Android 项目在经历了长期的迭代开发后，必然会寻求各模块间的逻辑独立和解耦，以降低维护成本，提高代码的可读性。抛开动态下发与动态加载技术，多数研发人员会将一些可模块化的独立逻辑抽取出来，以 Android Library Module 的形式引入到项目中。随着抽取的类库越来越多，Application 和 Library 并列共存，代码维护会异常混乱。为了改善这种情况，Android Studio 提供了将模块放置在子文件夹中的语法。

Java 8 API 增加了一个新的抽象称为流 Stream，可以让你以一种声明的方式处理数据。Stream 使用一种类似 SQL 语句从数据库查询数据的方式来提供一种对 Java 集合运算和表达的高阶抽象。这种风格将要处理的元素集合看作一种流，流在管道中传输，并且可以在管道的节点上进行处理，比如筛选、排序、聚合等。如果你之前有 RxJava 的使用经历，应该不会对流的操作感到陌生，并且 Stream 要比 RxJava 更容易上手。

元素流在管道中经过中间操作的处理，最后由最终操作得到前面处理的结果。下图展示了元素流经过筛选、排序、映射操作后，最终被转换成聚合元素的过程。后续我们将会对 Stream 的各种操作符进行展示。

通常情况下，我们可以通过 IDE 的插件市场来完成 Lombok 插件的安装。如果网络受阻或新版 Lombok 插件没有及时在插件市场上线，再或者在插件市场搜索不到对应的插件，我们就可以通过离线方式来进行安装。步骤如下：

1、在 Lombok@Github 或 Lombok@JetBrains 下载最新版本的 Lombok 插件。

单向绑定刷新 UI 有三种方式：BaseObservable、ObservableField、ObservableCollection。

在局部 UI 的刷新过程中，notifyPropertyChanged() 需要传入一个 int 类型的参数，这个参数就是 fieldId，指的就是特定属性名对应的 ID。这里要注意的是，这个属性必须是 public 类型，并且被 @Bindable 注解进行修饰，否则会报错。本例中以 User 类的 name 属性进行局部 UI 刷新测试，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

package com.sunzn.bind;

import androidx.databinding.BaseObservable;
import androidx.databinding.Bindable;

import com.sunzn.data.BR;

public class User extends BaseObservable {

    private int id;

    @Bindable
    public String name;

    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
        notifyChange();
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
        notifyPropertyChanged(BR.name);
    }

}

✦ 注意： BR 类在导包的时候需选择项目包名。

在《Android-DataBinding（一）基础》一文中对 DataBinding 的接入和使用进行了介绍。本文将会针对 DataBinding 中一些琐碎的知识点进行介绍，比如：Class 属性、Default 属性、Resource 引用等，这些属性被使用的频率或许不是很高，但特定的情况下却会起到意想不到的作用。下面将会针对这些属性进行逐一的讲解。

1. Data 标签的 Class 属性

默认情况下，系统会根据布局文件的名称生成对应的 ViewDataBinding 子类，帮助我们操作 XML 中绑定的数据，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

package com.sunzn.data;

import android.os.Bundle;

import androidx.appcompat.app.AppCompatActivity;
import androidx.databinding.DataBindingUtil;

import com.sunzn.data.databinding.ActivityMainBinding;

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ActivityMainBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_main);
    }
    
}

DataBinding 是 Android Jetpack 套件下的一个库，其作用是使用声明性格式将布局中的界面组件绑定到应用中的数据源。借助布局文件中的绑定组件，你可以移除 Activity 中的许多界面框架调用，使其维护起来更简单、方便。还可以提高应用性能，并且有助于防止内存泄漏以及避免发生 Null 指针异常。

**✦ 注意：**在许多情况下，视图绑定可简化实现，提高性能，提供与数据绑定相同的好处。如果你使用数据绑定的主要目的是取代 findViewById() 调用，请考虑改用视图绑定。

1. 开始准备

DataBinding 库与 Android Gradle 插件捆绑在一起。所以无需声明对此库的依赖项，但必须启用它。如需启用 DataBinding，需要在 Modle 级的 build.gradle 文件中将 dataBinding 构建选项设置为 true，如下所示：

1
2
3
4
5
6

android {
    ...
    buildFeatures {
        dataBinding true
    }
}

