关于MVP模式
MVP模式相信对于各位开发Android的同僚们都有概念了。
相比较于大家熟知的MVC模式，在Android的开发中，Activity应该属于view这一层，但是在实际开发中，Activity不仅承担了View，也承担了大部分的Controller的职责，这样的好处就是在这Activity小，功能少的情况下，代码易读好写。但多数情况会导致我们Activity十分臃肿，并且大部分功能不易于重用和修改，在单元测试上存在很大工作量。因此在Android常规的开发模式也被称为MV模式（Model-View）。
而MVP模式（Model-View-Presenter）则是把View分离成了View和Presenter。
在学习MVP模式之前，我们先来看MVC模式。
MVC模式
- View 层就是程序展示给用户的界面，用于展示程序和接收用户的反馈，比如输入，触摸
- Model 层就是 JavaBean 实体类，用于保存实例数据
- Control 控制器用于更新界面和数据实例
其中View的更新，一般来说通过Controller来通知更新，但有时候也可以通过Model直接更新View，比如一些简单的信息展示工作，这样会使开发方便很多。
MVP模式
在MVP模式中，Presenter取代了Controller。
结合Android的开发模式，MVP 把 Activity 中的 UI 逻辑抽象成 View 接口，把业务逻辑抽象成 Presenter 接口，Model 类还是原来的 Model。
这就是 MVP 模式，现在这样的话，Activity 的工作的简单了，只用来响应生命周期，其他工作都丢到 Presenter 中去完成。从上图可以看出，Presenter 是 Model 和 View 之间的桥梁，为了让结构变得更加简单，View 并不能直接对 Model 进行操作，这也是 MVP 与 MVC 最大的不同之处。
为什么要用MVP模式
- 分离视图和逻辑，降低耦合
- Activity只负责响应生命周期
- 视图逻辑和业务逻辑分别抽象到了 View 和 Presenter 的接口中去，提高代码的可阅读性
- Presenter 被抽象成接口，可以有多种具体的实现，所以方便进行单元测试
- 把业务逻辑抽到 Presenter 中去，避免后台线程引用着 Activity 导致 Activity 的资源无法被系统回收从而引起内存泄露和 OOM