MVP、MVVM是Android程序猿们没少接触的东西，关于它们的框架、文章也是非常多的。但是，几乎所有的框架和文章，都是只基于Java实现的，而在Kotlin成为Android首先开发语言的当下，Kotlin的特性与MVP、MVVM配合之后，发生的神奇反应，绝对会让你重新认识MVP和MVVM！
0.操作拆分
首先，我们将一个操作拆分成以下步骤来讲解一下从MVC到MVP，再到MVVM的演化过程。
1.用户点击屏幕。
2.显示等待框。
3.启动后台线程加载数据。
4.关闭等待框。
5.加载数据结果。
1.MVC (Model-View-Controller)
我们将MVC的各个角色代入到以上步骤中：
1.用户操作View产生指令。
2.Controller接收到指令，通知View显示等待框。
3.Controller通过Model获取数据。
4.Model将结果传递给View，并关闭等待框。
5.View加载数据结果。
可以发现，显示等待框的可能是Controller，也可能是Model。并且Model传递数据时，可能传递给Controller，也可能直接传递给View。这就是人人学写代码时就会使用的MVC架构。
画成图就是这样：
在MVC中，每个界面有一套自己的Model-View-Controller，多个界面之间无法复用其它界面的元素。比如，在两个不同的界面中访问相同的网络接口，甚至要写两遍相同的代码。
优点：对于小项目来讲，简单易用，学习成本低。
缺点：高耦合；复用性低；不易做单元测试；项目过大时，代码非常混乱。
2.MVP(Model-View-Presenter)
把MVC中各角色的职责划分开来，让Model与View不能直接相互访问，并且始终通过中间层来访问，就是我们常用的MVP架构了。
将MVP的各个角色代入后的调用过程：
1.用户操作View产生指令。
2.Presenter接收到指令，通知View显示等待框。
3.Presenter调用Model获取数据。
4.Model将结果传递给Presenter，然后由Presenter通知View关闭等待框，并将数据传递给View。
5.View加载数据结果。
画成图就是这样：
在MVP中，View与Model都是负责原子性的操作，由Presenter将它们的动作连接起来完成一个完整的流程，在大多数MVP框架中，1个界面实现1个View，每个View持有一个Presenter，每个Presenter持有多个Model，由此来实现Model的复用。它们的关系图如下：
