1. 为什么要架构设计？
架构设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。最终目的是提高程序开发的效率，更好的进行测试。当然设计不能违背初衷，对于不同量级的工程，具体架构的实现方式必然是不同的，所以对架构要因地适宜，不要为了用它而用它。
2. 如何选择架构？
MVC
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
- 视图（View）：用户界面
- 控制器（Controller）：业务逻辑
- 模型（Model）：数据保存
各部分之间的通信方式如下，所有通信都是单向的。
- View 传送指令到Controller
- Controller完成业务逻辑后，要求Model改变状态
Model将新的数据发送到View，用户得到反馈
优点
- 把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了（Swappable Controller）。
- 观察者模式可以做到多视图同时更新。
缺点
- Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。
- View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的
- 随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿
MVP
MVP模式将Controller改名为Presenter，同时改变了通信方向
- View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)。
- Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)。
- Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。
- 各部分之间的通信，都是双向的。
View interface:需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试。
优点
- 模型与视图完全分离，修改视图而不影响模型；
- 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
- 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
- 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
- 协同工作（例如在设计师没出图之前可以先写一些业务逻辑代码或者其他人接手代码改起来比较容易）
缺点
- Presente层与View层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化;粒度太大，解耦效果不好。因为View定义的方法并不一定全部要用到，可能只是后面要用到先定义出来（后面要不要删也未知），而且如果后面有些方法要删改，Presenter和Activity都要删改，比较麻烦；
- V层与P层还是有一定的耦合度。一旦V层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变，牵一发而动全身。如果这一层也能解耦就更好了。
- 复杂的业务同时也可能会导致P层太大，代码臃肿的问题依然不能解决，这已经不是接口粒度把控的问题了，一旦业务逻辑越来越多，View定义的方法越来越多，会造成Activity和Fragment实现的方法越来越多，依然臃肿。
MVVM
MVVM模式将Presenter改名为ViewModel，基本与MVP模式完全一致。唯一的区别是，它采用双向绑定（data-binding）：可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。如图
优点
- View与Presenter的耦合强于View与ViewModel的耦合
- View仅是ViewModel的消费者, 当修改UI时,不修改ViewModel.
- 根据业务关注点, 创建多个高内聚的View与ViewModel, 允许多个页面共享与替换.
- 彻底分离UI逻辑, 使用DataBinding分离UI显示与UI逻辑.
- View与ViewModel一对多, ViewModel与Model多对多.
- ViewModel和Model与UI界面完全解耦, 进一步提高可测试性.
缺点
- 过于简单的图形界面不适用，或说牛刀杀鸡。
- 对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。
- 数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。
3. 发展过程
MVC -> MVP -> MVVM 一步步演化发展，MVP中 P 是直接调用 View 的接口来实现对视图的操作，View 接口一般来说是 showData、showLoading等。M MVVM进一步使代码优雅简洁，运用 Data Binding， 重构showData等View接口 。
相同点
- Model：Model不依赖于View的实现，只要外部程序调用Model的接口就能够实现对数据的增删改查。
- View：UI层，UI展现代码及一些相关的界面逻辑代码。
不同点
- Controller
Controller接收View的操作事件，根据事件不同，或者调用Model的接口进行数据操作，或者进行View的跳转，从而也意味着一个Controller可以对应多个View。Controller对View的实现不太关心，只会被动地接收，Model的数据变更不通过Controller直接通知View，通常View采用观察者模式监听Model的变化。
- Presenter
Presenter与Controller一样，接收View的命令，对Model进行操作；与Controller不同的是Presenter会反作用于View，Model的变更通知首先被Presenter获得，然后Presenter再去更新View。一个Presenter只对应于一个View。根据Presenter和View对逻辑代码分担的程度不同，这种模式又有两种情况：Passive View和Supervisor Controller。
- ViewModel
注意这里的“Model”指的是View的Model，和MVVM中的Model不同，View的Model包含View的一些数据属性和操作，这种模式的关键技术就是数据绑定（data binding），View的变化会直接影响ViewModel，ViewModel的变化或者内容也会直接体现在View上。这种模式实际上是框架替应用开发者做了一些工作，开发者只需要较少的代码就能实现比较复杂的交互。