Android架构设计演变史

原文链接：【译】Android应用架构

天外飞仙

Android开发生态圈的节奏非常之快。每周都会有新的工具诞生，类库的更新，博客的发表以及技术探讨。如果你外出度假一个月，当你回来的时候可能已经发布了新版本的Support Library或者Play Services。

曾经架构

追溯到2012年我们的代码库使用的是基本结构，那个时候我们没有使用任何第三方网络类库，而且AsyncTask也是我们的好朋友。当时的架构可以大致表示为下图。

MV模式

交互步骤：

1. View Layer（视图层）职责是处理并将数据展示在UI上。
2. Data Layer（数据层）负责从REST API或者持久数据存储区检索和存储数据。
3. APIProvider提供了一些方法，使Activity和Fragment能够很容易的实现与REST API的数据交互。这些方法使用URLConnection和AsyncTask在一个单独的线程内执行网络请求，然后通过回调将结果返回给Activity。
4. CacheProvider 所包含的方法负责从SharedPreferences和SQLite数据库检索和存储数据。同样使用回调的方式，将结果传回Activity。

存在问题：

1. 使用这种结构，最主要的问题在于View Layer持有太多的职责。
2. 如果继续添加复杂的业务逻辑，这种架构就会陷入众所周知的Callback Hell（回调地狱，多层嵌套的回调）。

模式总结：

1. Activitty和Fragment变得非常庞大并且难以维护。
2. 太多的回调嵌套意味着丑陋的代码结构而且不易读懂和理解。后期修改痛苦。
3. 单元测试变得非常有挑战性，逻辑扎推，比较艰难。

RxJava驱动的新型架构

响应式编程：

1. 一个数据流是一个按时间排序的即将发生的事件(Ongoing events ordered in time)的序列。如一个某种类型的值事件，一个错误事件和一个完成事件。监听跟点击事件一样的数据流，并做出相应的反应。
2. 监听这个事件流的过程叫做订阅，我们定义的函数叫做观察者，而事件流就可以叫做被观察者。
3. 在常用的响应式库中，每个事件流都会附有一些函数，例如 map, filter, scan等，当你调用这其中的一个方法时，比如clickStream.map(f)，它会返回基于点击事件流的一个新事件流。它不会对原来的点击事件流做任何的修改。这种特性叫做不可变性(immutability)，而且它可以和响应式事件流搭配在一起使用，就像豆浆和油条一样完美的搭配。(几乎)一切都可以成为一个事件流，这就是Rx的准则(mantra)。

简而言之：

RxJava允许通过异步流的方式处理数据，并且提供了很多操作符，你可以将这些操作符作用于流上从而实现转换，过滤或者合并数据等操作。新型的架构可以大致表示为下图。

交互步骤：

1. Activity和Fragment要做的就是展示已经准备好的数据而不需要再进行转换了。
2. DataManager是整个架构中的大脑。它广泛的使用了RxJava的操作符用来合并，过滤和转换从帮助类中返回的数据。
3. Helper classes（图标中的第三列）有着非常特殊的职责以及简洁的实现方式。对数据crud。
4. Event Bus（事件总线）允许我们在Data Layer中发送事件，以便View Layer中的多个组件都能够订阅到这些事件。如登录状态变化。

架构优势：

1. RxJava的Observable和操作符避免了嵌套回调的出现。
2. DataManager接管了以前View Layer的部分职责。
3. 将代码从Activity和Fragment转移到了DataManager和帮助类中，就意味着使写单元测试变得更简单。
4. 明确的职责分离和DataManager作为唯一与Data Layer进行交互的点，使这个架构变得Test-Friendly。

存在问题：

1. 对于庞大和复杂的项目来讲，DataManager会变得非常的臃肿和难以维护。
2. 尽管View Layer诸如Activity和Fragment等组件变得更轻量，它们仍然要处理大量的逻辑，如管理RxJava的订阅，解析错误等方面。

MVP模式

简而言之：

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。

交互步骤：

1. 各部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter 传递。
3. View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

架构优势：

1. Activity和Fragment变得非常轻量。他们唯一的职责就是建立/更新UI和处理用户事件。现在我们通过模拟View Layer可以很容易的编写出单元测试。
2. 如果DataManager变得臃肿，我们可以通过转移一些代码到Presenter来缓解这个问题。

存在问题：

1. 当代码库变得非常庞大和复杂时，单一的DataManager依然是一个问题。

MVVM模式

简而言之：

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

交互步骤：

1. 只ViewModel 和 Model 间的通信是双向的。
2. View 与 Model 不发生联系，都通过 ViewModel传递。
3. View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而ViewModel非常厚，所有逻辑都部署在那里。

架构优势：

1. 它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel。
2. ViewModel作为View的数据映射，通常View上有什么属性，ViewModel上也会存在相应的一个属性，这两个属性通过事件实现了双向的绑定，Data Binding Library 替我们完成了这样的绑定过程。

饭后小茶

1. 值得一提的是它们并不是一个完美的架构。事实上，不要天真的认为这是一个独特且完美的方案，能够解决你所有的问题。Android生态系统将保持快速发展的步伐，我们必须继续探索。不断地阅读和尝试，这样我们才能找到更好的办法来继续构建优秀的Android应用程序。
2. 最后感谢所有对 “Android架构设计演变史”提供资料的作者们，谢谢你们的辛勤付出，么么哒！