MVP设计架构

MVP是一种使用广泛的基础架构模式，使用基于事件驱动的应用框架。MVP从更早的MVC框架演变过来的一种框架，与MVC有一定的相似性。

具体到Android App中，一般可以将App根据程序的结构进行纵向划分，根据MVP可以将App分别为模型层(M)，UI层(V)和逻辑层(P)。

UI层一般包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动之后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，两者之间的通信通过BroadCast、Handler或者接口完成，只传递事件和结果。

举例： UI层通知逻辑层（Presenter）用户点击了一个Button，逻辑层（Presenter）自己决定应该用什么行为进行响应，该找哪个模型（Model）去做这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。

MVP框架由3部分组成：View负责显示，Presenter负责逻辑处理，Model提供数据。在MVP模式里通常包含3个要素（加上View interface是4个）：

• View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)

• Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)

• Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。

• View interface:需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试。这是非必需的

MVP的优点

1、模型与视图完全分离，我们可以修改视图而不影响模型；

2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；

3、我们可以将一个Presenter用于多个视图（将视图A改变为视图B），而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；

4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

MVP的变种：Passive View

MVP的变种有很多，其中使用最广泛的是Passive View模式，即被动视图。
在这种模式下，整个框架内部模块之间的逻辑操作均由Presenter控制，View仅仅是整个操作的汇报者和结果接收者

• View和Model之间不能直接交互，View通过Presenter与Model打交道。Presenter接受View的UI请求，完成简单的UI处理逻辑，并调用Model进行业务处理，并调用View将相应的结果反映出来。View直接依赖Presenter，

• 但是Presenter间接依赖View，它直接依赖的是View实现的接口。

Passive View模式的基本特征总结

Passive View，顾名思义，View是被动的。那么主动是谁呢？答案是Presenter。对于Presenter的主动性，我个人是这么理解的：

• Presenter是整个MVP体系的控制中心，而不是单纯的处理View请求的人；

• View仅仅是用户交互请求的汇报者，对于响应用户交互相关的逻辑和流程，View不参与决策，真正的决策者是Presenter；

• View向Presenter发送用户交互请求应该采用这样的口吻：“我现在将用户交互请求发送给你，你看着办，需要我的时候我会协助你”，不应该是这样：“我现在处理用户交互请求了，我知道该怎么办，但是我需要你的支持，因为实现业务逻辑的Model只信任你”；

• 对于绑定到View上的数据，不应该是View从Presenter上“拉”回来的，应该是Presenter主动“推”给View的；

• View尽可能不维护数据状态，因为其本身仅仅实现单纯的、独立的UI操作； Presenter才是整个体系的协调者，它根据处理用于交互的逻辑给View和Model安排工作。