谷歌官方推出Android应用开发架构组件介绍(Android Architecture Components)

Posted 2022-11-26 七色音阶

简评：虽然说 android 的架构选择一直都很自由，MVP、MVC、MVVM 各有拥趸。但 Google 最近还是推出了一份关于应用架构的实践指南，并给出了相当详尽的步骤和一些指导建议。希望大家都能看一看，学习一下，打造更加优秀易用的 APP，也为 Android 生态的改善做一点贡献。: )

今年，官方在I/O 2017开发者大会上推出了Android开发的官方架构和最佳实践指南。这里就给大家介绍一下：

架构组件（Android Architecture Components） 是 2017 Google IO 上发布的关于安卓开发的一个重量级框架。算是安卓开发框架的一个官方参考实现。现在该框架还处于 alpha1 版本，估计会在 Android O 正式发布的时候一起发布。

官方地址：https://developer.android.google.cn/topic/libraries/architecture/index.html

官方最新架构原则

首先，Android 开发者肯定都知道 Android 中有四大组件，这些组件都有各自的生命周期并且在一定程度上是不受你控制的。在任何时候，Android 操作系统都可能根据用户的行为或资源紧张等原因回收掉这些组件。

这也就引出了第一条准则：「不要在应用程序组件中保存任何应用数据或状态，并且组件间也不应该相互依赖」。

最常见的错误就是在 Activity 或 Fragment 中写了与 UI 和交互无关的代码。尽可能减少对它们的依赖，这能避免大量生命周期导致的问题，以提供更好的用户体验。

第二条准则：「通过 model 驱动应用 UI，并尽可能的持久化」。

这样做主要有两个原因：

1.  如果系统回收了你的应用资源或其他什么意外情况，不会导致用户丢失数据。
2.  Model 就应该是负责处理应用程序数据的组件。独立于视图和应用程序组件，保持了视图代码的简单，也让你的应用逻辑更容易管理。并且，将应用数据置于 model 类中，也更有利于测试。
   

官方架构组件

基础上面两个最新的架构原则，Android官方推出了一些的架构组件：

架构组件是多个小库组成的。你可以只使用其中的一部分也可以使用所有的库，目前由下面几个库共同组成安卓架构组件库：

• android.arch.core:core 包含一个自定义的 Function 接口和几个内部用到的类
• android.arch.core:core-testing 用于测试的一个核心类, 依赖于上面的 core 库
• android.arch.lifecycle:common 生命周期库的通用接口，里面定义了几个管理生命周期的一些接口，有 Lifecycle、LifecycleObserver、LifecycleOwner、OnLifecycleEvent、ViewModel、ViewModelProvider、ViewModelStore、ViewModelStoreOwner 等类和接口。
• android.arch.lifecycle:runtime 库定义了几个生命周期相关的运行时接口，这个库依赖 android.arch.core:core 和 android.arch.lifecycle:common 库。里面有LifecycleRegistry、ProcessLifecycleOwner、ServiceLifecycleDispatcher、LifecycleActivity、LifecycleFragment、LifecycleService 等接口。值得注意的是， LifecycleActivity 是继承至 android.support.v4.app.FragmentActivity 的，而 LifecycleFragment 是继承至 android.support.v4.app.Fragment 的，当 android.arch.lifecycle 正式发布的时候，这两个类将被删除，Support v4 中的 FragmentActivity 和 Fragment 将直接实现 LifecycleRegistryOwner 接口。也就是说，当安卓架构组件正式发布的时候， 新版本的 Support v4库将依赖架构库并提供基本的实现。如果你不使用安卓架构组件的话，对你的影响也不大，只是添加了几个接口和十几个函数而已。
• android.arch.lifecycle:extensions  这个库依赖前面的 runtime 库，里面是扩展生命周期功能的几个接口定义和实现，主要有 AndroidViewModel 接口，里面可以访问 Application context 对象；LiveData 的类，用户在生命周期中保存数据的；Transformations 助手类实现简单的数据处理操作，类似 RxJava 中的操作符；ViewModelProviders 提供了对 ViewModel 的创建和管理。
• android.arch.lifecycle:compiler 这个是用来生成代码的库，需要使用 annotationProcessor “android.arch.lifecycle:compiler:1.0.0-alpha1” 的方式来引用，自动生成一些代码避免使用反射来提高性能。
• android.arch.persistence.room 是数据库 ORM 框架，里面包含了 common、runtime、migration、support-db、support-db-impl、compiler 等子库。如果你的应用中不使用 Sqlite 则无需使用 room 框架。
  

从上面的库分布可以看到，安卓框架组件的主要功能有两个：管理生命周期和数据库 ORM 。

生命周期

生命周期是 Android 应用中的特点，Android 系统四大组件都有不同的生命周期，系统会在不同的时候调用这些生命周期回调接口，你一个应用需要恰当的处理这些生命周期回调接口，否则的话您的应用可能会导致内存泄露或者应用会崩溃。对于 Android 开发新手来说，处理这些生命周期是比较麻烦的，所以 Android 团队希望通过这个 lifecycle 库来帮助开发者正确的处理生命周期。

ViewModel 是干什么的呢？

ViewModel 是生命周期中延伸出来的一个概念，比如 Activity，一般而言我们会把很多代码都放到 Activity 中去，但是 Activity 类是系统调用的，系统会在不同的情况下去调用 Activity 的不同函数，Activity 类只是系统和您的应用的桥梁，所以避免把过多的代码放到 Activity 中去，官方建议只有 处理 UI 事件或者和系统服务交互的代码才能放到 Activity 中。

另外你的 UI 应该有模型（model）来驱动，模型的责任是处理应用的数据，和 View 以及你 App 中的其他组件是独立的，并且模型应该和生命周期分离。这样 UI 代码尽可能的简单并和 App 逻辑代码分离可以很方便的处理生命周期的变化。

所以 ViewModel 的出现是为了简化生命周期处理的，如果你有数据需要在 Activity 中显示，则可以把数据定义到 ViewModel 中，通过 ViewModel 来管理和存储 UI 相关的数据，这样当 Activity 配置改变的时候您的数据依然存在，比如 当屏幕从横屏变为竖屏，你当前 Activity 的数据依然存在。

LiveData 

把数据保存到 ViewModel 中就可以保持数据在配置改变的时候依然存在，但是如果数据发生变化了，我们如何通知 UI 去更新界面呢？如果 数据是来至于其他地方的并且请求数据需要消耗资源，如果确保只有在对用户有意义的生命周期阶段才执行请求数据的操作呢？这个时候就需要 LiveData 了。

LiveData 是用来保存数据的，里面可以保存一个数据对象并且该数据是可以被检测的同时 LiveData 的 Live 说明 LiveData 会自动处理生命周期事件，只有当 Lifecycle 处于 STARTED 或者 RESUMED 状态的时候才认为是活动状态。比如你在请求一个图片，如果用户点击返回键退出了应用，则 LiveData 处于非活动状态，这个时候你就可以取消继续请求图片的操作了。

所以 LiveData 和 ViewModel 是 Lifecycle 的有利补充。

    LiveData 是一个可被观察的数据持有者（用到了观察者模式）。其能够允许 Activity, Fragment 等应用程序组件对其进行观察，并且不会在它们之间创建强依赖。LiveData 还能够自动响应各组件的声明周期事件，防止内存泄漏，从而使应用程序不会消耗更多的内存。

    注意：LiveData 和 RxJava 或 Agera 的区别主要在于 LiveData 自动帮助处理了生命周期事件，避免了内存泄漏。

数据持久化

不支持离线的应用不是一个用户体验良好的应用，用户手机网络的变化是不可预知的，特别是现在复杂的社会环境，比如做地铁到地下隧道了，手机没信号了，这个时候你正在浏览微博，看到一个有趣的消息想去点赞，点了一个赞微博应用就在哪里转圈，阻止你去看其他信息。一直等到出隧道恢复信号了才能点赞成功。如果你在隧道的时间比较长，则你一定感觉不爽。 如果应用支持离线使用，点赞的时候，应用把点赞的操作持久化到本地，然后你还可以继续浏览其他本地已经缓存的消息，当手机恢复网络的时候，应用自动把之前的点赞操作同步到服务器，这种体验肯定要好很多。

所以数据持久化是一个比较重要的功能，要保存复杂的数据在 Android 上没有比 Sqlite 更好的方式了。而使用 Sqlite 要求大家了解 Sql 语句并且手写各种创建表和查询表的 Sql 语句，这是比较繁琐的一项任务。而 Java 早在 2001 年就出现 Hibernate 等 ORM 框架了，但是这些 ORM 框架都比较“笨重” 无法在 Android 环境下使用， 近几年也出现了一些 Android 上的 ORM 框架比如 GreenDao、Ormlite 等，而来自官方的 Room 框架风格上有点借鉴 Retrofit 的意思，也算是官方提供的一个 ORM 框架了。如果你的应用需要保存数据，则可以考虑下 Room 框架。

Room

    Room 能帮助我们方便的实现本地数据持久化，抽象出了很多常用的数据库操作，并且在编译时会验证每个查询，从而损坏的 SQL 查询只会导致编译时错误，而不是运行时崩溃。还能和上面介绍的 LiveData 完美合作，并帮开发者处理了很多线程问题。

官方推荐的 App 架构

最后的架构一图以概之看起来就像这样：

最后的最后，给出一些指导原则

下面的原则虽然不是强制性的，但根据我们的经验遵循它们能使您的代码更健壮、可测试和可维护的。

• 所有您在 manifest 中定义的组件 - activity, service, broadcast receiver... 都不是数据源。因为每个组件的生命周期都相当短，并取决于当前用户与设备的交互和系统的运行状况。简单来说，这些组件都不应当作为应用的数据源。

• 在您应用的各个模块之间建立明确的责任边界。比如，不要将与数据缓存无关的代码放在同一个类中。

• 每个模块尽可能少的暴露内部实现。从过去的经验来看，千万不要为了一时的方便而直接将大量的内部实现暴露出去。这会让你在以后承担很重的技术债务（很难更换新技术）。

• 在您定义模块间交互时，请考虑如何使每个模块尽量隔离，通过设计良好的 API 来进行交互。

• 您应用的核心应该是能让它脱颖而出的某些东西。不要浪费时间重复造轮子或一次次编写同样的模板代码。相反，应当集中精力在使您的应用独一无二，而将一些重复的工作交给这里介绍的 Android Architecture Components 或其他优秀的库。

• 尽可能持久化数据，以便您的应用在脱机模式下依然可用。虽然您可能享受着快捷的网络，但您的用户可能不会。

本文不再贴相关代码，具体各个库的使用请查看官方文档：https://developer.android.com/topic/libraries/architecture/guide.html

附上官方的DEMO项目：https://github.com/googlesamples/android-architecture-components