MVC：
Modle-View-Controller 把一个个应用的输入，处理，输出流程按照 Modle，View，Controller进行分离
Modle:模型层 就是应用程序中的二进制数据
View:视图层 就是应用程序的界面 Android中的界面采用XML文件保存的，界面开发变得很方便
Controller：控制层 控制视图模型的数据显示
存在问题：Controller (例如activity)中存在两部分内容：
业务相关+界面相关
这样就造成V层的代码相对较少，C中代码相对较多
解决方案:
1.将Activity中的业务相关内容拆分：mvp
2.将Activity中界面相关的内容拆分：mvvm
MVP:
MODEL-VIEW-PRESENTER
拆分业务相关部分 要目的是划分模块职责,降低模块耦合,易测试,提高代码复用
Presenter: 作为Model和View的中间协调部分,负责两者之间的业务逻辑处理
View会抽象出来一系列操作UI的接口(Model层也可以),Presenter拿到的都是其他两个层级的接口来做业务逻辑的处理.这样不仅可以使View和Model之间的耦合度降低,还可以更易得进行单元测试.
MVP的优缺点
优点:降低耦合，层级职责更明显，易于单元测试
缺点:造成类数量爆炸，代码复杂度和学习成本高，在某些场景下presenter的复用会产生接口冗余
MVVM:
拆分界面相关部分
一种在Windows上已经使用多年的开发模式-Model-View-ViewModel (MVVM)。
将view和一个对象的对field绑定。当field更新的时候，framework将收到通知，同时view也会自动更新。
MVVM模式包含了三个部分：
Model – 代表你的基本业务逻辑
View – 显示内容
ViewModel – 将前面两者联系在一起的对象
一个ViewModel接口提供了两个东西：动作和数据。动作改变Model的下层（click listener，监听文字改变的listener等等），而数据则是Model的内容。
比如，为一个拍卖页面服务的ViewModel可能被作为数据呈现：item里的一张图片，标题，描述，价格。也可能作为动作呈现：投标，购买或者联系卖家。
在传统的安卓架构中，controller负责推送数据给view。在Activity中findview，然后在它上面设置内容。在MVVM中，ViewModel在改变内容之后通知binding framework内容发生了改变。然后framework自动更新和那些内容绑定的view。这两个组建只是通过ViewModel松耦合在一起。
这种设计模式之所以牛逼，除了明显智能化了的View之外，还方便了测试。
比如，在一个测试用例中，我们不将VM和一个真实的View绑定，而是直接创建一个VM，给它一些数据，然后在上面调用操作，以确保数据的变化是正确的。比如刚刚的拍卖案例中，你可以创建一个带虚拟（模拟的）API服务的VM
，让它载入任意的item然后在上面调用拍卖的行为，以确认结果数据是正确的。所有这些工作都不必和一个具体的View交互。
而在测试view的时候，我们可以创建一系列带有预先设置好数据（比如依赖于网络调用的或者数据库内容的）的模拟model，然后观察在不同的数据集合面前view是如何表现的。
但是由于框架的侵入性太强，导致一直没有流行起来。