Android 架构组件深入剖析（一）

Android 架构组件介绍

距离 Android Architecture Components 1.0 稳定版发布有一段时间了，期间使用这个框架写过几个 Demo，发现无论是从整体结构上还是设计使用细节上都非常不错。于是打算写一个系列文章去介绍 Android Architecture Components 如何使用，以及讨论一些设计细节和学习部分源代码等等。

写在Android Architecture Components之前

当第一次看到 Android Architecture Components 的介绍时，就对它十分感兴趣。主要是因为当时在开发 Android 应用程序遇到了两件很苦恼的事情：

UI操作和业务逻辑很容易掺杂在一起。

每时每刻在关心是生命周期组件（指 Fragment，Activity，Service 等，下同）的变化，很难将注意力集中在业务逻辑上。

先简单解释一下这两件事情为什么令我苦恼。

首先, 这两件事情几乎可以作为基本的开发原则，所以必要性就不必多说。

为了解决这两个问题，有很大部分的开发者（包括我）将业务逻辑独立出来，并将这些代码 “堆叠” 到一个类中，达到 “分离” 的效果。拿现在很多项目使用的 MVP 架构举个例子：将自己的业务逻辑写到 Presenter 里面，将 UI 放到操作放到 View 里面，同时 Presenter 再提供一套组件生命周期的方法供 View 来调用提醒 Presenter 生命周期发生变化，让 Presenter 也感应到生命周期，完成。很漂亮对吗？但是在我看来这样做一定程度上是一件形式大于意义的事情。

1. 这种结构有些死板。

举个例子：我们们的业务逻辑包括五项任务： A, B, C, D, E。那么一般情况下 Presenter 应该会同时给出这个五个使命在业务逻辑的对应操作的同时，还需要 View 各个生命周期的回调，就会造成下面的状态:

从代码结构角度上来看了，这样写太啰嗦了，即使我们只是想实现一个简单的需求，也需要相对大量的模板代码。如果有一个人阅读我们的代码，阅读者从代码量上就会产生一种无形的压力。同样这样的结构并不适于做敏捷开发,代码写了半天只有一个恐龙的骨架，还需要填肉进去。然而我可能只需要一只会跑的老鼠。

再从设计上：将若干个可能毫不相干的方法放到一起，很难解释 Presenter 是什么，他做的事情太杂了。 或许你没有弄明白这代表了什么，那我们简单举个例子：

我们先假设 A 是去做一个数据库查询，B 是打开 WIFI，C 是关闭 WIFI，D 是做一个简单的计算，E 是另一个简单的计算。如果是一个好的设计，我们或许要将 A 放在一类，B, C 放到一类, D, E 放到一类使得某个类专注做一件事情。这样做是有道理的，设想一个极端情况当 Presenter 有 50 种的时候,如果把代码不分门别类的放到一起，Presenter 就会变成一个杂乱的代码集合体。变得难以维护。

2. 我们依然头疼于组件的生命周期变化。

我们写 Activity 时，很容易产生与生命周期相关的问题。主要是 Manifest 中声明的类受到 AndroidOS 的控制，这样一来，如果我们的义务逻辑分为多个阶段，任何一个阶段可能都需要考虑当前 Activity 的状态。与此同时 Activity 的生命周期也有很多阶段，这样将两个本来逻辑上平行的事件中各个可能性进行一对一对接就很容易出现纰漏，一旦有所纰漏就容易出问题。

但是，在目前只有基本回调接口的情况下，像上面的示例代码。为了能够把控好生命周期。我们不得不为此在每个 onCreate 等等生命周期回调中调用提醒方法。

MVP 或者 MVVM 这些框架在各个软件平台各种规模被运用多年。已经非常成熟了。这些成熟的框架的引入的确会提高 APP 的健壮性，易维护性，可读性等（这当然要基于正确的使用）。这么成熟的体系为什么使用起来还是有这么多问题呢？我觉得一个非常重要的原因是 MVP 不知道这里是 Android， Android 有自己的运行体系，而 MVP、MVVM 是面向更宽广的开发环境，并不会为 Android 独特的体系而设定结构，导致了这种结果。那么有没有一套符合 Android特性的设计架构呢？以前没有， 现在有了，那就是 Android Architecture Components。

Android Architecture Components

Android Architecture Components 是一个谷歌官方发布的组件合集, 这些组件包括 Lifecycles、LiveData、ViewModel、Room 和 Paging。

同时 Android Architecture Components 还提供了测试工具来帮助测试 LiveData 和 Room 数据库合并的测试。

新的 Android 体系架构指南定义了一些关键原则，该指南为开发者创建优秀的 APP 提供了安全的路线。但是，该指南明确规定，所提出的路线不是强制性的，采用哪种类型的架构由开发者自己决定。根据指南，优秀的 Android APP 应该提供一个牢固的关注点隔离（separation of concerns），并且在 Model 层驱动 UI。 任何不处理 UI 或与操作系统交互的代码不应该在 Activity 或 Fragment 中，因为保持 Activity 和 Fragment 尽可能干净，可以避免许多与生命周期相关的问题。 毕竟，系统可以随时销毁掉 Activity 或 Fragment。此外，数据应该由与UI隔离和与生命周期隔离的model层来处理……

关于 Android Architecture Components 更详尽的介绍，本系列接下来将慢慢谈。从如何使用到源代码解析。并写一写我对这些框架的看法。我在使用这些框架时碰到的坑等等。

官方文档：https://d.android.com/arch

注：本文部分图片来自网络。

知其然，更要知其所以然，SealDEV 倾情出品。