背景
设计模式（Design pattern）：是一套被反复使用、多数人知道的、经过分类编目的、代码设计经验的总结。从定义上看，它涉及到了代码级别，侧重于解决实际的、现实的问题。
比如，应该如何如何为不同的商品设计折扣方式，采用策略模式。
框架（Framework）：是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法；另一种定义认为，框架是可被应用开发者定制的应用骨架。
前者是从应用方面而后者是从目的方面给出的定义。
架构模式：描述软件系统里的基本结构组织或纲要。架构模式提供一些定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
软件架构：是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。
架构模式
随着移动端的飞速发展，产生了一些问题：
- 移动端App中业务逻辑越来越复杂，用户渴望更好的体验及更新颖的功能
- 不断地迭代让项目结构复杂化，维护成本越来越高
所以，需要一个良好的架构模式，拆分视图和数据，解除模块之间的耦合，提高模块内部的聚合度。
MVC
MVC 对应 Model、View、Controller。
- Model（数据层）：负责管理业务逻辑和处理网络或数据库API。数据访问（数据库、文件、网络）、缓存（图片、文件等）、配置文件等
- View（视图层）：让数据层的数据可视化。数据展示与管理、用户交互、UI组件的绘制、列表Adapter等
- Controller（逻辑层）：获得用户行为的通知，并根据需要更新 Model。初始化配置（定义全局变量等）、数据加工（加工成UI层需要的数据）、数据变化的通知机制等
MVC 的 Model 不只是代表一个实体模型，还应该包含大量的业务逻辑处理。
MVC 的优势
Model 类没有对 Android 类的任何引用，因此可以直接进行单元测试。Controller 不会扩展或实现任何 Android 类，并且应该引用 View 的接口类。
通过这种方式，也可以对控制器进行单元测试。
MVC 模式高度支持职责分离，这个优势不仅增加了代码的可测试性，而且使其更容易扩展，从而可以相当容易地实现功能。
MVC 容易产生的问题
代码相对冗余。MVC 中 View 对 Model 是有着强依赖的。当 View 非常复杂时，为了最小化 View 中的逻辑，Model 应该能够为要显示的每个视图提供可测试的方法–这将增加大量的类和方法
灵活性较低。由于 View 依赖于 Controller 和 Model，UI 逻辑中的一个更改可能导致需要修改很多类，这降低了灵活性，并且导致UI难以测试。
可维护性低。Android 的视图组件中，有非常明显的生命周期。对于 MVC 模式，有时不得不将处理视图逻辑的代码都写在这些组件中，造成臃肿。
所以，Android 中的 MVC 架构模式问题显而易见：过于臃肿的 Controller 层大大降低了工程的可维护性及可测试性。
MVP
MVP 分别对应 Model、View、Presenter。
- Model（数据层）：负责管理业务逻辑和处理网络或数据库API。
- View（视图层）：显示数据并将用户操作的信息通知给 Presenter。
- Presenter（逻辑层）：从 Model 中检索数据，应用UI逻辑并管理 View 的状态，决定显示什么，以及对 View 的事件做出响应。
相对于 MVC，MVP 模式设计思路的核心是提出了 Presenter 层，它是 View 层与 Model 层沟通的桥梁，对业务逻辑进行处理。
MVP 容易产生的问题
接口粒度难以掌控。MVP 模式将模块职责进行了良好的分离。但在开发小规模App或原型时，这似乎增加了开销。
Presenter 逻辑容易过重。当将UI的逻辑移动到 Presenter 中时，Presenter 变成了有数千行代码的类，或许会难以维护。
Presenter 和 View 相互引用。在 Presenter 和 View 中都会保持一份对方的引用，所以需要用 subscribe 和 unsubscribe 来绑定和解除绑定。
MVVM
维基百科：MVVM 有助于将图形用户界面的开发与业务逻辑或后端逻辑（数据模型）的开发分离开来，这是通过置标语言或GUI代码实现的。MVVM 的视图模型是一个
值转换器，这意味着视图模型负责从模型中暴露（转换）数据对象，以便轻松管理和呈现对象。在这方面，视图模型比视图做得更多，并且处理大部分视图的显示逻辑。
视图模型可以实现中介者模式，组织对视图所支持对用例集的后端逻辑的访问。
- Model（数据模型）：与 ViewModel 配合，可以获取和保存数据。
- View（视图）：将用户的动作通知给 ViewModel。
- ViewModel（视图模型）：暴露公共属性与 View 相关的数据流，通常为 Model 和 View 的绑定关系。
如果 MVP 模式意味着 Presenter 直接告诉 View 要显示的内容，那么在 MVVM 中，ViewModel 会公开 Views 可以绑定的事件流。这样，ViewModel 不再需要保持对 View 的引用，
但发挥了 Presenter 一样的作用。
View 还会通知 ViewModel 进行不同的操作。因此，MVVM 模式支持 View 和 ViewModel 之间的双向数据绑定，并且 View 和 ViewModel 之间存在多对一关系。
View 具有对 ViewModel 的引用，但 ViewModel 没有关于 View 的信息。
MVVM 容易产生的问题
需要更多精力定位Bug。由于双向绑定，视图中的异常排查起来会比较麻烦。
通用的 View 需要更好的设计。当一个 View 要变成通用组件时，该 View 对应的 Model 通常不能复用。
