转载请注明出处：http://www.cnblogs.com/cnwutianhao/p/6700668.html
引言：在Google没有给出一套权威的架构实现之前，很多App项目在架构方面都有或多或少的问题。第一种常见问题是没有架构，需求中的一个页面对应项目中的一个activity或一个fragment，所有的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中。第二种常见的问题是架构实现的不断变化，不断在各种架构间摇摆，一直找不到一个适合自己的架构。
Google官方示例项目地址 https://github.com/googlesamples/android-architecture/tree/todo-mvp/
Google提供这个示例项目有两个目的：
- Provide a basic Model-View-Presenter (MVP) architecture without using any architectural frameworks.
- Act as a reference point for comparing and contrasting the other samples in this project.
中文解释：
- 提供了一个基础的MVP架构，而不是用其他的架构。
- 用这个项目和其他类似的做一个参考对比。
当然Google也明确表示了这些示例只是用来做参考，而并不是要为了当做标准
下面我们从源码的角度来分析todo-mvp（mvp基础架构示例）的实现。我们先从项目的整体组织方式开始，再看项目究竟使用了哪些组件，最后当然是最重要的具体mvp的实现方式。
先看一下项目代码组织方式：
项目含一个app src目录，4个测试目录，分别是androidTest（UI层测试）、androidTestMock（UI层测试mock数据支持）、test（业务层单元测试）、mock（业务层单元测试mock数据支持）。
src目录的代码组织方式完全是按照功能来组织的，功能内部分为xActivity、xContract、xFragment、xPresenter四个类文件(x代表业务名称)。
组件使用
由于项目是基于gradle进行编译的，所以我们可以从build.gradle文件看到项目依赖的全貌。
dependencies {
// App's dependencies, including test
compile "com.android.support:appcompat-v7:$rootProject.supportLibraryVersion"
compile "com.android.support:cardview-v7:$rootProject.supportLibraryVersion"
compile "com.android.support:design:$rootProject.supportLibraryVersion"
compile "com.android.support:recyclerview-v7:$rootProject.supportLibraryVersion"
compile "com.android.support:support-v4:$rootProject.supportLibraryVersion"
compile "com.android.support.test.espresso:espresso-idling-resource:$rootProject.espressoVersion"
compile "com.google.guava:guava:$rootProject.guavaVersion"
// Dependencies for local unit tests
testCompile "junit:junit:$rootProject.ext.junitVersion"
testCompile "org.mockito:mockito-all:$rootProject.ext.mockitoVersion"
testCompile "org.hamcrest:hamcrest-all:$rootProject.ext.hamcrestVersion"
// Android Testing Support Library's runner and rules
androidTestCompile "com.android.support.test:runner:$rootProject.ext.runnerVersion"
androidTestCompile "com.android.support.test:rules:$rootProject.ext.runnerVersion"
// Dependencies for Android unit tests
androidTestCompile "junit:junit:$rootProject.ext.junitVersion"
androidTestCompile "org.mockito:mockito-core:$rootProject.ext.mockitoVersion"
androidTestCompile 'com.google.dexmaker:dexmaker:1.2'
androidTestCompile 'com.google.dexmaker:dexmaker-mockito:1.2'
// Espresso UI Testing
androidTestCompile "com.android.support.test.espresso:espresso-core:$rootProject.espressoVersion"
androidTestCompile "com.android.support.test.espresso:espresso-contrib:$rootProject.espressoVersion"
androidTestCompile "com.android.support.test.espresso:espresso-intents:$rootProject.espressoVersion"
// Resolve conflicts between main and test APK:
androidTestCompile "com.android.support:support-annotations:$rootProject.supportLibraryVersion"
androidTestCompile "com.android.support:support-v4:$rootProject.supportLibraryVersion"
androidTestCompile "com.android.support:recyclerview-v7:$rootProject.supportLibraryVersion"
androidTestCompile "com.android.support:appcompat-v7:$rootProject.supportLibraryVersion"
androidTestCompile "com.android.support:design:$rootProject.supportLibraryVersion"
}
项目中使用到了Guava库，官网地址 https://github.com/google/guava
该库是Google在基于java的项目中都会引用到得一个库，库中包含大约14k的方法数，是个很大的库，其中包含了集合、缓存、并发、基本注解、字符串处理、io处理等等。项目中使用Guava库主要是处理null这种不安全的情况，因为一般我们在使用有可能为null的对象时，一般会增加一次判断。比如项目中的出现的：
public boolean isEmpty() {
return Strings.isNullOrEmpty(mTitle) &&
Strings.isNullOrEmpty(mDescription);
}
这样面对空的时候，就不用再多写很多代码了，确实是方便了很多。但是不建议为了null安全直接引入如此大的一个库，因为我们都知道android apk的65k方法数限制，如果要用的话可以把源码中涉及到得部分直接拿出来用。当然Guava中还有很多重要的功能，其他功能读者可以自行研究，关于Guava就先到这里了。
测试相关组件
示例项目在可测试方面做的非常好，由于对视图逻辑(view层)和业务逻辑(presenter层)进行了拆分，所以我们就可以对UI、业务代码分别进行测试。为了进行UI测试引入了Espresso，为了对业务层进行单元测试引入了junit，为了生成测试mock对象引入了mockito，为了支撑mockito又引入了dexmaker，hamcrest的引入使得测试代码的匹配更接近自然语言，可读性更高，更加灵活。
重头戏：项目MVP实现方式
1.基类
两个Base接口 BasePresenter 和 BaseView，这两个类分别是 presenter 和 view 的基类。
public interface BasePresenter {
void start();
}
BasePresenter 中含有方法 start()，该方法的作用是 presenter 开始获取数据并调用 view 中方法改变界面显示，其调用时机是在 Fragment 类的 onResume 方法中。
项目中调用 start() 的地方：
public interface BaseView<T> {
void setPresenter(T presenter);
}
BaseView 中含方法 setPresenter()，该方法作用是在将 presenter 实例传入 view 中，其调用时机是 presenter 实现类的构造函数中。
项目中调用 setPresenter() 的地方：
2.契约类
与之前见到的所有mvp实现都不同，Google官方的实现中加入了契约类来统一管理view与presenter的所有的接口，这种方式使得view与presenter中有哪些功能，一目了然，维护起来也方便，实例如下：
public interface TasksContract {
interface View extends BaseView<Presenter> {
void setLoadingIndicator(boolean active);
void showTasks(List<Task> tasks);
void showAddTask();
...
}
interface Presenter extends BasePresenter {
void result(int requestCode, int resultCode);
void loadTasks(boolean forceUpdate);
void addNewTask();
...
}
}
3.Activity在MVP中的作用
Activity 在项目中是一个全局的控制者，负责创建 view 以及 presenter 实例，并将二者联系起来，下面是 Activity 中创建 view 及 presenter 的代码:
TasksFragment tasksFragment =
(TasksFragment) getSupportFragmentManager().findFragmentById(R.id.contentFrame);
if (tasksFragment == null) {
// Create the fragment
tasksFragment = TasksFragment.newInstance();
ActivityUtils.addFragmentToActivity(
getSupportFragmentManager(), tasksFragment, R.id.contentFrame);
} // Create the presenter
mTasksPresenter = new TasksPresenter(
Injection.provideTasksRepository(getApplicationContext()), tasksFragment);
我们可以从上面看到整个创建过程，而且要注意的是创建后的 Fragment 实例作为 presenter 的构造函数参数被传入，这样就可以在 presenter 中调用 view 中的方法了。
4.MVP的实现与组织
实例中将 Fragment 作为 view 层的实现类，为什么是 Fragment 呢？
有两个原因:
- 我们把 Activity 作为一个全局控制类来创建对象，把 Fragment 作为 view，这样两者就能各司其职。
- 因为 Fragment 比较灵活，能够方便的处理界面适配的问题。
我们先看 view 的实现，我们只挑一部分重要的方法来看
public class TasksFragment extends Fragment implements TasksContract.View {
...
@Override
public void onResume() {
super.onResume();
mPresenter.start();
}
@Override
public void setPresenter(@NonNull TasksContract.Presenter presenter) {
mPresenter = checkNotNull(presenter);
}
...
}
上面可以看到 setPresenter() 方法，该方法继承于父类，通过该方法，view 获得了 presenter 得实例，从而可以调用 presenter 代码来处理业务逻辑。我们看到在 onResume 中还调用了 presenter 得 start() 方法。
下面我们再看presenter的实现
public class TasksPresenter implements TasksContract.Presenter {
...
public TasksPresenter(@NonNull TasksRepository tasksRepository, @NonNull TasksContract.View tasksView) {
mTasksRepository = checkNotNull(tasksRepository, "tasksRepository cannot be null");
mTasksView = checkNotNull(tasksView, "tasksView cannot be null!");
mTasksView.setPresenter(this);
}
@Override
public void start() {
loadTasks(false);
}
...
}
presenter 构造函数中调用了 view 的 setPresenter() 方法将自身实例传入，start() 方法中处理了数据加载与展示。如果需要界面做对应的变化，直接调用 view 层的方法即可，这样 view 层与 presenter 层就能够很好的被划分。
最后还剩下 model 层实现，项目中 model 层最大的特点是被赋予了数据获取的职责，与我们平常 model 层只定义实体对象截然不同，实例中，数据的获取、存储、数据状态变化都是 model 层的任务，presenter 会根据需要调用该层的数据处理逻辑并在需要时将回调传入。这样 model、presenter、view 都只处理各自的任务，此种实现确实是单一职责最好的诠释。
5.总结：
我们再来整体看下官方的实现方式有哪些特性。首先是复杂度，我们可以从上面的分析看出整体的复杂度还是较低的，易学的；然后是可测试性，由于将UI代码与业务代码进行了拆分，整体的可测试性非常的好，UI层和业务层可以分别进行单元测试；最后是可维护性和可扩展性，由于架构的引入，虽然代码量有了一定的上升，但是由于界限非常清晰，各个类职责都非常明确且单一，后期的扩展，维护都会更加容易。