一、MVC、MVP、MVVM的简单比较
MVC，MVP，MVVM是三个不同时期出现的架构模式，他们之间非常相似，可以说是相互继承关系，这里简单介绍一下：
MVC：Model-View-Controller，特点是三者之间互相依赖，优点就是简单，逻辑线性，代码组织简单。缺点也是简单， 逻辑不够抽象，代码组织简单，耦合过高不好维护，很容易出现需求变化的时候哪里都要改的情况。
MVP：Model-View-Presenter，特点是Model和View相互之间不依赖，两者通过Presenter进行通信。优点比起MVC来说解耦程度更高一些，各自更专注自己的职能。缺点是不同项目间MVP的实现不一，Presenter层可能承载过多代码。同时MVP对定义的接口依赖更重，如果接口业务修改了，也容易出现需求变化的多个地方需要修改的情况。
MVVM：Model-View-ViewModel，特点是View和ViewModel通过数据进行双向绑定，使得开发者在维护的过程中主要集中在ViewModel和Model之间的交互。优点是实现更加解耦的同时，减少了对接口的依赖。这是面向数据开发和面向接口开发的区别。缺点是各层之间的抽象程度加高，要求开发人员对整体架构的把控力。
实际上来说，MVVM和MVP是很像的。p层和vm层做的事情很类似，区别在于MVP是面向接口编程，MVVM是面向数据编程。
二、Android应用 简单MVVM架构
值得注意的是，MVVM代表的是一种代码架构思想，即使你不用任何的第三方框架，同样可以写出MVVM架构的Android应用。所以从实际的代码来看，以及综合Google官方的推荐，我认为M-V-VM并不足以说明各个层次的代码职能。下面我以一个类HelloWorld例子来进行示例。
一个空白的页面中间有一个TextView，显示着HelloWorld。你需要隔一段时间请求一次网络获取最新文本，有变化的情况修改这个TextWiew的显示内容。对应的代码架构如下：
基于这个模型，jetpack的各种框架都可以热插拔按需进行。你可以使用kotlin-android-extensions，ButterKnife来替代控件绑定部分，也可以使用DataBinding来替代整个绑定的部分，可以使用LiveData的形式来替代数据绑定的部分等等。
如果使用MVP的代码架构，对应的各层之间的联系，就被Contract代替了。可以说这就是面向数据和面向接口的实质区别。
