一、MVC
MVC的全称是Model-View-Controller，也就是模型-视图-控制器。
在Android中View层一般由XML布局文件充当。在Model层中我们会进行一些数据处理的工作，比如网络数据请求、数据库操作等。Controller层通常由Activity、Fragment充当，并在其中进行界面、数据相关的业务处理。
可见在Android中，作为Controller的Activity或Fragment主要起到的作用就是解耦，将View和Model进行分离，两者在Activity中完成具体的操作。
下图是MVC架构的结构模型：
从图中可以看出，MVC的耦合性还是相对较高的，View和Model之间可以互相访问，导致三者间构成回路，同时核心的业务逻辑都写在Controller中，导致Controller中的代码略显臃肿，这也是我们开发中使用MVC模式所面对的问题，Activity或Fragment中的业务逻辑代码代码少则几百行多则上千行。
二、MVP
MVP是MVC架构的一个演化版，全称是Model-View-Presenter。
和MVC架构相比，MVP架构在Android中场景应该是这样的，Model层同样提供数据操作的功能，但View层的职责由Activity、Fragment、或某个View控件担任，最后Presenter层作为View层和Model层沟通的中介。
通常在View层中，有一个Presenter成员变量，同时我们的View（可以是Activity、Fragment）需要实现一个接口，这样可以将View层中需要的业务逻辑操作通过该接口转交给Presenter来实现，进而Presenter通过Model得到相应的数据，并通过View层实现的接口返回到View中。这样View层和Model层的耦合就解除了，同时也将业务逻辑从View中抽离出来，转移到Presenter中，避免了Activity或Fragment过度臃肿，充斥大量业务逻辑代码。
MVP的结构模型如下：
从图中可以看出，MVP架构中，解除了View和Model间的耦合，使它们不能相互访问，核心的业务逻辑都集中在Presenter中。
随着产品的升级，UI会添加新的设计，业务逻辑也会更改，在MVC架构中，我们需要在View层处理这些变化，可是面对成百上千的代码，也是挺烦的。使用MVP架构能很好的降低View的复杂性，将业务逻辑分离到Prestener，它们之间通过接口通信，处理变化时只需要根据情况来扩展接口并在Prestener处理新的业务逻辑即可。
所以可以看出，MVP架构还是相当优良的，对于相对大的项目，它能够很好的组织处理应用的结构，使应用更加易于扩展、更加灵活。如果应用相对简单的话，使用MVP架构就相对复杂麻烦，有点小题大做的感觉。
关于MVP的例子，可参考这里：https://github.com/Othershe/NiceRead
三、MVVM
MVVM的结构模型如下：
可以发现，MVVM与MVP的结构还是很相似的，在MVVM中，View层和Model层进行了双向绑定（即Data Binding），所以Model数据的更改会表现在View上，反之亦然。ViewModel就是用来根据具体情况处理View或Model的变化。
Google自家的MVVM(Data Binding)，可以看这里https://github.com/LyndonChin/MasteringAndroidDataBinding
工作原理和我们Android中的Adapter有些类似，可以这样想象一下，在使用RecyclerView时，Adapter扮演ViewModel的角色，RecyclerView当然是View的角色、数据集合则是Model的角色，当数据集发生变化时，我们会调用Adapter类的notifyXXX()方法，RecyclerView列表就会得到更新，如果RecyclerView列表是可编辑的，例如删除Item等，这些操作也是会影响原始数据集的。所以ViewModel就是View和Model之间沟通的桥梁，解决了View和Model之间的耦合问题，让操作变得更加灵活、方便。
