接到公司的需求，把之前那个实在维护不动的项目重构一下（之前项目是eclipse+没有架构写的，跟平铺差不多），临时组建了4个人的Android开发小组，确定架构的时候全票通过了MVP。 之前虽然用过MVP，可总意会不到MVP的精髓所在，反而经常被绕晕。也看了很多关于MVP的技术博客。怎么写的都有，很多分不清M层和P层的职责所在，为了发挥MVP的优势，特地找到了Google官方发布的MVP源码。总算发现了新大陆。（本文不会讲解官方的源码，只针对个人理解进行叙述，大神至此请无视）

Model View Presenter俗称MVP，该架构是从著名的MVC架构演变而来的。 Android应用开发类似MVC架构。开发中将XML文件视为MVC中的View角色，将Activity则视为MVC中的Controller角色。但是在实际应用开发中Activity大多充当Controller和View的合体。于是Activity既要负责视图的显示，又要负责对业务逻辑的处理。使得Activity过于臃肿。为了优化这一情况特地提出MVP架构模式，使得每层各尽其职，条理清晰。

【资料图】

用一张图来描述下他们之间的关系 M：逻辑层，数据逻辑，网络逻辑全写在这 P：调度层，M层和V层的交互需要P层调度 V：UI层，一般指Activity Fragement等等ui界面

在实际的使用使用中，我采用了Google官方的那种写法，除了MVP三层以外还增加了一个Contract契约类,将逻辑接口以及UI接口全部写在了Contract契约类中。然后Presenter和View分别实现Contract类中各自的接口。这么做的目的是方便管理，提高代码的可读性。打开Contract后一目了然，能非常清晰快速的了解到本模块的所有逻辑结构。

说了半天到底怎么个意思？

我们还是撸下代码吧，还是撸代码来的实在一点，首先我们看一张类结构图 BaseView和BasePresenter两个类，命名上就能看出这俩类是V层与P层的基类，主要实现所有View和Presenter都需要使用的接口。 MainContract：该类为契约类，集成了View层的ui更新接口以及Presenter层调用逻辑接口。

MainModel：该类为M层的逻辑处理类，所有的逻辑处理以及联网等均在此类中进行，最后通过P层调用从而实现逻辑驱动。

MainActivity：该类为V层的UI处理类，实现MainContract.View接口。主要负责Presenter，Model的初始化，以及UI的更新操作。

MainPresenter：该类为P层的调度处理类，主要负责调用View层以及Model层的方法或接口以实现调度的职责。该类构造函数中接收Activity初始化好的Model和View，并通过View设置Presenter使得每一个实现MainContract.View接口的View均可得到Presenter对象，以方便后续操作。

至此，完整的MVP架构已经叙述完毕了，通过以上的描述我们可以清楚的了解到MVP目前比较火的架构之一。他能最大程度的降低代码耦合程度以及维护成本，提高代码的维护性和可读性。从而达到以不变应万变的目的。

以上是本人对MVP的全部理解。如果疑问和建议欢迎留言指点。