MVP是一种使用广泛的基础架构模式，使用基于事件驱动的应用框架。中培伟业《Android APP开发架构应用实战培训》专家刘老师详细介绍了Android系统中的MVP架构。

MVP框架思路的由来

在App开发过程中，经常出现的问题就是某一部分的代码量过大，虽然做了模块划分和接口隔离，但也很难完全避免。从实践中看到，这更多的出现在UI部分，也就是Activity里。我曾见过2000+行以上基本不带注释的Activity，那时我的第一反应就是想吐。Activity内容过多的原因其实很好解释，因为Activity本身需要担负与用户之间的操作交互，再加上现在大部分的Activity还对整个App起到控制器的作用，这又带入了大量的逻辑代码，造成Activity的臃肿。为了解决这个问题，我们引入了MVP框架思路。

MVP架构的概念

MVP是一种使用广泛的基础架构模式，使用基于事件驱动的应用框架。MVP从更早的MVC框架演变过来的一种框架，与MVC有一定的相似性。MVP框架由3部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。MVP与MVC之间最主要的区别在控制层上，在MVP框架中，View与Model并不直接交互，所有的交互放在Presenter中；而在MVC里，View与Model会直接产生一定的交互。MVP的Presenter是框架的控制者，承担了大量的逻辑操作，而MVC的Controller更多时候承担一种转发的作用。因此在App中引入MVP的原因，是为了将此前在Activty中包含的大量逻辑操作放到控制层中，避免Activity的臃肿。MVP的变种有很多，其中使用最广泛的是Passive View模式，即被动视图。在这种模式下，整个框架内部模块之间的逻辑操作均由Presenter控制，View仅仅是整个操作的汇报者和结果接收者，Model根据Presenter的单向调用返回数据(图片来自网络)。并且MVP模式使得View与Model的耦合性更低，降低了Presenter对View的依赖，实现了关注点分离的初衷，方便开发人员的编码和测试工作。

具体到Android App中，我一般将App根据程序的结构进行纵向划分，对应MVP分别为模型层，UI层和逻辑层。UI层一般包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动之后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，两者之间的通信通过BroadCast、Handler或者接口完成，只传递事件和结果。举个简单的例子，UI层通知逻辑层（Presenter）用户点击了一个Button，逻辑层（Presenter）自己决定应该用什么行为进行响应，该找哪个模型（Model）去做这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。

MVP架构本身存在的问题

转移逻辑操作之后可能部分较为复杂的Activity内代码量还是不少，于是在分层的基础上再加入模板方法（Template Method）。具体做法是在Activity内部分层。其中最顶层为BaseActivity，不做具体显示，而是提供一些基础样式，Dialog，ActionBar在内的内容，展现给用户的Activity继承BaseActivity，重写BaseActivity预留的方法。如有必要再进行二次继承，App中Activity之间的继承次数最多不超过3次。

模型层（Model）中的整体代码量是最大的，一般由大量的Package组成，针对这部分需要做的就是在程序设计的过程中，做好模块的划分，进行接口隔离，在内部进行分层。

强化Presenter的作用，将所有逻辑操作都放在Presenter内也容易造成Presenter内的代码量过大，对于这点，我的方法是在UI层和Presenter之间设置中介者Mediator，将例如数据校验、组装在内的轻量级逻辑操作放在Mediator中；在Presenter和Model之间使用代理Proxy；通过上述两者分担一部分Presenter的逻辑操作，但整体框架的控制权还是在Presenter手中。Mediator和Proxy不是必须的，只在Presenter负担过大时才建议使用。