Android 架构组件 - 让天下没有难做的 App

Google 为了帮助 Android 开发者更快更好地开发 App，推出了一系列组件，这些组件被打包成了一个整体，称作 Android Jetpack，它包含的组件如下图所示：老的 support 包被整合进了 Jetpack，例如上图 Foundation 模块的 AppCompat，整合进去之后，包名做了一下修改，全部以 androidx 开头。Android Studio 提供的迁移工具（Refactor > Migrate to AndroidX）可以将源码中的旧包名替换成新的，但是如果 Maven 依赖的产物还未迁移到 AndroidX 的话，还需要配置一个工具—— Jetifier，只需要在 build.gradle 中加上两行配置即可：android.enableJetifier=true
复制代码Jetfier 会在编译阶段直接修改依赖产物的字节码，简单粗暴。架构大图Jetpack 不属于 Android Framework，不是 Android 开发的必需品，它只是应用层开发的一种辅助手段，帮我们解决了一些常见问题，比如版本兼容、API 易用性、生命周期管理等。其中 Architecture 部分的组件（Android Architecture Components，以下简称 AAC）组合起来形成了一套完整的架构解决方案，在没有更好的方案被发明出来之前，我们姑且把 AAC 当做 Android 架构领域的最佳实践，它的出现一定程度上避免了很多不必要的轮子。官方给出的架构指导非常明确地表达出了每个架构组件的位置：这张图背后隐含了三大设计思想：关注点分离（SOC / Separation Of Concerns）数据驱动 UI（Reactive）唯一真相源（SSOC / Single Source Of Truth）SOC 具体到工程实践中就是分层合理，单层的职责越明确，对上下游的依赖越清晰就意味着它的结构更稳定，也更可测（testable）。一个 App 从全局来看，可以划分为三部分：首先是 UI Controller 层，包含 Activity 和 Fragment；其次是 ViewModel 层，既可以做 MVVM 的 VM、MVP 的 P，也可以做 UI 的数据适配，这一层可以实现数据驱动 UI；最后是 Repository 层，它作为 SSOC，是一个 Facade 模式，对上层屏蔽了数据的来源，可以来自 local，也是来自 remote，数据持久化策略向上透明。一张架构蓝图，三大设计原则，接下来深入细节，看看组件之间如何配合才能实现这个架构Lifecycle与 React/Vue 或者 iOS 相比，Android 的生命周期都比较复杂，如果要监听生命周期，一般情况下只能覆写 Activity / Fragment 的回调方法（onCreate、onResume、onPause、onDestroy 等），样板代码少不了，可维护性也变差。如果要对生命周期进行简化，可以抽象成一个图，点表示状态，线表示事件：Lifecycle 负责处理这些点（states）和线（events），Activity / Fragment 是 LifecycleOwner，监听者则是 LifecycleObserver，一个非常清晰的观察者模式。class MyObserver : LifecycleObserver {

@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun connectListener() {
}

@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
fun disconnectListener() {
}

}
复制代码如果我们的组件需要强绑定声明周期，那么只需要借助 Lifecycle 去监听生命周期的状态和事件即可，再也不用覆写各种回调方法了。下面将要讲到的 LiveData 和 ViewModel 都是 Lifecycle-Aware Components，它们都用到了 Lifecycle。Android 生命周期管理不当带来的最大问题就是内存泄露，举一个我们经常遇到的场景：一个异步任务（比如网络请求）持有了 UI 元素的引用，只要任务没有执行完，所有与这个 UI 元素有强引用关系的元素都没法被 GC，如果这样的场景多发生几次，很可能会引起 OOM。为了异步对象引用的问题，最早我们使用 AsyncTask，任务执行在 worker thread，执行结果在主线程上发起回调。AsyncTask 的致命缺点是不支持流式数据（stream），而且回调嵌套太深（callback hell），与软件质量衡量指标之一的 maintainable 背道而驰，不好用自然就会慢慢被淘汰。后来我们开始使用 RxJava，响应式编程，声明式写法，再借助 retrolambda 这种 backport，即使当年 Android 只支持到 JDK7，我们依然可以利用各种 operator 写出非常简洁的代码，“filter map 我闭~着眼”。RxJava 不但完美解决了线程调度的问题，还为我们提供了 OO 之外的抽象——作用在流上的 lambda，基于函数的抽象。但是，即便完美如斯，生命周期的问题依然无法回避，因为 Java 天生的局限性，一个 lambda 无论伪造地再像高阶函数，它本质上还是一个匿名内部类，这个匿名内部类依然持有对 outer class 实例的引用。于是我们必须通过 CompositeDisposable 来管理订阅关系，发起异步操作时记录订阅，离开页面时取消订阅，仍然需要覆写 onDestory 或者 onPause 。如果我们以 Repository 层为界把架构蓝图分为上下两部分的话，上面的部分是数据展示，下面的部分是数据获取，数据获取部分因为要请求 Remote 数据，必然会依赖到线程调度，而数据展示必然运行在 UI 线程，与生命周期强相关，这个时候就需要 LiveData 登场了。LiveDataLiveData 也是一个观察者模型，但是它是一个与 Lifecycle 绑定了的 Subject，也就是说，只有当 UI 组件处于 ACTIVE 状态时，它的 Observer 才能收到消息，否则会自动切断订阅关系，不用再像 RxJava 那样通过 CompositeDisposable 来手动处理。LiveData 的数据类似 EventBus 的 sticky event，不会被消费掉，只要有数据，它的 observer 就会收到通知。如果我们要把 LiveData 用作事件总线，还需要做一些定制，Github 上搜 SingleLiveEvent 可以找到源码实现。我们没法直接修改 LiveData 的 value，因为它是不可变的（immutable），可变（mutable）版本是 MutableLiveData，通过调用 setValue（主线程）或 postValue（非主线程）可以修改它的 value。如果我们对外暴露一个 LiveData，但是不希望外部可以改变它的值，可以用如下技巧实现：private val _waveCode = MutableLiveData()
val waveCode: LiveData = _waveCode
复制代码内部用 MutableLiveData ，可以修改值，对外暴露成 LiveData 类型，只能获取值，不能修改值。LiveData 有一个实现了中介者模式的子类 —— MediatorLiveData，它可以把多个 LiveData 整合成一个，只要任何一个 LiveData 有数据变化，它的观察者就会收到消息： val liveData1 = …
val liveData2 = …

