我们在Android开发中为了更好的保持代码的可测试、可维护和可扩展性，产生了很多架构模式，例如MVC、MVP、MVVM等等，下面我们来看看这些架构模式
MVC
示意图：
M:Model数据模型，包含数据以及负责数据存取
V:View视图，xml布局以及自定义view
C:Controller控制器（Activity/Fragment)，负责具体业务逻辑
在最早android开发初期，我们会将业务逻辑和数据都放到Activity中处理，但是并没有做分层处理，Activity/Fragment作为Controller即负责业务逻辑又处理UI更新，因此随着迭代开发Controller会急速膨胀，并且不利于测试、维护和扩展
MVP
为了解决MVC的痛点，MVP架构模式开始被广泛使用，示意图：
M:类比MVC的Model
V:View视图，包含Activity/Fragment，xml 布局
P:Presenter中间人角色，持有View和Model，负责业务逻辑以及两者之间的通信，使M和V实现了解耦
MVP解决了MVC耦合性强，不利于测试、维护和扩展的问题，但是MVP也有自己的问题。首先，P持有V的引用如果使用不当容易导致泄漏，在就是P和V通常是1:1比例存在，随着业务复杂度提升也使P会急速膨胀。另外虽然MVP对M和V进行解耦但是P和V还是强耦合的
MVVM
为了解决MVP存在的问题，MVVM被广泛使用，示意图：
M:Model类比MVC/MVP
V:View类比MVC/MVP
VM:ViewModel类比MVP的Presenter，负责Model和View交互，但它不持有View而是通过观察者模式进行回调通知(数据绑定)
MVVM的ViewModel不持有View解决了MVP中V和P强耦合的问题，一个Activity可以持有多个ViewModel，多个Activity也可以共用一个ViewModel提高了代码的复用性，减少了代码膨胀问题，MVP虽然也可以做类似的处理但是因为V和P的强耦合性会带来复杂度和维护成本几何数的提升所以通常MVP中几乎没人这么干。
注意：
MVVM的ViewMode和Android的ViewModel不是一个概念，Android的ViewMode是一个数据持有类在设备配置改变例如屏幕旋转时数据不会丢失
MVVM最早是微软提出的双向绑定也是它的特性，Android也推出了databinding来实现双向绑定，但是广大开发者并不喜欢因此目前流行的android MVVM架构是通过LiveData实现的单向绑定
通用架构原则
android官网介绍了通用架构原则有两点
- 分离关注点
- 通过数据模型驱动页面
分离关注点：
简单说就是分层每一层遵循单一职责原则，通过分离关注点可提高代码的可测试性、维护性和扩展性
数据驱动页面：
通过数据驱动页面（最好是持久性数据），独立于页面元素和其他组件，与生命周期没有关联，更便于测试、更稳定可靠
总结
架构模式从被提出到前后端各自演变过程中出现了很多变种，各个版本是否正统也存在一些争议，本文讨论是基于Android端的架构实现，google在推荐架构中也规避相关架构概念名词也是为了避免给大家带来误解和争议，在明白各个架构概念后，互相讨论时能明白对方在说什么就OK了，不用刻意钻牛角尖。
参考：