1.背景
之所以要谈这个话题呢是因为在开发我们英语趣配音时，我发现在Activity中有大量的代码，既进行了逻辑处理，又进行了页面处理，从MVC的角度看，Activity既是Controller，又是View，所以Activity负担过重，难以维护。所以目前我打算使用MVP的设计模式来对我们趣配音的代码进行重新的设计。
2.什么是MVP？
MVP就是Model－View－Presenter。
MVP之Model
模型这一层做的工作就是具体业务逻辑处理的实现，伴随着程序中各种数据的处理，复杂一些的就明显需要实现一个Interface来松耦合了。
MVP之View
视图这一层体现的很轻薄，负责显示数据、提供友好界面跟用户交互就行。MVP下Activity和Fragment体现在了这一 层，Activity一般也就做加载UI视图、设置监听再交由Presenter处理的一些工作。
MVP之Presenter
Presenter这一层处理着程序各种逻辑的分发，收到View层UI上的反馈命令、定时命令、系统命令等指令后分发处理逻辑交由Model层做具体的业务操作，再通过视图接口通知界面更新。
3.MVP，MVC，MVVM的比较
MVC的问题
MVP是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller，从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
MVP如何解决MVC的问题？
在MVP里，Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。而且，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！ 不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试--而不需要使用自动化的测试工具。 我们甚至可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。 在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。因此就有人提出了Presenter First的设计模式，就是根据User Story来首先设计和开发Presenter。在这个过程中，View是很简单的，能够把信息显示清楚就可以了。在后面，根据需要再随便更改View，而对Presenter没有任何的影响了。 在MVP模式里，View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接访问Model--这就是与MVC很大的不同之处。
MVP的升级，MVVM
MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。
MVC，MVP，MVVM三者之间的差别如下如所示：
对于MVVM，Google已经在 Android 中引入了 Data Binding ，但目前 Android 的 Data Binding 还是 beta，还只是 one-way单向绑定，功能上还有所欠缺、控制性也还不强，但是把它写出来还是没问题的。不过未来随着Data Binding的完善也可以试着向MVVM升级。
我的关于mvp项目地址：https://github.com/zhl3391/face
