mvp学习使用

为什么需要mvp

MVP 模式介绍
Android项目中ui占据大部分工作,早期开发,一般ui业务逻辑都写在Activity或者Fragment里面,直接后果,项目大了之后,ui界面代码会越来越臃肿,维护非常不方便.当项目越来越庞大、复杂，参与的研发人员越来越多的时候，MVP 模式 的优势就充分显示出来了.核心功能和业务逻辑分离,Activity 和 Fragment属于 View 层,用于展示 UI 界面，以及接收用户的输入，此外还要承担一些生命周期的工作。Presenter负责业务逻辑处理,分层更清楚,而且Presenter的一些业务逻辑也可以更好复用了.

MVP流程

说明：
步骤1：UI实现View方法，引用Presenter
步骤2：Presenter调用Model，走Model具体逻辑
步骤3：Model逻辑实现，回调Presenter方法
步骤4：Presenter回调View，即回到UI，回调View方法

模块

View Layer: 只负责 UI 的绘制呈现，包含 Fragment 和一些自定义的 UI 组件，View 层需要实现 ViewInterface 接口。Activity 在项目中不再负责 View 的职责，仅仅是一个全局的控制者，负责创建 View 和 Presenter 的实例；

Model Layer: 负责检索、存储、操作数据，包括来自网络、数据库、磁盘文件和 SharedPreferences 的数据；

Presenter Layer: 作为 View Layer 和 Module Layer 的之间的纽带，它从 Model 层中获取数据，然后调用 View 的接口去控制 View；

Contract: Google 的 Demo 加入契约类 Contract 来统一管理 View 和 Presenter 的接口，使得某一功能模块的接口能更加直观的呈现出来，这样做是有利于后期维护的。

MVP 优势

分离了视图逻辑和业务逻辑，降低了耦合
Activity 只处理生命周期的任务，代码变得更加简洁
视图逻辑和业务逻辑分别抽象到了 View 和 Presenter 的接口中去，提高代码的可阅读性
Presenter 被抽象成接口，可以有多种具体的实现，所以方便进行单元测试
把业务逻辑抽到 Presenter 中去，避免后台线程引用着 Activity 导致 Activity 的资源无法被系统回收从而引起内存泄露和 OOM