MVP 在 Android 上的使用其实已经流行了有挺长的一段时间,包括我们公司,经过我们Android端小伙伴们的思考与才华 我们的产品也是采取的MVP模式。
今天主要是想分享一下,本人对MVP的浅见,以及如何使用MVP模式搭建一个项目框架。
说明:由于本人能力和时间有限,所以本文只是抛砖引玉,疏漏之处敬请谅解。
老规矩,先上图:
MVP概述
MVP定义
MVP,全称 Model-View-Presenter,是一种架构模式;
从MVC这位老前辈 演变而来;
至于MVC,MVP,MVVM的区别请查看:MVC,MVP 和 MVVM 的图示。
简单知识:
大体分为 Model、View、Presenter三层,下面介绍一下这几层的作用:
- View :负责绘制UI元素、与用户进行交互(在Android中体现为Activity);
- View interface :需要View实现的接口,View通过View interface与Presenter进行交互,降低耦合,方便进行单元测试;
- Model :负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合);
- Presenter :作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。
MVP考量:
MVP的优点:
- 分离了视图逻辑和业务逻辑,降低了耦合;
- Activity只处理生命周期的任务,代码变得更加简洁;
- 我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁;
- 视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去,提高代码的可阅读性;
- Presenter被抽象成接口,可以有多种具体的实现,所以方便进行单元测试;
- 把业务逻辑抽到Presenter中去,避免后台线程引用着Activity导致Activity的资源无法被系统回收从而引起内存泄露和OOM
不足:
- Presenter中除了应用逻辑以外,还有大量的View->Model,Model->View的手动同步逻辑,造成Presenter比较重,维护起来会比较困难。
- 额外的代码复杂度及学习成本。
MVP实践
背景—>大体思路
背景:
- 有三大主打产品;
- 产品需要不断迭代;
- 功能模块多;
- 以团队为单位进行开发;
大体思路:
根据以上背景前提下,我们的项目拆分成两个包:commonlibrary
与 app(Presentation)
commonlibrary
:负责提供各种工具和管理第三方库,与业务逻辑完全无关,可跨项目使用;Presentation
:负责展示图形界面,并填充数据,处理业务逻辑;
Presentation 内要按功能划分模块:
包结构划分
一个项目是否好扩展,灵活性是否够高,包结构的划分方式占了很大比重。很多项目里面喜欢采用按照特性分包(就是Activity、Service等都分别放到一个包下),在模块较少、页面不多的时候这没有任何问题;但是对于模块较多,团队合作开发的项目中,这样做会很不方便。所以,我的建议是按照模块划分包结构。
res划分
layout
布局文件按 模块划分- 其它资源文件照旧
注意:需要修改 module下的 build.gradle
文件
MVP 分层说明
这层不准备细分,如果细分的话可以参考这篇文章-“领域驱动设计系列文章——浅析VO、DTO、DO、PO的概念、区别和用处”
View 层
- 简单的页面中直接使用 Activity/Fragment 作为 View 的实现类,然后抽取相应的接口;
- 在一些有 Tab 的页面中,可以使用 Activity + Fragment ( + ViewPager) 的方式来实现,至于 ViewPager,视具体情况而定,当然也可以直接 Activity + ViewPager 或者其他的组合方式
- 在一些包含很多控件的复杂页面中,那么建议将界面拆分,抽取自定义 View,也就是一个 Activity/Fragment 包含多个 View(实现多个 View 接口)
Presentation
用于程序逻辑处理, 通过接口与View交互, 解耦业务和界面
这边会大量的View->Model,Model->View的手动同步逻辑,造成Presenter比较重,维护起来会比较困难,所以这边我们采用的是EventBus来进行解耦
关于第三方库的选取
请参考: 如何评估开源库是否值得引入!!!
MVP 模式的的开源库:
参考: