Android 应用架构组件（Architecture Components）实践

lijiankun24 鸿洋 2019-04-05

本文作者

作者：lijiankun24

链接：http://lijiankun24.com/archives/

本文由作者授权发布。

Architecture Components 是在 2017 年 Google I/O 大会上，Google 官方推出的一个构建 Android 应用架构的库。它可以帮你避免在 Android 应用开发中常见的一些问题，比如：内存泄露，管理组件生命周期等等。

本文将介绍如何利用 Architecture Components 库开发一个实际的 Android 应用 ArchitecturePractice，欢迎 fork 和 star。

https://github.com/lijiankun24/ArchitecturePractice

本文主要分为以下两部分：

介绍 Architecture Components 库；
如何使用 Architecture Components 库开发应用。

1关于 Architecture Components

应用开发者所面对的问题

在资源有限的移动设备中，在任何时候，系统都有可能为新的应用杀死一些原来的应用，那么在原来应用中的组件（Activity、Fragment、Service等等）也会被销毁，这些组件的生命周期不受开发者控制，而是由系统控制的，所以不要在应用程序组件中存储任何应用数据和状态，并且应用程序组件之间相互不要依赖。

常见的构建原则

如果不可以在应用程序组件中存储应用数据和状态，那么该如何构建应用呢？这儿有两条常见的构建原则：

关注点分离：一个常见的错误是在 Activity 和 Fragment 中编写所有的代码。任何和UI或者操作系统交互无关的代码都尽量不要出现在这些类中，尽量保持这些类的精简会帮助你避免很多和生命周期相关的问题。最好减少对它们的依赖以提供一个稳定的用户体验。
通过 Model 驱动 UI，最好是持久化的 Model。最好使用持久化的数据有两个原因：a. 如果系统销毁应用释放资源，用户也不用担心丢失数据； b. 即使网络连接不可靠或者断网，应用仍将继续运行。Model 是负责处理应用数据的组件，Model 独立运行于应用中的 View 和应用程序中的其他组件，因此 Model 和其他应用程序组件的生命周期无关。基于 Model 构建的应用程序，其管理数据的职责明确，所以更容易测试，而且稳定性更高。

主要内容

处理生命周期

在 android.arch.lifecycle 包中提供了可以构建生命周期感知的组件的类和接口，这些组件可以根据 Activity/Fragment 的生命周期自动调整它的行为。

https://developer.android.com/reference/android/arch/lifecycle/package-summary.html

Lifecycle：它是一个持有 Activity/Fragment 生命周期状态信息的类，并且允许其他对象观察此状态。
LifecycleOwner：是一个具有单一方法的接口。如果一个类实现了此接口，则该类中需要持有一个 Lifecycle 对象，并通过LifecycleOwner#getLifecycle() 方法返回该对象。
并不是只有 Activity 和 Fragment 才可以实现 LifecycleOwner 接口的，任何和 Activity/Fragment 生命周期有关系的类都可以实现此接口。通过实现此接口，该类完全是生命周期可感知的，只需要对它进行初始化，它就可以进行自己的初始化和清理操作，而不受其 Activity/Fragment 的管理。详细可以参看官方文档说明：LifecycleOwner 实践

LiveData

LiveData 是一个数据持有类，它持有一个值并且该值可以被观察。不同于普通的可观察者，LiveData 遵从应用组件的生命周期，这样 Observer 便可以指定一个其应该遵循的 Lifecycle。

如果 Observer 所依附的 Lifecycle 处于 STARTED 或者 RESUMED 状态，则 LiveData 认为 Observer 处于活跃状态。

可以感知组件生命周期的 LiveData 给我们提供了一种可能：可以在多个 Activity、Fragment 之间共享它。

使用 LiveData 会有以下几个优势：

