MVP也即Model-View-Presenter，是在MVC基础上优化衍生出来的一种软件架构模式，它将MVC中的Controller层进行了优化而生成了Presenter（可理解为主持者或表示者）。
这里Presenter层和MVC的Controller一样，负责核心逻辑，但不同的是，Presenter通过接口协议进行数据传递、功能调用，并阻断了View和Model的直接联系，从而使View和Model更加专注于自身业务逻辑，更好地实现了高内聚、低耦合，同时也方便单元测试。
用下图来说明二者之间的对比，可能更直观些。
在Android平台上，由于Activity/Fragment的生命周期比较复杂以及配置可能发生变化等因素，我们在具体实现时，可以采用多种不同的方案。
本文对Android平台上常见的MVP架构模式，从实现方案的角度尝试做些分析，也欢迎一起深入探讨。
1、Google官方实现
这里使用的例子为TODO-MVP，属于MVP架构的一个基础实现，主要功能是记录、查看待处理任务，管理待办事宜。
其项目工程结构和包，是按照功能来划分的，包括新建/编辑、任务统计、详情查看等模块，如图。
各个子模块的实现比较类似，以新建/编辑任务模块为例，其UML静态结构如下。
其中AddEditTaskActivity完成Presenter的实例化，并将实现了View接口的AddEditTaskFragment对象作为一个参数传递到构造函数中，再通过setPresenter调用，把AddEditTaskPresenter传递给AddEditTaskFragment，建立View和Presenter之间的双向关联。而TasksDataSource接口及TasksRepository类则对应Model，负责完成任务的获取、保存和刷新等处理。
这里获取任务数据的回调处理，是通过Presenter实现TasksDataSource.GetTaskCallback接口来完成的，在onTaskLoaded 和onDataNotAvailable回调中根据数据获取情况更新UI显示。
除了上面提到的基础调用逻辑之外，我们还需要关注该实现中，在Fragment不同的生命周期以及Activity配置发生变化时，对应Presenter的处理方式。
生命周期的处理，又分为两部分。一是在onActivityCreated完成“新建”按钮的属性和点击事件设置，二是在onResume中调用Presenter的start方法，以获取待编辑的任务数据。
配置变化的处理，则是通过AddEditTaskPresenter构造函数中的一个变量来实现的，该变量在任务数据获取完成之后加以复位。Activity中，对应的变量在配置变化时会被保存下来，当再次创建Activity时，该变量被传递给AddEditTaskPresenter，这样避免了由于配置变化带来的数据丢失。
实际上，针对配置变化的问题，Google官方的TODO-MVP-Loders实现给出了另外一种解决方案。该实现利用Loader机制来处理数据访问，对于任务数据的访问管理提供了更强大的功能，包括异步加载数据、监听数据变化以及自动重连等。
与之类似的官方实现还有TODO-MVP-Clean，该实现主要是增加了一个Domain层，可以理解为业务逻辑层，负责处理Presenter发起的业务逻辑相关的操作。个人认为这种实现是对MVP中的Model做了扩展，将业务逻辑与数据访问进一步解耦。
关于Google官方MVP架构实现，暂且分析到这里，欢迎继续关注。
