一开始是没有分层设计的概念的，直到后来出现了图形界面。
MVC起源
图形界面的出现，使交互方式相比之前的命令行发生了根本的改变：用户操作界面去触发程序内部处理的逻辑，然后将处理的结果反馈到界面上。这样，才促使了分层思想的出现。
分层的本质是为了解耦。在开发过程中，我们不希望在更改界面样式的时候会影响到业务代码，同理，在修改业务的同时波及到了界面的代码。
MVC很好的解决了这种场景。
MVC将代码分成三层，分别是： M（Model）层，代表数据模型；V（View）层，代表视图；C（Controller）层，代表控制层。
在MVC架构的程序中，View层接收到用户的操作之后，将其传递给Controller层，Controller层处理完成后更改Model层，然后Model层通知View层去更新界面。如下图所示：
而在Android中，我们平时创建的工程就是标准的MVC分层：其中layout布局文件代表View层，Activity就代表Controller层，Model层就是我们为业务创建的数据模型。
但是这样会出现一个问题，由于布局文件代表的View层功能太弱，部分View层的功能是在Activity中实现的。这样，Activity既充当了Controller层，又充当了View层，并没有很好的实践MVC思想。而且由于Activity在Android应用中的特殊性，充当Controller层容易造成其自身回收不及时，导致内存泄漏等问题。
MVP传承
MVP与MVC一脉相承，从字面上看，仅仅是将C改成了P。其中，P代表Persenter，它与MVC中的Controller功能类似。尽管这样，MVP和MVC还有一个本质的区别：
在MVP中，Model层是与View层完全解耦的，它们通过Presenter层来完成通讯。如下图所示：
这里，Activity充当的View层，接收到用户的操作后，将其传递给Presenter层；Presenter层根据具体业务去操作处理Model之后，拿到更新后的Model，然后再去通知View层更新界面。
所以在Android中，MVP解决了MVC中Activity职责不单一的情况，并且使View层与Model层完全解耦，比MVC有着更良好的实践。
MVVM
在Android中，MVVM的实现，还得依赖于谷歌发布的DataBinding框架。
DataBinding框架实现了布局中控件与应用中数据的双向绑定，其中任何一方的修改，都能直接反应在另一方身上。这样，在MVVM中，布局文件又重新充当起View层，与ViewModel层进行双向绑定；而ViewModel通过具体的业务去操作处理Model层，并将自身的变化反应到View层，如下图所示：
