为什么需要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