MVP是Google官方发布的Android开发相关的架构知识。本文要讲解的是一种最基本的MVP的实现方式，它使用手动的依赖注入来提供具有本地和远程数据源的存储库。异步任务处理回调。

基本的MVP示例项目地址：。

下图是基本的MVP的逻辑图：

注意：在MVP的模式中，View是被重新定义的。

• android.view.View类被指为Android View。
• 在MVP中，接受presenter命令的View将被简称为View。

MVP(Model-View-Presenter)模式，将APP的结构分为三层：View - Presenter - Model。

View

1. 提供UI交互

2. 在presenter的控制下修改UI。

3. 将业务事件交由presenter处理。

注意：View层不存储数据，不与Model层交互。

Presenter

1. 对UI的各种业务事件进行相应处理。也许是与Model层交互，也许自己进行一些计算，也许控制后台Task，Servic

2. 对各种订阅事件进行响应，修改UI。

3. 临时存储页面相关数据。

注意 : Presenter内不出现View引用。

Model

1. 从网络，数据库，文件，传感器，第三方等数据源读写数据。

2. 对外部的数据类型进行解析转换为APP内部数据交由上层处理。

3. 对数据的临时存储,管理，协调上层数据请求。

下图是MVP各层的结构示意图：

MVP架构能够将复杂的功能分割为各层内的小问题。各层内功能单一。这样易于功能修改拓展与Debug。解耦的设计，独立的模块，更有利于分工开发与测试。 

在示例Demo中，我们可以看到使用到了Fragments，这里使用Fragment有两个原因：

Fragment和 activity的分离符合实现MVP的思路。Activity是整体的控制器，能够创建和连接view和presenter。

平板形式的布局方式也能够很好的使用到Fragment。

关键概念

在这个sample app里面，有四个功能：

• Task
• TaskDetail
• AddEditTask
• Statistics 

每一个功能都有：

• 定义了View和Presenter的联系
• 一个Activity，负责创建Fragment和Presenter。
• 一个Fragment来实现View的接口
• 一个Presenter实现了Presenter的接口

一般来说，业务逻辑应该在Presenter里面存在，依赖View来完成Android的UI操作。而View不应该有任何的业务逻辑存在，它只负责将Presenter的命令转换成UI操作，并将用户的行为传递给Presenter。Contract是定义View和Presenter之间联系的一系列接口。

Dependencies（依赖）

• Common Android support libraries (com.android.support.*)
• Android Testing Support Library (Espresso, AndroidJUnitRunner…)
• Mockito
• Google Guava (非空检查库)

Features（特性）

MVP 复杂性的理解：

• 架构的框架/库/工具的使用复杂性：None — 不复杂
• 概念的复杂性：低，这个是一个Android纯MVP
• 可测试性： 单元测试 -- 高, Presenter 和 数据源都可以进行单元测试； UI测试 -- 高，允许使用假数据进行注入测试。
• 代码度量：相比较传统的项目，MVP架构会定义更多的类和接口。所以MVP的代码行数和类的数量都会比较高。
• 可维护性：高 -- 易于修改和添加一个功能
• 学习成本：低 -- 功能易于发现，责任明确。开发人员不需要熟悉任何依赖于项目外部的的project。