避免内存泄露：因为 Observer 是绑定到 Lifecycle 对象上的，当 Lifecycle 对象被销毁的时候，LiveData 对象也会被自动清除
不会因为 Activity 停止而使应用崩溃：如果 Observer 所绑定的 Lifecycle 处于闲置状态（例如：Activity 处于后台运行时），他们不会接收到改变的事件
始终保持最新的数据：如果一个 Lifecycle 重新启动以后（例如：Activity 从后台重新开始运行于前台），它会接收到最新的数据（除非没有最新的数据）
正确处理配置改变：如果一个 Activity 或者 Fragment 以为配置改变（例如：旋转屏幕）被重建以后，LiveData 将会接收到最新的数据
资源共享：通过单例模式，可以在多个 Activity 或者 Fragment 之间共享 LiveData 数据。
不再手动的处理生命周期：Fragment 只有在处于活跃的时候才会观察 LiveData 数据。由于 Fragment 提供了 Lifecycle 对象，所以 LiveData 会管理这一切。

有时候，也许想在 LiveData 被下发到 Observer 之前，改变 LiveData 的值，或者是基于当前的 LiveData 下发另一个不同的 LiveData 值。Lifecycle 包中的 Transformations 可以实现这样的功能。

Transformations.map()，使用此方法，可以将 LiveData 传递到下游

LiveData<User> userLiveData = ...;
LiveData<String> userName = Transformations.map(userLiveData, user -> {
user.name + " " + user.lastName
});

Transformations.switchMap()，和 map() 方法类似，使用 switchMap() 应用于 LiveData的值并解包，然后将结果传递到下游。传递给 switchMap() 的方法必须返回一个 Lifecycle

private LiveData<User> getUser(String id) {
  ...;
}
LiveData<String> userId = ...;
LiveData<User> user = Transformations
        .switchMap(userId, id -> getUser(id) );

使用这两个转换，允许在整个调用链中携带观察者的 Lifecycle 信息，这样的话，只有在观察者观察到 LiveData 的返回值时，才会运算这些转换。

当你需要在 ViewModel 中添加一个 Lifecycle 对象时，Transformations 或许是一个好的解决办法。

ViewModel

ViewModel 类是用来存储和管理 UI 相关的数据，这样在配置发生变化（例如：屏幕旋转）时，数据就不会丢失。

由于应用程序组件（例如：Activity、Fragment），具有一个由 Android Framework 管理的生命周期，Activity 或 Fragment 在某些情况下（比如：内存紧张或者屏幕旋转）会发生销毁或者重新创建的情况。

这样就会带来一些问题：

由于 Activity 或者 Fragment 有可能会被销毁或重新创建，所以保存于其中的数据有可能会丢失
在 Activity 或者 Fragment 中会经常发起一些需要一定时间才会返回结果的异步请求调用
如果把处理应用数据、完成响应用户操作、处理系统通信工作的代码都写在 Activity 或者 Fragment 中，那么 Activity 或者 Fragment 将会变得非常的臃肿，给维护工作带来一定的困难

针对以上问题，Lifecycle 提供了一个叫 ViewModel 的类，一个 UI 控制器的帮助类，用来为 UI 准备数据。

在配置更改的时候，ViewModel 会被保留，以便其保存的数据可以立即传递给重新创建的 Activity 或者 Fragment 实例中。如果 Activity 被重新创建，它将会收到由之前的 Activity 或者 Fragment 创建的 ViewModel 实例。当所有者 Activity 被销毁以后，Framework 会调用 ViewModel#onCleared() 清楚系统资源。

在多个 Fragment 之间共享数据

在同一个 Activity 中的多个 Fragment 之间进行通信是十分常见的需求，目前通常的做法是新建一个接口，并且用 Activity 将多个 Fragment 联系起来。如果需要通信的数据比较多，就会出现接口泛滥的情况。

使用 ViewModel 可以解决这个痛点。在同一个 Activity 中的 Fragment 可以使用此 Activity 限定的 ViewModel 来处理该通讯。比如如下代码所示：

在上面示例代码中，获取 ViewModelProvider 时两个 Fragment 都使用 getActivity() 方法，这就意味着，它们会收到同一个 Activity 限制的同一个 ViewModel 实例对象。

这样做有以下几个优点：