val liveDataMerger = MediatorLiveData<>();
liveDataMerger.addSource(liveData1) { value -> liveDataMerger.setValue(value))
liveDataMerger.addSource(liveData2) { value -> liveDataMerger.setValue(value))
复制代码综上，我们汇总一下 LiveData 的使用场景：LiveData - immutable 版本MutableLiveData - mutable 版本MediatorLiveData - 可汇总多个数据源SingleLiveEvent - 事件总线LiveData 只存储最新的数据，虽然用法类似 RxJava2 的 Flowable，但是它不支持背压（backpressure），所以不是一个流（stream），利用 LiveDataReactiveStreams 我们可以实现 Flowable 和 LiveData 的互换。如果把异步获取到的数据封装成 Flowable，通过 toLiveData 方法转换成 LiveData，既利用了 RxJava 的线程模型，还消除了 Flowable 与 UI Controller 生命周期的耦合关系，借助 Data Binding 再把 LiveData 绑定到 xml UI 元素上，数据驱动 UI，妥妥的响应式。于是一幅如下模样的数据流向图就被勾勒了出来：图中右上角的 Local Data 是 AAC 提供的另一个强大武器 —— ORM 框架 Room。Room数据库作为数据持久层，其重要性不言而喻，当设备处于离线状态时，数据库可用于缓存数据；当多个 App 需要共享数据时，数据库可以作为数据源，但是基于原生 API 徒手写 CRUD 实在是痛苦，虽然 Github 上出现了不少 ORM 框架，但是它们的易用性也不敢让人恭维，直到 Room 出来之后，Android 程序员终于可以像 mybatis 那样轻松地操纵数据库了。Room 是 SQLite 之上的应用抽象层，而 SQLite 是一个位于 Android Framework 层的内存型数据库。虽然 Realm 也是一个优秀的数据库，但是它并没有内置于 Android 系统，所会增大 apk 的体积，使用 Room 则没有这方面烦恼。Room 的结构抽象得非常简单，数据对象（表名 + 字段）用 @Entity 注解来定义，数据访问用 @Dao 来注解，db 本身则用 @Database 来定义，如果要支持复杂类型，可以定义 @TypeConverters，然后在编译阶段，apt 会根据这些注解生成代码。Room 与 App 其他部分的交互如下图所示：Entity 是一个数据实体，表示一条记录，它的用法如下：@Entity(tableName = “actors”)
data class Actor(
@PrimaryKey @ColumnInfo(name = “id”)
val actorId: String,
val name: String,
val birthday: Date?,
val pictureUrl: String
)
复制代码Actor 是一个用 @Entity 注解的 data class，它会生成一个名字是 actors 的表，注意到有一个字段是 @Date? ，但是 SQLite 本身不支持这种复杂类型（complex type），所以我们还需要写一个可以转换成基础类型的转换器：class Converters {
@TypeConverter
fun timestampToDate(value: Long?) = value?.let { Date(it) }

@TypeConverter
fun dateToTimestamp(date: Date?) = date?.time

}
复制代码转换器通过 @TypeConverters 可作用于 class、field、method、parameter，分别代表不同的作用域。比如作用在 @Database 类的上，那么它的作用域就是 db 中出现的所有 @Dao 和 @Entity。@Database(entities = [Actor::class], version = 1, exportSchema = false)
@TypeConverters(Converters::class)
abstract class AppDatabase : RoomDatabase() {
abstract fun actorDao(): ActorDao
}
复制代码代码出现的 ActorDao 定义了 CRUD 操作。用 @Dao 来注解，它既可以是一个接口，也可以是抽象类，用法如下：@Dao
interface ActorDao {
@Query(“SELECT * FROM actors WHERE id = :actorId”)
fun getActor(actorId: String): LiveData

@Insert(onConflict = OnConflictStrategy.REPLACE)
fun insertAll(actors: List)

}
复制代码@Query 中的 SQL 语句可以直接引用方法参数，而且它的返回值可以是 LiveData 类型，也支持 Flowable 类型，也就是说，Room 原生支持响应式，这是对数据驱动最有利的支持，也是 Room 区别于其他 ORM 框架的显著特征。至此，我们可以确定，无论数据来自 Remote 还是来自本地 DB，架构蓝图中的 Repository 对 ViewModel 提供的数据可以永远是 LiveData 类型，接下来我们看一下 ViewModel 的妙用。ViewModelViewModel 是一个多面手，因为它的生命周期比较长，可以跨越因为配置变动（configuration changed，比如屏幕翻转）引起的 Activity 重建，因此 ViewModel 不能持有对 Activity / Fragment 的引用。