一、MVP概念
M : Model（数据层.负责与网络层和数据库层的逻辑交互） （数据库/网络请求）
V : View（视图层/UI层：负责绘制UI元素/显示数据，与用户进行交互，并向Presenter报告用户行为） （activity）
P : Presenter （是连接Model 和 View 的桥梁，从Model拿数据, 应用到UI层, 管理UI的状态, 决定要显示什么, 响应用户的行为）（逻辑代码）
二、为什么使用MVP
之前有一个MVC模式: Model-View-Controller. 主要用来隔离UI、UI逻辑和业务逻辑
MVC模式 有两个主要的缺点: 首先, View持有Controller和Model的引用; 第二, 它没有把对UI逻辑的操作限制在单一的类里, 这个职能被Controller和View或者Model共享.
因为Android的特殊性，使得Activity对应了MVC中的V和C,同时担任两个角色，就有了类似“既当爹又当妈”的感觉，这显然就不符合软件设计原则的“单一职责”原则。但现实中是很多的APP代码中有这么的处境，特别是Androi原生的很多系统APK，某些Activity动则几千行代码。 况且，随着项目的深入发展，很多逻辑很越来越复杂，Activity处理的东西也会越来越多，代码越来越臃肿。这样一来维护起来的代价就会越来越高，这是因为View的变化会引起Controller的很多变化，反之亦然。用一句大白话来说明就是–某一段代码的变动会引起很多其他相关联的代码的改动，而程序员都是懒惰的，所以会恨死这样的代码。
而MVP就是要减轻在Android中的这种困惑。
MVP是基于MVC的，
三、为什么用MVP
任何事务都存在两面性，MVP当然也不列外，我们来看看MVP的优缺点。
优点：
- 降低耦合度，实现了Model和View真正的完全分离，可以修改View而不影响Modle
- 模块职责划分明显，层次清晰
- 提高代码的阅读性
- Presenter被抽象成接口，有多种具体的实现方式 业务逻辑在Presenter中，避免Activity造成内存泄露
- 模块职责划分明显
- 代码灵活性/提高代码复用
- 隐藏数据
- View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。
-
利于测试驱动开发。以前的Android开发是难以进行单元测试的（随着项目变得越来越复杂，没有测试是很难保证软件质量的）
缺点：
- Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。
- 由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。
- 如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。
- 额外的代码复杂度及学习成本。
四、MVP的核心思想
将Activity中的视图逻辑抽象成View接口，将业务逻辑抽象成Presenter接口
五、MVP开发在Android中的基本流程
-
View层定义View.interface，用来定义View的行为。一般由Activity或者是Fragment来实现这个接口，它定义了View视图的各种变化，如设置Textview,加载对话框，更新进度条等。
-
Model层定义Modle.interface,这个是用来定义数据层发生变化时的通知接口，因为Model不能直接与View交互，所以它与Presenter交互，然后再通过Presenter间接达到与View的交互。
-
Presenter翻译的意思是主持人，也就是主持场合，控制节奏的意思。在这时Presenter就负责具体的业务逻辑，请求数据，把数据送到Model，或者监听Model的数据变化，接受View层的动作，负责通过通知View层的视图变化。
六、项目架构（这里用的是TMVP算是mvp的加强版版吧 添加了契约类/contract和更加方便）
ps：名字当然不是这样写的 这样写只是为了看起来容易理解
七、对mvp的理解
我以前在团队工作的时候，团队分工是每人负责相应的Activity,在这里Activity是最小的开发单元。再后来，某些Activity变得越来越重要，越来越复杂，代码也越来越多，这样会造成团队某个人的开发任务重，而其他的团队成员也帮不上忙。而MVP的出现可以将Activity再细分，划为View和Presenter两个部分，所以Activity不再是最小的开发单元，如果可以完全可以这样分配任务，一个开发人员负责View部分，另一个开发人员负责Presenter部分。
况且因为MVP的划分，所以各个部分其实相对独立，V的变动会对P的部分造成较少的影响，而M对V或者说V对M几乎是透明的。
因为Presenter的存在，View和Model就可以很轻松，顶多Presenter累一点。
还有一个特点是MVP模式很适合测试，单独测试VIEW成了一种可能。我们可以模拟View和Model的数据来测试Presenter的逻辑。
未完待续