Activity 不需要知道该通信的任何事情
Fragment 之间不受相互影响。除了 ViewModel 之外，Fragment 不需要了解彼此，就算一个 Fragment 被销毁了，另一个也可以正常工作。而且每个 Fragment 都有自己独立的生命周期，不受其他 Fragment 的影响。

ViewModel 的生命周期

ViewModel 对象存在于内存当中，直到传递给它的 Lifecycle 对象被完成的销毁（Activity：被完全销毁，Fragment：被完成移除）。其生命周期图如下所示：

ViewModel vs SavedInstanceState

ViewModels 提供了一种在配置更改时保存数据的简便方式，但是如果应用进程被操作系统杀死，那么数据则没有机会被恢复。
通过 SavedInstanceState 保存的数据，存在于操作系统进程的内存中。当用户离开应用数个小时之后，应用的进程很有可能被操作系统杀死，通过 SavedInstanceState 保存的数据，则可以在 Activity 或者 Fragment 重新创建的时候，在其中的 onCreate() 方法中通过 Bundle 恢复数据。

Room Persistence Library

Room 在 SQLite 之上提供了一个抽象层，以便在利用 SQLite 全部功能的同时也可以流畅发访问数据库。

在 Room 中有非常重要的三个类：

Database：可以使用此组件创建一个数据库持有者。使用注解定义实体列表，通过类的内容定义数据库中数据访问对象列表。它也是底层连接的主要切入点。
注解的类应该是一个继承了 RoomDatabase 的抽象类。在运行时，可以通过 Room.databaseBuilder() 或者 Room.inMemoryDatabaseBuilder() 方法获取单例。
Entity：该组件代表了一个表示数据库中某个数据表某一行的类。对于每个 Entity 类，都会在数据库中创建一个数据表保存该类的对象。必须通过 Database 中的 entities 字段引用 Entity 类。Entity 类中的每个字段都会持久化到数据中，除非使用 @Ignore 注解修饰
DAO：该组件表示一个数据访问对象（DAO）的类或者接口。DAO 是 Room 的主要组件，其职责是定义方法来访问数据库。被 @Database 注解修饰的类必须包含一个没有参数的抽象方法，该方法的返回值是被 @Dao 注解的类。在编译时生成代码时，Room 创建该类的实现。

Room 中的三大组件与应用程序中其他部分的关系如下图所示：

关于 Room Persistence Library 更加详细的内容，请参阅 Room Persistence Library 官方说明文档。

https://developer.android.com/topic/libraries/architecture/room.html

2Architecture Components 的使用

添加组件到项目

添加 Google Maven 仓库

在应用工程的 build.gradle 文件中添加依赖对 Google Maven 的依赖：

allprojects {
    repositories {
        jcenter()
        maven { url 'https://maven.google.com' }
    }
}

添加 Architecture Components 组件

在应用或者模块的 build.gradle 文件中添加对 Architecture Components 的依赖，如下所示：

具体应用

假如在项目中有类似于下面知乎列表这样的一个页面：

关于该页面有如下两个接口：

// 请求最新的知乎列表（下拉刷新）
https://news-at.zhihu.com/api/4/news/latest
// 上拉加载历史列表（上拉加载更多）
https://news-at.zhihu.com/api/4/news/before/{date}

根据上面两个接口和 “UI设计稿”，再根据 Architecture Components 组件中提供的类，我们一步步完成此页面。首先我们分三步：

UI 界面的实现
中间层 ViewModel（UI 界面和数据层连接的桥梁）
数据层（本地持久化数据和服务器端的网络数据）

View 界面

此页面使用 Fragment 控制并显示，将其命名为 ZhihuListFragment.java，其布局文件 fragment_zhihu_list.xml 如下所示：

fragment_zhihu_list.xml 布局文件比较简单，不需要多讲。

ZhihuListFragment.java 代码如下所示：

在 ZhihuListFragment.java 中注释已经比较清楚，关于 UI 方面的不多讲，其中最重要的一个方法是 subscribeUI() 方法。在该方法中，创建 ZhihuListViewModel 对象之后，对 ZhihuListViewModel 中两个重要的数据进行注册观察并更新 UI，两个重要的数据分别是：

