Android 架构组件，节省你重复造轮子时间

前言

Google 为了帮助 Android 开发者更快更好地开发 App，推出了一系列组件，这些组件被打包成了一个整体，称作 Android Jetpack，它包含的组件如下图所示：

老的 support 包被整合进了 Jetpack，例如上图 Foundation 模块的 AppCompat，整合进去之后，包名做了一下修改，全部以 androidx 开头。Android Studio 提供的迁移工具（Refactor > Migrate to AndroidX）可以将源码中的旧包名替换成新的，但是如果 Maven 依赖的产物还未迁移到 AndroidX 的话，还需要配置一个工具—— Jetifier，只需要在 build.gradle 中加上两行配置即可：

 

android.useAndroidX=true
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