Android应用开发的早些年间，一个APP的整体架构并没有得到很好的重视，毕竟当时懂Android开发的人并不多，自身的开发者更是少之又少。随着多年以来的发展和积累，Android 应用开发的UI架构模式经历了MVC,MVP到MVVM的演进，特别是近一两年，MVP模式更是受到热烈的追捧，虽然没能像Java Web开发领域的SSK那样形成统一的标准或者开发框架，但MVP的思想已经得到了普及，也涌现出了一些不错的开源框架实现。
UI架构模式是面向开发者的，它在一定程度会存在性能的损耗，但好处是代码具有更高的可阅读性，可测试性，可维护性以及复用性。
MVP的基本概念
传统的Android应用开发中，View层(Activity,Fragment或者自定义View)承载了太多的责任，它不仅要完成界面的更新，复杂动画的渲染等UI相关的操作，还要处理各种业务逻辑，例如从网络获取数据，将用户输入保存到本地数据库中，由于职责不单一，View层的代码往往显得很庞大，一个Activity或者Fragment的代码行数可能要好几千行，这种模式显然不是长久之计，随着一个类的代码量逐渐增加，维护和升级将变得越来越困难，牵一发而动全身，为了更好的组织并对代码进行分层设计，我们有必要引入MVP模式。
MVP的全称是Model,View,Presenter,顾名思义，它将整个应用分为三层：
View层：视图层，包含界面相关的功能，例如各种Activity，Fragment，View，Adapter等，该层专注于用户的交互，实现设计师给出的界面，动画等交互效果，View层一般会持有Presenter层的引用，或者也可以通过依赖注入（例如Dagger）的方式获得Presenter的实例，并将非UI的逻辑操作委托给Presenter。
Presenter层：逻辑控制层，充当中间人的角色，用来隔离View层和Model层，该层是通过从View层剥离控制逻辑部分而形成的，主要负责View层和Model层的控制和交互，例如接受View层的网络数据加载请求，并分发给对应的Model处理，同时监听Model层的处理结果，最终将其反馈给View层，从而实现界面的刷新。
Model层：封装各种数据来源，例如远程网络数据，本地数据库数据等，对Presenter层提供简单易用的接口。
MVP与MVC的区别
MVP是经典的MVC的延伸和改进，MVC和MVP的相比，可以看出最大的不同在于：
1 MVP中View层和Model层并没有直接通信，而是通过中间人Presenter来简介通信；Presenter和View以及Model的交互都是通过接口进行的，通常View的Presenter是一对一的，当然，复杂的View可能需要多个Presenter来共同处理，这些需要根据具体的业务需求而定
2 MVC中Model层和View层是直接通信的，而且Controller是基于行为的，可以被多个View共享
MVP的开源实现
Android-Architecture
Google官方出品的Android UI架构的一系列例子，几乎都是MVP架构的实现，开发者可以根据自己的业务需求进行选择和参考
TODO-MVP
MVP架构的基本实现，没有使用任何其他的架构框架，通过纯手工的依赖注入实现从本地数据源和远程数据源获取数据的Repository，使用回调方法实现异步任务
TODO-MVP-Loaders
在TODO-MVP的基础上，通过Loaders机制从Repository中获取数据，使用Loaders机制的好处如下：
1 提供异步加载数据的能力，因此Repository不需要提供回调方法
2 监听Repository的数据变化，并在数据变化时发送新的结果
3 在配置变化导致界面重建时，Loaders机制会重新与最后的Loader建立连接
TODO-MVP-Clean
在TODO-mvp的基础上，参考Clean架构的思想，在表现层和Repository之间增加了一个Domain层，在整体上将app分为了三个层次
1 MVP层：也成为表现层，包含View和Presenter
2 Domain层：业务逻辑层，提供名为use cases或者interactors的类来表示所有可能从Presenter发起的动作
3 Repository层：数据存储层
TODO-Databinding
在TODO-MVP的基础上，结合Data Binding函数库实现视图和数据的绑定，它并没有严格遵循MVP或者MVVM模式，因此它结合使用了ViewModels和Presenters。
Data Binding函数库的引入，减少了很多样板代码的使用，使用UI元素的数据的绑定
1 使用布局文件实现数据和UI元素的绑定
2 事件也会和一个动作处理器绑定在一起
3 监听数据并在需要时自动更新
MVP的好处
使用MVP组织代码架构，并对代码实施分层管理，有以下好处
1 如果界面发生变化，甚至全新改版，只需修改对应的View即可，Presenter和Model层无需改动
2 如果业务逻辑或者数据获取方式发生变化，只需修改对应的Model
3 如果控制逻辑发生变化，只需修改对应的Presenter
4 Presenter层和View层以及Mdel层的交互都是基于接口实现的，这有助于对Presenter进行单元测试，同时由于是面向接口编程，只需实现定义好接口，每一层的实现可以交由不同的开发人员并行实现，最终在一起联调，能够明显加速某一功能的开发进度
5 团队的新成员拿到项目的代码，能够很容易的读懂现有的逻辑，快速上手
6 如果你正在开发一个对外的SDK，根据市场需求，需要提供带UI版本和不带UI的纯接口版本，那么使用MVP模式，将UI部分代码放在View层，将接口部分代码放在Model层，打包的时候可以轻松实现是否将View层打包进去，从而避免纯接口版本混入UI相关的代码
MVP存在的问题
1 增加代码类的数量
2 由于进行了三层划分，函数的调用栈变深了，如果开发人员没能非常清楚的了解哪一层具体该负责哪些功能，那么可能存在因为层次职责辨认不清等原因导致不同层之间的代码乱入，从而没能达到MVP充分解耦各层的目的
网友评论