前言
写Android：你是如何把Activity写的如此“万能”的这篇文章到现在已经好久了，但是由于最近事情较多，写重构篇的计划就一直被无情的耽搁下来了，借这几天还算有点空余时间，把自己这桩心事了解下。
其实大家也知道Android：你是如何把Activity写的如此“万能”的这篇文章只是个引子，其实我真正想引出的是mvp设计模式，因为最近自己最近在用mvp做项目，自己对mvp有一些感悟，因此我将用mvp进行“万能”activity的重构。
同时也有一些朋友与我交流mvp，他们会被mvp中的m,v,p都应该放什么逻辑而困惑？会被mvp中的m应该怎么写而困惑？会被一个界面，怎么按照mvp来进行重构感到困惑？会被listview的adapter应该放在m层还是p层困惑？
我希望通过本文的讲解能帮助大家对mvp有一个更深的了解，现在进入主题内容。
正文内容
本文内容分为2部分：
- 带你了解mvp
- 使用mvp对“万能”Activity进行重构
第一部分会深入了解mvp到底是什么，它的好处等知识。第二部分会讲解如何利用mvp来重构“万能”Activity。
带你了解mvp
任何软件都是以数据为中心，为了能与用户进行交互，就需要提供界面支持用户对数据进行增删改查操作。
不管是mvc，mvp还是mvvm始终都在做一件事情：怎么样能更好的解决数据与界面之间的关系，以达到数据与界面之间的耦合更低，代码的复用性更高，代码的可测性更好。
本文的重点是讲解mvp，因此让我们开始了解下mvp是怎么组织数据与界面之间的关系的。我们先从mvp的结构图说起。
mvp的面容
网上有些关于mvp的结构图基本是以下样子
我觉得这张图是有问题的，问题在于presenter把请求转交给model，model应该把处理结果返回给presenter，这张图是没有反映这个过程的。
正确的mvp的结构图是这样子的
我们先看下能从这张图中得到哪些信息？
- mvp的分层结构特别类似于网络的七层协议，每层只知道自己依赖层的细节。
- 这种分层的好处是：层与层之间的耦合性低，模块的复用性高，可维护性更好，每层可以单独存在，这样可测性更好。
- 数据流的走向可以是：view–>presenter–>model–>presenter–>view,这种数据流一般出现的场景是用户在界面触发了一个事件的情形下
- 数据流的走向也可以是：model–>presenter–>view，这种数据流一般出现于比如通过长链接接收消息的场景。
- 不管数据流是怎样的一个流动走向，始终有一个原则是：数据流不能跨层流动，即层与层不能跨层通信。
看了mvp的整体结构图，我们以从底层到上层的顺序依次来介绍model，presenter，view。
model
先说下一些关于model的错误理解：
- model是实体类的集合
- 比如从json中解析数据的代码应该放在presenter中
- model与mvc中的model是一样的
关于model的正确理解我们会在文中看到。
数据加工处理厂
通过应用mvp后的感受，我个人的感觉model是最难写的一层，并且也是最难懂的，因为model是整个应用或界面的数据加工处理厂，所谓数据加工厂就是对数据的获取，数据的解析，数据的存储，数据的分发，数据的增删改查等操作。意思就是凡是涉及到数据操作都是在model进行的，所以model不仅仅只是实体类的集合，同时还包含关于数据的各种处理操作。
三种数据源
数据的数据源有三种：内存，磁盘（文件或数据库等），网络。为了提升app的性能，有必要把经常访问的数据临时存入内存中；同时也为了提升app性能和为用户省流量省电，有必要把数据存入磁盘中；还有的数据是有必要从网络读取的。三个数据源不一定同时存在，比如不与网络交互的app，不存在网络数据源。所以凡是涉及到关于数据发生于三个数据源加工处理的操作的代码都要放在model中。
model为上层提供的服务
model从黑盒的角度来看为上层（指依赖于model的层比如present）提供的服务无非就2种：model为上层提供数据，model处理上层传递的数据
model为上层提供数据
上层会从model中去数据，那model会从三数据源中取数据，取的顺序是
- 先内存，内存取到数据返回
- 其次磁盘，磁盘取到数据，如有必要把数据存储在内存中，则需要进行
存储，返回数据 - 最后网络，网络取到数据，如有必要在磁盘或内存中存储，则进行存储，返回数据
上面的取数据过程是最简单的情况，复杂些还会涉及到从内存或磁盘中取到的数据是否过期，过期的话就应该从网络获取。从网络取得数据后需要把内存或磁盘的数据更新。
model处理上层传递的数据
model接收到上层传递的数据后，model会依次把数据扔给三个数据源去处理，有可能三个数据源都会处理数据，有可能只是其中一个处理，model会把处理的结果返回。
所以model会把解析好的数据提供给上层，上层对于数据的来源完全是透明的，上层完全不需要关心数据到底是来自内存，还是磁盘甚至是网络。同理上层只需要的把数据扔给model，上层唯一做的事情就是愉快的等待处理结果。
tip
mvc中的model是要和view进行交互的，而mvp中的model不会知道任何view的细节。
model中的所有操作都发生于普通线程。
关于model的介绍先到此，我们在来看下presenter。
presenter
presenter翻译成汉语的意思是主持人，提出者。从它的意思可以看出它有控制全场的作用。首先presenter是处于mvp的中间层，在view和model中起一个承上启下的作用。presenter会把view交给自己的命令进行一定的校验等操作交给model处理，会把model处理的结果交给view。
presenter封装业务
presenter不仅起一个桥梁的作用，它还会把业务逻辑代码给包揽下来。这样就可以减轻Activity的负担了，让Activity全心全意做它的view工作。那估计就有朋友犯迷糊了，哪些代码属于业务逻辑呢？比如一些校验代码。或者可以这样想只要是不属于view和model的代码基本都可以放在presenter中。
presenter负责刷新view
mvc或以前的关于view的写法一般都是这样，view在接收到数据后，自己来进行view的刷新或其他操作。但是mvp中presenter负责对view进行刷新，比如从model获取的数据，presenter会根据获取的数据成功与否来通知view应该是显示成功界面还是失败界面。这样就让Activity变的更轻了，变成了听别人指挥的傻白甜了。这时候的presenter就有点主持人，掌控者的味道了。
presenter持有的线程
Android中view的操作需要在ui线程里执行，其他耗时操作需要在普通线程执行。presenter会持有这2种线程:ui线程,普通线程。刷新view时，它切换为ui线程进行刷新，从model取数据切换为普通线程。假如使用rxjava的话，就特别简单了关于线程切换的事情。
tip
presenter从model中获取的数据就是解析好的数据，不需要出现解析数据的代码。
接着我们来看下view。
view
view层就很好理解了，就是用户直接看到的界面，mvp中的view是很省心的，比如更新view，接收数据。这些操作它都不需要操心，也不需要知道数据到底来自哪里，给我啥我显示啥就可以了。
一个view可以同时拥有多个presenter，也可以只有一个presenter。
Android中的Activity，Fragment在mvp中是作为view来使用的，这些Activity，Fragment的责任就小了，只关心界面相关的事情足矣。
各种Adapter是放在view层的。
总结
我们初步认识了mvp，mvp中的model，present，view到底是什么，他们之间的关系是什么样的，这只是初步认识mvp，关于mvp中还有很多细节需要介绍，比如android clean architecture 中model和presenter之间多了一层interactor,多的这层interactor是用来做什么的，model层是怎么架构的。google mvpmodel层要比android clean architecture 简单等，希望能在我后面的章节看到相关关于每层的详细介绍。我们开始进入我们的重构”万能”Activity的部分。
使用mvp设计模式对”万能”Activity进行重构
回忆下“万能”Activity的样子
我在上篇文章的“万能”的LoginActivity基础上增加了登录对话框的功能，“万能”LoginActivity的代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
public LoginActivity extends Activity{ private EditText mUserNameView, mPasswordView; private Button mLoginView; public void initViews(){ ....... 各种findViewById.....代码 //给登陆按钮加监听器 mLoginView.OnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { String userName = mUserNameView.getText(); String password = mPasswordView.getText(); //验证用户输入的密码是否合法 if(!validate(userName) || !validate(password)){ 告诉用户输入的用户名或密码不合法 } else{ //开始登陆 login(userName,password); } } }); } //登陆方法,用伪代码来写下网络请求 private void login(String userName,String password){ //增加登录进度对话框给用户友好用户体验 显示登录进度对话框... HttpClient.getInstance().login(userName,password, new ResponseListener(){ public void failed(Failed failed){ 把登录进度对话框消失... 做失败相关的处理工作，比如给用户提示 把密码输入框清空，还比如登陆次数限制等 } public void success(Response response){ 把登录进度对话框消失... 做成功相关的处理工作 //暂且把用户信息的类叫做UserInfo,从json中解析数据，假设response.getContent()存在 String jsonContent = response.getContent(); JsonObject jsonObject = new JsonObject(jsonContent); UserInfo userInfo = new UserInfo(); userInfo.name = jsonObject.optString("name"); userInfo.userId = jsonObject.optString("userId"); 其他字段的解析...... //保存userInfo信息到数据表中,假设userDatabase已经存在 userDatabase.save(userInfo); 跳到app的主页 } }); } //验证给定的字符串是否合法，true 合法，false 不合法 private boolean validate(String str){ } } |
我们回忆了“万能”LoginActivity的代码后，开始重构。
开始重构
model
在使用mvp时，我一般有个习惯就是首先从model->presenter->view的顺序写代码，所以重构“万能”LoginActivity也先从model开始。前半部分关于model介绍过，model从黑盒的角度来说只有2个功能：一个是输出数据，一个是输入数据。因此登录中presenter只需要把账号，密码交给model，presenter唯一做的事情就是监听登录状态即可。model会把presenter传递的账号，密码交给服务器，model在把服务器返回的数据进行解析，存储在磁盘或内存中，把解析好的数据传递给presenter。那我们看下伪代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
//管理登录的类,它是单例的，这就不写单例方法了 public class LoginManager{ //登录的监听器 public static interface LoginListener{ //登录成功 void onSuccessLogin(UserEntity user); //登录失败 void onFailedLogin(Failed failed); } //登录方法 public void login(String name,String password,final LoginListener loginListener){ //假设HttpClient是一个请求网络服务的类 HttpClient.getInstance().login(userName,password, new ResponseListener(){ public void failed(Failed failed){ loginListener.onFailedLogin(failed); } public void success(Response response){ //假设UserParse类已经存在，主要用来从response中解析UserEntity UserEntity userEntity = UserParse(response.getContent()); //假设userDatabase是数据库存储类 userDatabase.store(userEntity); //还可以把userEntity存入内存中，这得根据业务需求进行处理 loginListener.onSuccessLogin(userEntity); } }); } } |
登录的model层我们没有做的那么复杂，比如把服务器返回的用户信息存储在内存中，把服务器返回的token存储在磁盘中，实现自动登录功能等，本例子只是一个特别简单的登录功能，实际应用中登录需要考虑很多的东西，登录的modle层到此重构完毕。
presenter
上文中提到过presenter，presenter起连接view与model的作用，presenter封装业务作用，presenter有负责刷新view的作用。
我们梳理下presenter都应该包含哪些功能：
- 验证账号，密码的合法性.
- 把验证成功的账号，密码交给model层
- 把登录的状态传递给view层，并根据不同的登录状态通知view显示不同的界面
那让我们开始写代码，presenter层的类组织结构我是参照google mvp的presenter类组织结构来进行的，因为我认为google mvp presenter类结构更清晰，看下伪代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
//登录的条约接口，分别定义了登录view的一些方法，和登录presenter的一些方法 public interface LoginContract{ //需要view层来实现的登录view接口，IView是所有view的基类 interface ILoginView extends IView{ |
