MVC，MVP，MVVM都是为了解决UI页面与逻辑代码分离而出现的模式，MVP和MVVM都是MVC的基础上演化而来
MVC：
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写
M——模型层（Model）负责处理数据的加载或者存储
V——视图层（View）负责界面数据的展示，与用户进行交互
C——控制器层（Controller）负责逻辑业务的处理
MVC关系图
在MVC模式中，View层可以直接访问Model层和Controller层，所以View层包含Model层信息和Controller层的业务逻辑处理
在MVC模式中，Model层不依赖View层，但是View层依赖Model层，导致更改View层比较困难
优点：
耦合性低，生命周期成本低，部署快，可维护性高，适用于快速开发的小型项目
缺点：
不适合大型，中等项目，View层Controller层连接过于紧密
View层对Model层的访问效率低
一般的高级UI页面工具和构造器不支持MVC模式
注意：
Activity和Fragment既有View的性质，又具有Controller的性质，导致Acyivity和Fragment很重
MVC中View层与Model层直接交互，所以Activity和Fragment与Model的耦合性很高
MVP：
MVC全名是Model View Controller，是模型(mV----odel)－视图(view)－控制器(controller)的缩写
M——数据层（Model）负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等
V——视图层（View）负责对数据的展示，提供友好的界面与用户进行交互，Android通常将Activity或者Fragment作为View层
C——控制器层（Controller）连接View层与Model层的桥梁并对业务逻辑进行处理
MVP关系图
MVP模式将MVC中的Controller换成Presenter，同时改变了通信方向。
View与Model隔离，Presenter负责完成View层与Model层的交互。
MVP执行流程：
View层收到用户的操作
View层把用户的操作交给Presenter
Presenter直接操作Model层进行业务逻辑处理
Model层处理完毕后，通知Presenter
Presenter收到通知后，去更新View层
在MVP模式中，Model与View无法直接进行交互，所以Presenter层会从Model层获得数据，适当处理后交给View层进行显示
在MVP模式中，Presenter层将View层和Model层进行隔离，使View和Model之间不存在耦合，同时将业务逻辑从View层剥离
优点：
模型与视图完全分离，修改View而不Model
可以更高效的使用Model，所有的交互都发生在——Presenter内部
将一个Presenter用于多个视图，而不需要改变Presenter的逻辑，View变化比Model变化频繁
逻辑结构清晰，View层代码不再臃肿
缺点：
MVP模式基于接口设计，会增加很多类，代码逻辑虽然清晰，但代码量庞大
MVP适用于中小型项目，大型项目慎用
MVC和MVP的主要区别：
MVP中View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互
MVP中Controller是基于行为的，并且可以被多个View共享，Controller可以负责决定显示哪个View
MVP中Presenter与View的交互是通过接口来进行的，更有利于添加单元测试。
MVC中View可以与Model直接交互，通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑
注意：
MVP中将这三层分别抽象到各自的接口当中，通过接口将层次之间进行隔离
Presenter对View和Model的相互依赖也是依赖于各自的接口，符合了接口隔离原则
Presenter层中包含了一个View接口，并且依赖于Model接口，从而将Model层与View层联系在一起
View层会持有一个Presenter成员变量并且只保留对Presenter接口的调用，具体业务逻辑全部交由Presenter接口实现类中处理。
MVVM：
MVVM 即 Model-View-ViewModel
M——Model（模型）实体模型，定义实体类，获取业务数据模型，如通过数据库或者网络来操作数据等
V——View（视图）布局文件(XML），主要进行控件的初始化设置
VM——ViewModel（控制器）：连接 View 与 Model 的中间桥梁，ViewModel 与 Model 直接交互，通过DataBinding将数据变化反应给View
注：ViewModel可以理解为View与Presenter的合成体
优点：
结构清晰，职责划分清晰
模块间充分解耦
在 MVP 的基础上，MVVM 把 View 和 ViewModel 也进行了解耦
低耦合
MVVM 模式中，数据处理逻辑是独立于 UI 层的
ViewModel 只负责提供数据和处理数据，不会持有 View 层的引用
View 层只负责对数据变化的监听，不会处理任何跟数据相关的逻辑
View 层的 UI 发生变化时，也不需要像 MVP 模式那样修改对应接口和方法实现，一般情况下ViewModel 不需要做太多的改动
数据驱动
UI 的展现是依赖于数据的，数据的变化会自然的引发 UI 的变化，而 UI 的改变也会使数据 Model 进行对应的更新
ViewModel 只需要处理数据，而 View 层只需要监听并使用数据进行 UI 更新
异步线程更新Model
Model 数据可以在异步线程中发生变化，此时调用者不需要做额外的处理
数据绑定框架会将异步线程中数据的变化通知到 UI 线程中交给 View去更新
方便协作
View 层和逻辑层几乎没有耦合，在团队协作的过程中，可以一个人负责 UI，一个人负责数据处理。并行开发，保证开发进度
易于单元测试
ViewModel 层只负责处理数据，在进行单元测试时，测试不需要构造一个 fragment/Activity/TextView 等来进行数据层的测试
View 层也一样，只需要输入指定格式的数据即可进行测试，而且两者相互独立，不会互相影响
数据复用
ViewModel 层对数据的获取和处理逻辑，尤其是使用 Repository 模式时，获取数据的逻辑完全是可以复用的
开发者可以在不同的模块，多次方便的获取同一份来源的数据
同样的一份数据，在版本功能迭代时，逻辑层不需要改变，只需要改变 View 层即可