LiveData<List<ZhihuStory>> 和 LiveData<Boolean>：

LiveData<List<ZhihuStory>>：表示从数据层获取到的知乎列表的数据
LiveData<Boolean>：表示是否正在获取数据的状态，以控制界面中加载动画的显示和隐藏

ViewModel 控制层

在 ZhihuListViewModel 类中需要三个 LiveData 类型的属性。LiveData 类型的数据和 RxJava 中的 Observables 工作模式类似，当 LiveData 持有的数据发生变化时，通知观察者。如下面代码所示：

注：由于 ViewModel 存活的时间可能会比个别的 activity 和 fragment 实例更长，所以它决不能引用 View，或任何持任何 activity(context)。如果 ViewModel 需要 Application 的 context（如：调用系统服务），可以继承 AndroidViewModel 类，可以在构造函数中接受 Application。

上面示例的 ZhihuListViewModel 类是功能并不完整的 ViewModel 类，因为它只是向 View 层提供了操作 Zhihu 列表数据和监听数据请求状态的接口，那么 ZhihuListViewModel 该从哪里获取数据呢？

换句话说，数据源在哪里？

在 ArchitecturePractice 项目中(https://github.com/lijiankun24/ArchitecturePractice)，封装了 DataRepository 类，表示所有数据的源头。
那 ZhihuListViewModel 应该持有一个 DataRepository 对象，来获取数据。完整的 ZhihuListViewModel 类如下所示：

Model 数据层

正如在 ViewModel 控制层中介绍的，ArchitecturePractice 中所有的数据均由 DataRepository 类中获取。在 DataRepository 中有两个数据源：本地数据库和远端服务器，如果有网，则从服务器获取最新数据，并保存在本地数据库中；

如果没有网，则从本地数据库中加载数据并显示。则 DataRepository 的初步实现是这样的：

其中的 DataSource 表示获取数据的抽象层，如下所示：

此外还有两个非常重要的类：RemoteDataSource 和 LocalDataSource，这两个类分别实现了 DataSource 接口。

RemoteDataSource 类代码如下所示，从远端服务器获取数据使用的是 Retrofit，并且对网络请求进行简单封装，由 ApiManager(https://github.com/lijiankun24/ArchitecturePractice/blob/master/app/src/main/java/com/lijiankun24/architecturepractice/data/remote/api/ApiManager.java) 统一向外提供网络请求接口：

LocalDataSource 类代码如下所示，从本地数据库获取数据使用的是 Architecture Components 中的 Room 库，简单封装为 AppDatabaseManager(https://github.com/lijiankun24/ArchitecturePractice/blob/master/app/src/main/java/com/lijiankun24/architecturepractice/data/local/db/AppDatabaseManager.java) ，向外提供统一的方法：

使用到的 ApiManager 用于统一管理 Retrofit 网络请求，AppDatabaseManager 则是对 Room 数据库的统一管理，关于 Retrofit 和 Room 的使用就不再多说。这样一个向外提供干净可靠 API 的数据源 DataRepository 模块则完成了，DataRepository 主要负责处理数据的获取。

至此，关于 Architecture Components 组件的介绍和实践都全部介绍完毕，本文中用于举例的 ArchitecturePractice 在 GitHub 上，欢迎 star 和 fork，如果有什么问题欢迎指出。我的工作邮箱：jiankunli24@gmail.com

https://github.com/lijiankun24/ArchitecturePractice

参考资料：

Android Architecture Components 官方文档
https://developer.android.com/topic/libraries/architecture/index.html
Google 官方推出应用开发架构指南 – Hevin
https://zhuanlan.zhihu.com/p/27026614
译 Architecture Components 之 Guide to App Architecture – zly394
https://juejin.im/post/5937b1d7a22b9d005810b877

bxrf的瓜

失信被执行人的孩子上学受影响吗？最高法明确：受限！

”FAN某”的离婚财产分割判决书（全文）

”FAN某”的离婚财产分割判决书（全文）

公益慈善｜“翼行天下一生守护”慈善项目捐赠仪式圆满举行！