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 体积差异

在移动逆向分析以及 APP 开发的时候，总会需要对其网络行为进行监控测试，本文针对市面上主流的抓包工具进行了抓包测试，并将过程进行了逐一记录，方便日后查用。

1. 基于 Wireshark

1.1 抓包环境

Windows 10 + 小米5s Plus + Wireshark 3.2.1 【下载地址】

1.2 设置 WiFi

在电脑主机上使用百度 WiFi之类的工具，开启热点，将所要抓包的手机连接该热点，并记录手机的【IP地址】和【路由器】，这两个信息会在后续的抓包过程中用到。

在 Java 中，<? extends T> 和 <? super T> 是 Java 泛型中的「通配符」Wildcards 和「边界」Bounds的概念。

Java 是单继承，所有继承的类构成一棵树。假设 A 和 B 都在一颗继承树里（否则 super，extend 这些词没意义）。

A extend B 表示 A 是 B 的子类或者子孙，在 B 下面。
A super B 表示 A 是 B 的父类或者祖先，在 B 的上面。

由于树这个结构上下是不对称的，所以这两种表达区别很大。假设有两个泛型写在了函数定义里，作为函数形参（形参和实参有区别）：

参数写成：T<? extends B>，由于指定了 B 为所有元素的“根”，你任何时候都可以安全的用 B 来使用容器里的元素，但是插入有问题，由于供奉 B 为祖先的子树有很多，不同子树并不兼容，由于实参可能来自于任何一颗子树，所以你的插入很可能破坏函数实参，所以，对这种写法的形参，禁止做插入操作，只做读取。

参数写成：T<? super B>，对于这个泛型，? 代表容器里的元素类型，由于只规定了元素必须是 B 的超类，导致元素没有明确统一的“根”（除了 Object 这个必然的根），所以这个泛型你其实无法使用它，对吧，除了把元素强制转成 Object。所以，对把参数写成这样形态的函数，你函数体内，只能对这个泛型做插入操作，而无法读。

Kotlin 与 Java 的构造器有着很大的区别，Java 的构造器需要与类同名，Kotlin 的构造器则必须要使用 constructor 进行表示，并且没有 public 关键字修饰，因为 Kotlin 的构造器默认是公开可见的。

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

/**
 * Java : 用同类名方法表示构造器，有 public 关键字修饰，默认可见
 */
public class User {

    private String username;
    private String password;

    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }

}

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

/**
 * Kotlin : 用 constructor 声明构造器，无 public 关键字修饰，默认可见
 */
class User {

    val username: String
    val password: String

    constructor(username: String, password: String) {
        this.username = username
        this.password = password
    }

}

通过上面的代码我们知道了构造器在 Java 与 Kotlin 中的写法和区别。其实在 Kotlin 中，还有更简介的语法来写构造器，我们可以在声明类的同时声明构造器，语法格式是在类的后面使用括号包含构造器的参数列表，示例如下：

1
2
3
4
5
6

class User constructor(username: String, password: String) {

    var username: String = username
    var password: String = password

}

这种跟在类名后面的构造器称为「主构造器」，写在类中的构造器被称为「次构造器」。在 Kotlin 中，一个类最多只能有一个主构造器（也可以没有），而次构造器则没有个数限制。constructor 构造器移到类名后，类的属性可以引用构造器中的参数，比如以上示例中 User 类的属性 username 可以引用构造器中的 username 参数。此外，init 代码块也可以引用主构造器中的参数：

1
2
3
4
5
6
7
8
9
10
11

class User constructor(username: String, password: String) {

    var username: String
    var password: String

    init {
        this.username = username
        this.password = password
    }

}

说明：其中 init 代码块是紧跟在主构造器之后执行的，这是因为主构造器本身没有代码体，init 代码块就充当了主构造器代码体的功能。

另外，如果一个类有主构造器，那么其他次构造器都要通过 this 关键字调用主构造器，可以直接调用或者通过别的次构造器间接调用。如果不调用 IDE 就会报错，比如下面这样：

1
2
3
4
5
6
7

class User constructor(username: String, password: String) {

    constructor(username: String, password: String, sex: Int) {
        // Error : Primary constructor call expected
    }

}

在 Kotlin 中，Elvis 操作符特定是跟 null 进行比较。也就是说

1

val y = x ?: 0                                          // 使用 Elvis 操作符 ?:

等价于

1

val y = if (x !== null) x else 0                        // 等价的 if...else 逻辑

主要用来做 null 安全性检查。

Elvis 操作符 ?: 是一个二元运算符，如果第一个操作数为真，则返回第一个操作数，否则将计算并返回其第二个操作数。它是三元条件运算符的变体，Kotlin 中没有类似 true? 1 : 0 这样的三元运算符，取而代之的是 if(true) 1 else 0 。而 Elvis 操作符算是精简版的三元运算符。

注意：这里所说的 Elvis 操作符是精简版的三元运算符是一种狭义的概念，因为 Elvis 操作符仅限于跟 null 进行比较，是广义三元运算符中的一个特例。

新开的项目需要内置一个 SQLite 数据库，内置的库会提前灌入一些基本数据信息以减少客户端和服务器之间的交互。之前一直都是使用 SQLite Administrator 在灌数据，但这个工具一直存在编码问题，用着不是很舒服。这次对 SQLiteExpert 进行了测试，发现 SQLite Expert Professional 版具有文件导入功能，并且能完美的解决编码问题。

注意： 这里要强调的是只有 SQLite Expert Professional [专业版] 具有文件导入功能，SQLite Expert Personal [个人版] 是不具备该功的。

1. 准备数据

数据的准备如下图所示，第一行为表的列名，列名下填充对应的数据。