随着 DataBinding 在项目中使用频率的增加，就越能感觉到 Jetpack 下的这个组件在 Android 开发中所带来的便捷性。DataBinding 不仅在形式上彻底抛弃了传统意义上寻找控件的模版代码，也在本质上防止了控件在使用过程中的空指针、类型转换和内存泄漏等问题，使得开发者可以将更多的精力投入到业务逻辑的开发中。当然，DataBinding 的出现不仅仅是用来解决模版代码的，它还可以将变量和布局中的视图进行关联，同时还可以实现双向数据绑定，既接收对属性的数据更改，又监听用户对此属性的更新。

毫无疑问，DataBinding 已经在一定程度上改变了你的开发习惯。比如，你可能更习惯于在布局文件中使用 @{onClickListener} 来为一个控件添加点击事件；再比如，你可能更喜欢在布局文件中使用表达式 @{viewmodel.username} 来为一个 TextView 进行赋值。没错，你也会更倾向于采用同样的方法为 EditText 添加一个文字改变监听器。但事实上，DataBinding 是不支持直接为 EditText 添加文字改变监听器的，我们需要依赖 ViewModel 持有一个 TextWatcher 的实例并将其绑定到 EditText 上来进行实现。

EditText 实现文字改变的监听大致分为三步：一、定义持有 TextWatcher 实例的 ViewModel；二、布局文件引用 ViewModel；三、Activity 调用。伪代码如下，如需访问完整代码请访问 Watcher@Gitee。

只要继承 Thread 类或是实现 Runnable 接口，就可以让对象具有多线程功能。入门线程是简单的，但如果多个线程共享某些数据，数据的同步（一致性、整体性）问题就要特别注意。

1. 同步化

如果程序只是一个单线程，即单一流程的程序，那么只要保证程序逻辑正确，程序通常就可以正确地执行你想要的功能。但当程序是多线程程序，即多流程同时执行时，那么就需要注意更多的细节。例如在多线程共享同一对象的数据时。

如果一个对象所持有的数据可以被多线程同时共享存取，则必须考虑到数据同步的问题。所谓数据同步指的是两份数据的整体性和一致性。例如对象 A 有 name 与 id 两个属性，而有一份 B 数据有 name 与 id 的数据要用来更新对象 A 的属性，如果 B 的 name 与 id 设定给 A 对象完成，则称 B 与 A 同步。如下图所示：

Java 中的单例（Singleton）模式是一种广泛使用的设计模式。单例模式的主要作用是保证在 Java 程序中，某个类只有一个实例存在。一些管理器和控制器常被设计成单例模式。

单例模式有很多好处，它能够避免实例对象的重复创建，不仅可以减少每次创建对象的时间开销，还可以节约内存空间；能够避免由于操作多个实例导致的逻辑错误。如果一个对象有可能贯穿整个应用程序的生命周期，而且起到了全局统一管理控制的作用，那么单例模式也许是一个值得考虑的选择。

单例模式有很多种写法，大部分写法都或多或少有一些不足。下面将分别对这几种写法进行介绍。

1. 饿汉模式

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() {
        super();
    }

    public static Singleton getInstance() {
        return instance;
    }

}

从代码中我们看到，类的构造函数被定义为 private 的，保证其他类不能实例化此类，然后提供了一个静态实例并返回给调用者。饿汉模式是最简单的一种实现方式，静态变量在类加载的时候就对实例进行创建，实例在整个程序周期都存在。它的好处是静态变量只在类加载的时候创建一次实例，不存在多个线程创建多个实例的情况，避免了多线程同步的问题。它的缺点也很明显，即使这个单例没有用到也会被创建，而且在类加载之后就被创建，内存就被浪费了。

这种实现方式适合单例占用内存比较小，在初始化时就会被用到的情况。但是，如果单例占用的内存比较大，或单例只是在某个特定场景下才会用到，使用饿汉模式就不合适了，这时候就需要用到懒汉模式进行延迟加载。

该来到的终会到来，如果你还没有经历过上下求索的磨砺，说明你的加快前进的脚步了。Google 的大神们早就挖好坑，头也不回的继续挖下一个坑去了，我们能做的只是尽量跟着这些人的脚步，不至于被甩开太远。开始正文之前，我想有必要知道 Android M（6.0）是 Google 在 2015 年 5 月 28 日的 Google I/O 大会上正式推出的版本，没错，这特么是一个 5 年前的版本！但这个版本的行为变更一直默默无闻的在那躺着无人问津，直到你将 minSdkVersion 指向了 23，这时你会发现 APK 签名包的体积极大的超出了预期。到这，你是不是能理解一个程序员在文章开头发出的感叹了？

1. 奇怪的 APK 体积差异