MVP入门

Android MVP 模式 也不是什么新鲜的东西了，我在自己的项目里也普遍地使用了这个设计模式。当项目越来越庞大、复杂，参与的研发人员越来越多的时候，MVP 模式 的优势就充分显示出来了。

MVP 模式是 MVC 模式在 Android 上的一种变体，要介绍 MVP 就得先介绍 MVC。在 MVC 模式中，Activity 应该是属于 View 这一层。而实质上，它既承担了 View，同时也包含一些 Controller 的东西在里面。这对于开发与维护来说不太友好，耦合度大高了。把 Activity 的 View 和 Controller 抽离出来就变成了 View 和 Presenter，这就是 MVP 模式.。

MVP 模式（Model-View-Presenter）可以说是 MVC 模式（Model-View-Controller）在 Android 开发上的一种变种、进化模式。后者大家可能比较熟悉，就算不熟悉也可能或多或少地在自己的项目中用到过。要介绍 MVP 模式，就不得不先说说 MVC 模式。

MVC 模式

MVC 模式的结构分为三部分，实体层的 Model，视图层的 View，以及控制层的 Controller。

• 其中 View 层其实就是程序的 UI 界面，用于向用户展示数据以及接收用户的输入
• 而 Model 层就是 JavaBean 实体类，用于保存实例数据
• Controller 控制器用于更新 UI 界面和数据实例

例如，View 层接受用户的输入，然后通过 Controller 修改对应的 Model 实例；同时，当 Model 实例的数据发生变化的时候，需要修改 UI 界面，可以通过 Controller 更新界面。（View 层也可以直接更新 Model 实例的数据，而不用每次都通过 Controller，这样对于一些简单的数据更新工作会变得方便许多。）

举个简单的例子，现在要实现一个飘雪的动态壁纸，可以给雪花定义一个实体类 Snow，里面存放 XY 轴坐标数据，View 层当然就是 SurfaceView（或者其他视图），为了实现雪花飘的效果，可以启动一个后台线程，在线程里不断更新 Snow 实例里的坐标值，这部分就是 Controller 的工作了，Controller 里还要定时更新 SurfaceView 上面的雪花。进一步的话，可以在 SurfaceView 上监听用户的点击，如果用户点击，只通过 Controller 对触摸点周围的 Snow 的坐标值进行调整，从而实现雪花在用户点击后出现弹开等效果。具体的 MVC 模式请自行 Google。

MVP 模式

在 Android 项目中，Activity 和 Fragment 占据了大部分的开发工作。如果有一种设计模式（或者说代码结构）专门是为优化 Activity 和 Fragment 的代码而产生的，你说这种模式重要不？这就是 MVP 设计模式。

按照 MVC 的分层，Activity 和 Fragment（后面只说 Activity）应该属于 View 层，用于展示 UI 界面，以及接收用户的输入，此外还要承担一些生命周期的工作。Activity 是在 Android 开发中充当非常重要的角色，特别是 TA 的生命周期的功能，所以开发的时候我们经常把一些业务逻辑直接写在 Activity 里面，这非常直观方便，代价就是 Activity 会越来越臃肿，超过 1000 行代码是常有的事，而且如果是一些可以通用的业务逻辑（比如用户登录），写在具体的 Activity 里就意味着这个逻辑不能复用了。如果有进行代码重构经验的人，看到 1000 + 行的类肯定会有所顾虑。因此，Activity 不仅承担了 View 的角色，还承担了一部分的 Controller 角色，这样一来 V 和 C 就耦合在一起了，虽然这样写方便，但是如果业务调整的话，要维护起来就难了，而且在一个臃肿的 Activity 类查找业务逻辑的代码也会非常蛋疼，所以看起来有必要在 Activity 中，把 View 和 Controller 抽离开来，而这就是 MVP 模式的工作了。

MVP 模式的核心思想

MVP 把 Activity 中的 UI 逻辑抽象成 View 接口，把业务逻辑抽象成 Presenter 接口，Model 类还是原来的 Model。

这就是 MVP 模式，现在这样的话，Activity 的工作的简单了，只用来响应生命周期，其他工作都丢到 Presenter 中去完成。从上图可以看出，Presenter 是 Model 和 View 之间的桥梁，为了让结构变得更加简单，View 并不能直接对 Model 进行操作，这也是 MVP 与 MVC 最大的不同之处。