导读：在Android的开发过程中，Activity承担了大量地工作。如果对整个项目十分了解，并且在开发过程中有意识地抽离出了一些通用层的话，维护起来还稍微好一点，但实际上我们经常会遇到这样一些情况：维护并迭代已有地商业项目（可能前几期并不是由你开发）;UI变动极大（是不是经常Crtl+f到处查找？）...
如果按照MVC的项目结构来说，Activity应该是属于View这一层。而实质上，它既承担了View，更多地却包含一些Controller的东西在里面。这对于开发与维护来说极度不利，耦合度大高了
那么有没有什么解决方案呢？答案当然就是本文所讲述的——MVP了
虽然说MVP已经出来很有一阵了，网上关于讲解这方面的文章也不少，但实际上真动手写起来时，还是有一些不顺畅。这没有更好的办法，唯有多练，多练，多练（重要的事情说三遍）。
MVP是Model, View和Presenter的简称。是MVC模式的演化版。MVP模式把显示逻辑和从业务逻辑层中分离出来，理想状况下，视图层变更替换过程中，可以实现相完全相同的逻辑代码。
下面看一张图
从上图可以看出，Presenter层成了Model与View之间的桥梁，Model与View之间不再直接进行交互。而Presenter持有Model与View的引用，完成了对逻辑地处理。将这个模式代入到Android中，我们可以将他丰富成这样(如下图)
Presenter层。presenter英文意思是主持人，在MVP中它是负责逻辑处理并统筹View与Model的一个层。一般来说View与presenter都是一对一的情况，当然这只是一般情况，并不排除复杂界面中Presenter有多个的情景。上面说到Presenter持有View与Model的一个引用，准确地来说，它持有的是ViewInterface与ModelInterface的引用。
让我们先来回忆一下MVC的结构
M （Model） 实体层
V （View） 视图层
C （Controller）控制层
相信对MVC，大家都是非常熟悉了，不再多言，一图以蔽之
通过与MVP结构图对比着看可以发现：
在MVC结构中，Model是可以直接被View操作的。其实这就是MVP与MVC最大的一个区别。
或者可以这样问MVP有什么好处？为什么要使用MVP?
其实通过上面的几张图就不难看出
其实，说这么多，都是因为显示层与逻辑层分离带来地便利。
都说MVP抽离了层结构，降低了耦合度，那么它到离是如何抽离的？当然是通过接口了。
Presenter中通过对接口的操作，可以完全不关心View层与Model层的具体实现，只需要处理对应逻辑就可以了。而在View层中，即Android的Activity与Fragment中，只需要持有一个Presenter的对象，以完成界面交互。这样咱们的View层就变得非常地薄了。所以，总结了一下，使用MVP，可以从以下几个方向思考：
以上,MVP理论上来说可以实现在多人协作项目中，让写UI的人与写逻辑的人分工而行，也更方便于在开发过程中进行单元测试。鉴于文章长度问题，具体地实际应用我们放在下章再说，我们一起来一步步实现一个MVP模式的Android应用
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.