Github标星5-8K今年最热门技术-Android-MVP-阿里大牛-倾情-详解（上）

前言

MVP 在 Android 上的使用其实已经有挺长一段时间了，长到似乎有点“过时”了（目前风头正劲的是MVVM），那为什么现在还要讲 MVP。今天我想要讨论它的主要原因有如下几点：

1. MVP 并未过时，值得我们研究

2. 目前关于 MVP 的资料都不算太详尽

3. 由于能力和时间有限，本人拖到最近才下定决心写

说明：本文只是抛砖引玉，疏漏之处敬请谅解。

###为了感谢大家这么久以来的支持，给大家准备了一份惊喜在文章结尾！感兴趣的朋友可以看看哦。

目录

前言

一、什么是MVP

二、MVX解析

三、MVX与三层架构

四、Android上MVP的几种实现

五、最佳实践

六、进阶与不足

前言

2014年年底偶然得知在Android开发中出现了MVP这种模式，当时觉得这东西挺好，正好赶上公司要做一个新的小项目，于是尝试了一下。仿照网上的Demo分出View、Model、Presenter层，抽取View接口，看起来像那么回事的用MVP完成了整个项目。因为项目简单，期间也没有遇到什么坑，但是总觉得还有那些地方不对。当时网上一些关于Android MVP的介绍都有点浅尝辄止，一个登录或者根据地区查询天气等的小Demo，没有实际在项目中应用的示例，所以在用MVP做完一个小项目之后还是不敢在主项目中轻易尝试。首先，主项目比较混乱，改动起来工作量很大，而工期经常较紧，时间不允许；其次，知道自身对MVP理解还不够，怕掉坑里去；最后，也是最重要的一点，当时的项目不是按功能模块划分的包结构，如果改为MVP那是真的就回不到过去了。好了，废话不多说，今天主要是想分享一下，本人对MVP的浅见，以及如何使用MVP模式搭建一个项目框架。纯属一家之言，不足之处，请见谅。

一、什么是 MVP

1.1. MVP 的定义

MVP，全称 Model-View-Presenter

要说MVP那就不得不说一说它的前辈——MVC。

MVC（Model-View-Controller，模型-视图-控制器）模式是80年代Smalltalk-80出现的一种软件设计模式，后来得到了广泛的应用，其主要目的在于促进应用中模型，视图，控制器间的关注的清晰分离。MVP（Model-View-Presenter，模型-视图-表示器）模式则是由IBM开发出来的一个针对C++和Java的编程模型，大概出现于2000年，是MVC模式的一个变种，主要用来隔离UI、UI逻辑和业务逻辑、数据。也就是说，MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

说明：按照View和Presenter之间的交互方式以及View本身的职责范围，Martin Folwer将MVP可分为PV（Passive View）和SoC（Supervising Controller）两种模式。

Passive View

顾名思义，PV（Passive View）是一个被动的View，针对包含其中的UI元素（比如控件）的操作不是由View自身来操作，而交给Presenter来操控。

Supervising Controller

在SoC（Supervising Controller）模式下，为了降低Presenter的复杂度，将诸如数据绑定和格式化这样简单的UI处理逻辑逻辑转移到View中，这些处理逻辑会体现在View实现的接口中。

1.2. 发展历程

任何一种思想的产生都有其特定的背景，在软件开发中也是如此。在软件复杂度增长，需求不断变更的客观条件下，为了更好的解决这些问题，出现了各种软件架构思想、编程思想以及设计模式。（因为人的能力并没有“跟上”机器，所以才会出现各种模式、方法、工具等等来补足人的不足，以最大地透支机器性能。–Indream Luo）

相信做过客户端（PC、Android、iOS等）或者前端开发的童鞋都听过MVC、MVP、MVVM这些名词（就算不了解也大致知道有这个东西吧），这些都是为了解决拥有图像界面的程序开发复杂性而产生的模式。这里说的是模式，当然有各种各样的框架方便开发者在项目中应用这种模式，这不是本文重点。

有前辈（Indream Luo）说过，架构是对客观不足的妥协，规范是对主观不足的妥协。对此我深表赞同，先不管这些，我们来看看GUI是怎么和MVX扯上关系的。

先搞清楚一个顺序，是GUI应用程序的出现导致了MVC的产生。GUI应用程序提供给用户可视化的操作界面，这个界面提供给用户数据和信息。在PC上用户与界面的交互主要依赖（键盘，鼠标等。这些操作会执行一些应用逻辑，应用逻辑（application logic）可能会触发一定的业务逻辑（business logic）使应用程序数据的发生变更，数据的变更自然需要用户界面的同步变更以提供最准确的信息。在开发这类应用程序时，为更好的管理应用程序的复杂性，基于职责分离（Speration of Duties）的思想都会对应用程序进行分层。在开发GUI应用程序的时候，会把管理用户界面的层次称为View，应用程序的数据为Model（注意这里的Model指的是Domain Model，这个应用程序对需要解决的问题的数据抽象，不包含应用的状态，可以简单理解为对象）。Model提供数据操作的接口，执行相应的业务逻辑。有了View和Model的分层，那么问题就来了：View如何同步Model的变更，View和Model之间如何粘合在一起。（所谓的MVX中的X都可以归纳为对这个问题不同的处理方式）（引自：戴嘉华）。

MVC 的产生

早在上个世纪70年代，美国的施乐公司（Xerox）的工程师研发了Smalltalk编程语言，并且开始用它编写图形界面的应用程序。而在Smalltalk-80这个版本的时候，一位叫Trygve Reenskaug的工程师设计了MVC图形应用程序的架构模式，极大地降低了图形应用程序的管理难度。而在四人帮（GoF）的设计模式当中并没有把MVC当做是设计模式，而仅仅是把它看成解决问题的一些类的集合。Smalltalk-80 MVC和GoF描述的MVC是最经典的MVC模式。

看到这服务端的童鞋有话要说：我们也用MVC，你看Structs、SpringMVC这些都是经典的MVC框架。那服务端的MVC和GUI开发中的MVC有何不同之处了，请看下面的分析。

MVC Model 2的出现

在Web服务端开发的时候也会接触到MVC模式，而这种MVC模式不能严格称为MVC模式。经典的MVC模式只是解决客