一、概述
每一个 app 的运营都需要经过不断的迭代与更新!在产品不断的升级过程中，项目的代码量会变得越来越大。当采用 Android 原生的架构（ Android 项目的架构：当建立起一个新项目时，默认的就像是个 MVC 的架构）去不断完善、升级项目时。到最后项目就变得越来越臃肿，这时，随着项目的越来越大，也许不得已需要进行项目的重构，然而这是个工作量很大的任务。所以，做好项目的架构，写好模型往往是很重要的。
google 官方在 GitHub 上也有着对应的官方规范已完善的开源项目架构（可以直接到这里下载 demo 学习）：
- todo-mvp/- Basic Model-View-Presenter architecture(基本的 mvp 架构)
- todo-mvp-loaders/- Based on todo-mvp, fetches data using Loaders.（基于 todo-mvp ，数据获取采用 Loaders）
- todo-databinding/- Based on todo-mvp, uses the Data Binding Library.（基于 todo-mvp ，使用 databinding 开源库）
- todo-mvp-clean/- Based on todo-mvp, uses concepts from Clean Architecture.（基于 todo-mvp，使用 Clean 架构）
- todo-mvp-dagger/- Based on todo-mvp, uses Dagger2 for Dependency Injection（基于 todo-mvp，使用 dagger2 进行依赖注入）
- todo-mvp-contentproviders/- Based on todo-mvp-loaders, fetches data using Loaders and uses Content Providers（基于 todo-mvp-loaders ，数据获取采用 Loaders 和 ContentProviders）
- todo-mvp-rxjava/- Based on todo-mvp, uses RxJava for concurrency and data layer abstraction.（基于 todo-mvp ，使用了 Rxjava ）
二、Android Architecture Blueprints：todo-mvp 学习
（1）首先，我们来看一下 todo-mvp 的包结构:
我们可以看到，在 todo-mvp demo 中，一个包就对应着一个功能模块。在 tasks 包中：
- TasksContract（定义 Presenter、View 的接口）
- TasksFragment（实现了 TasksContract.View 接口定义的功能）
- TasksPresenter（实现了 TasksContract.Presenter 接口定义的功能） 4. TasksActivity（TasksFragment 的载体）
在 data 包中，则是定义了对应的功能需要的数据实体、model 接口：
- 任务实体 Task
- model 接口 TasksDataSource
- 对应功能的 TasksDataSource实现类
（2）源码分析
- 首先，我们先看一下Presenter、View的两个基类
public interface BasePresenter { void start();}
start()方法在View界面开始显示的时候调用，一般是在Activity、Fragment的onStart()方法中
public interface BaseView<T> { void setPresenter(T presenter);}
setPresenter(T presenter)方法在Presenter实例化之后调用，一般是在Presenter构造方法最后调用，传入自己。
- 我们从 TasksActivity 入手，在 onCreate() 方法中，可以看到下面一段代码
@Override
protected void onCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState);
...略
//添加TasksFragment
TasksFragment tasksFragment = (TasksFragment)getSupportFragmentManager().findFragmentById(R.id.contentFrame);
if (tasksFragment == null) {
tasksFragment = TasksFragment.newInstance();
ActivityUtils.addFragmentToActivity( getSupportFragmentManager(), tasksFragment, R.id.contentFrame);
}
//新建TasksPresenter实例
mTasksPresenter = new TasksPresenter(Injection.provideTasksRepository(getApplicationContext()), tasksFragment);
}
TasksActivity 中，在添加 TasksFragment 后 new 了一个 TasksPresenter，接下来看TasksPresenter的构造方法。
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);
}
TasksPresenter的构造方法中，TasksPresenter获得了对mTasksView引用，并且还调用了mTasksView的setPresenter()方法。此时，TasksPresenter就传递到了TasksFragment 中，只要在TasksFragment 中对mPresenter 进行赋值，就完成了TasksFragment 与TasksPresenter实例引用的相互持有。
@Override public void setPresenter(@NonNull TasksContract.Presenter presenter) {
mPresenter = presenter;
}
到这里你也许会问，你只说了 V 与 P 的联系，那 M 去哪里了呢？嘿嘿，你在返回去看TasksPresenter的构造方法，这时你是否会发现这一句代码。
mTasksRepository = checkNotNull(tasksRepository, "tasksRepository cannot be null");
没错，就是在实例化TasksPresenter的同时，将数据处理model TasksRepository 赋予了TasksPresenter。至此，既然知道了各自的引用关系，那View、Presenter、Model的关系也就清楚了。
注意：Presenter的实例化在Activity中，但View对Presenter的引用却不一定在Activity中。因为View的实现类不一定是Activity，也可能是Fragment。至此，我们可以得出一个结论：Presenter的实例化在Activity中，View对Presenter的引用在View的实现类中。
3.既然清楚了View、Presenter、Model之间的关系，那么我们来看看它们之间到底是怎样协作的。由于代码比较多，我们就选择刷新数据功能来讲。
- View
@Nullable
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
...略
swipeRefreshLayout.setOnRefreshListener(new SwipeRefreshLayout.OnRefreshListener() {
@Override
public void onRefresh() {
mPresenter.loadTasks(false);
}
});
...略
return root;
}
在刷新时，调用了 mPresenter.loadTasks(false);可以看到，View将刷新功能交给了Presenter来做。再来看看mPresenter.loadTasks(false)方法 - Presenter
@Override
public void loadTasks(boolean forceUpdate) {
loadTasks(forceUpdate || mFirstLoad, true);
mFirstLoad = false;
}
//私有方法，操作数据
private void loadTasks(boolean forceUpdate, final boolean showLoadingUI) {
if (showLoadingUI) {
//对mTasksView的选中框进行显示
mTasksView.setLoadingIndicator(true);
}
if (forceUpdate) {
//mTasksRepository中的数据操作、刷新数据
mTasksRepository.refreshTasks();
}
EspressoIdlingResource.increment();
// App is busy until further notice
//mTasksRepository中的回调方法处理返回的数据
mTasksRepository.getTasks(new TasksDataSource.LoadTasksCallback() {
@Override
public void onTasksLoaded(List<Task> tasks) {
List<Task> tasksToShow = new ArrayList<Task>();
// This callback may be called twice, once for the cache and once for loading
// the data from the server API, so we check before decrementing, otherwise
// it throws "Counter has been corrupted!" exception.
if (!EspressoIdlingResource.getIdlingResource().isIdleNow()) {
EspressoIdlingResource.decrement();
// Set app as idle.
}
// We filter the tasks based on the requestType
for (Task task : tasks) {
switch (mCurrentFiltering) {
case ALL_TASKS:
tasksToShow.add(task);
break;
case ACTIVE_TASKS:
if (task.isActive()) {
tasksToShow.add(task);
}
break;
case COMPLETED_TASKS:
if (task.isCompleted()) {
tasksToShow.add(task);
}
break;
default:
tasksToShow.add(task);
break;
}
}
// The view may not be able to handle UI updates anymore
if (!mTasksView.isActive()) {
return;
}
if (showLoadingUI) {
mTasksView.setLoadingIndicator(false);
}
processTasks(tasksToShow);
}
@Override
public void onDataNotAvailable() {
// The view may not be able to handle UI updates anymore
if (!mTasksView.isActive()) {
return;
}
mTasksView.showLoadingTasksError();
}
});
}
mPresenter.loadTasks(）方法通过调用一个同名私有的重载的方法，调用 mTasksView.setLoadingIndicator(true)显示是选中框、 mTasksRepository.refreshTasks()刷新数据、 mTasksRepository.getTasks()的回调方法处理返回的数据。
总结：MVP在我看来就是一种“代理模式”。View、Model只需要做好自己的任务，然后，Model处理后的数据交于Presenter，Presenter通过View的引用将处理后的数据进行显示。最后，还有个契约类，也就是Contract，主要用于管理Presenter与View的接口，方便扩展。
