说到 MVP ，大家应该都不陌生了，由于其高度解耦等优点，越来越多的项目使用这个设计模式；然而，优点虽在，缺点也不少，其中一个就是类多了很多，而且 V 与 P 直接要项目通信，那么 P 就得持有 V 得实例，但如果 activity 挂掉了，如果没有对 V 进行释放，又有导致内存溢出得问题，而且，那么多的接口函数，看得人眼花缭乱，也使得很多人在使用这个模式的时候望而却步。
如果对 MVP 不了解，可以看我以前的这两篇文章：
MVP 设计模式理解，实战理解MVP
MVP+多线程+断电续传 实现app在线升级库 (手把手教你打造自己的lib)
回归原题，最近把一个项目改成 MVP 的模式，用以前的方式，写完之后，那么多接口类，除了很多重复了之外，和别人共同开发也是个问题；那么，封装一些 base 基类就显得尤为重要了。当然，一千个人中有一千个哈姆雷特，这里就提供一下我的思路，大家可以结合自己的理解参考一下。
项目类型： 类似一个 雷豹清理大师的清理工具，先上传个简单的 效果图吧，这样会比较好理解一下：
1、封装 BaseView
BaseView 的封装中，我们把每个子类都会用到的方法放在这里，由于是清理工具类的项目，那么就有一个扫描的过程，还有加载失败，所以，baseview 如下：
public interface BaseView { void fail(String errorMsg); // 扫描状态更新，根据需要更新
void scanStatusShow(int current,int maxsize,long size,String path);
}当然，这里的 baseview 只是我这个项目的，实际上，你还可以在上面添加 夜间模式切换，显示隐藏加载进度条等公有方法。
2、封装 BasePresenter
上面中，我们提到，presenter 是持有view 的实例的，假如activity崩溃，而persenter继续持有，那么势必会导致内存泄漏的问题的；所以，我们希望在activity崩溃时，也把 view 去掉；
那么，basepresenter 时用抽象类好？还是接口类呢？比如网上很多人这样写：
public abstract class BasePresent<T>{ public T view; public void attach(T view){ this.view = view;
} public void detach(){ this.view = null;
}
}这里用了一个抽象类来实现，但我们参考 google 的 mvp 源码时，它的 basepresenter 是一个接口，就一个 start() 方法，然后再用一个契约类来实现的，如下：
/**
* This specifies the contract between the view and the presenter.
*/public interface AddEditTaskContract { interface View extends BaseView<Presenter> { void showEmptyTaskError(); void showTasksList(); void setTitle(String title); void setDescription(String description); boolean isActive();
} interface Presenter extends BasePresenter { void saveTask(String title, String description); void populateTask(); boolean isDataMissing();
}
}可以看到，它把相关的 view 和persenter 都放在 contract 这个类中，这样做的好处在于，方便后期的维护，类的实现方法和接口都在这，方便查找与调试，所以，我们封装的时候，也参考这种模式。但思考一个问题，我们的 basepresenter 是用抽象类好呢？好像接口呢？
答案是抽象，为什么？
我们知道，接口是一个特殊的抽象类，接口里面的方法都是抽象方法，如果定义成接口函数，则里面的方法必须实现，则在 baseactivity 或者 basefragment 继承时重写了方法，而在 具体子类的 presenter 的时候也重写了方法，这样就多余了，所以，书上看到这接口和抽象类的总结，觉得还不错，如下：
优先使用接口
在既要定义子类的行为，又要为子类提供公共的功能时应选择抽象类
所以，这里的 basepresenter 就用 抽象类会好一点。
/**
* T 泛型，指的是baseview，当然也可以是其他的view 类型
* Created by zhengshaorui on 2017/6/22.
*/public abstract class BasePresenter<T> { // 获取 view 的view 实例
T view; void onAttach(T view){ this.view = view;
}; // 解绑 view 层
void onDetch(){ this.view = null;
}; // view 数据的开始，一般再 oncreate 或者 onresume 中
// void start();}可能你会疑问，这样的话，我们的契约类怎么写？别急，往下看。
3、契约类 contract
回顾一下自己以前写的 mvp 小demo，我们是不是 v 一个接口，p一个接口，除了结构上给人类很多之外，而且还大部分是重复的，涉及到 v 层数据的更新，p在获取了v的实例之后，通过观察者模式，获取model的数据更新到v，那么这里接口就存在重复的，我们可以用基类继续封装；
而且mvp中的p，我们说过，它就是个纽带，那么就不要添加什么逻辑性的东西在这里，保证 p 的轻薄，v 就是更新 UI 的。
ok，首先，先看一下我的 contract 类的封装：
public interface ContractUtils { /*=============一键减速契约类===============*/
// 一键加速contract
interface ISpeedUpView extends SpeedUpBaseInterface { void getMemory(long availsize,String total);
} //presenter 的接口类
interface ISpeedUpPresenter extends SpeedUpBaseInterface{ void startSpeedup();
} /* ==============轻度清理契约类==================*/
interface IClearView extends BaseView { void scanComplete(List<CacheInfo> mInfoList);
} interface IClearPresenter extends BaseView{ void scanComplete(List<CacheInfo> mInfoList); void startclear();
}
.....
}ok，在 contractUtils 类中，我把v与p的接口都放在这里，这样方便查阅，然后关于他们之间更新数据重复的接口，再封装一次，其中 SppedUpBaseInterface 如下，继承自baseview：
public interface SpeedUpBaseInterface extends BaseView { void scanComplete(List<RunAppInfo> datas); void updateMemory(String msg);
}以后在调试的时候，只要过来查看这个共有契约类就方便多了。
4、封装baseactiviy
这个大家在平时都有做的，我们可以在这里封装activity之间的启动动画，权限管理，还有共有方法等等，而 MVP 这个设计模式，当然也是所有的 activity 都支持的，所有，封装如下，这里只展示 mvp 部分：
public abstract class BaseActivity<V extends BaseView<T>,T extends BasePresenter<V>> extends Activity { public T mPresenter; @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // TODO:OnCreate Method has been created, run FindViewById again to generate code
.....
//这里初始化 mvp
mPresenter = getPresenter();
} @Override
protected void onResume() { super.onResume(); if (mPresenter != null) {
mPresenter.onAttach((V) this);
}
} @Override
protected void onDestroy() { super.onDestroy(); if (mPresenter != null) {
mPresenter.onDetch();
}
} /**
* 不同activity的布局接口
* @return
*/
public abstract int getLayoutId(); public abstract T getPresenter();
}在所有的 onresume 中，将 view 实例给 presenter ，在 ondestroy 中，销毁其中的view，而 baseactivity 后面的泛型，就是根据不同的子类来的。最后用一个抽象方法，getPresenter 把子类的 presenter 拿出来，都在 oncreate 中初始化；
5、子类中的调用
子类中的调用，这里展示 mvp 部分，比如一键加速这里：
View：
public class SpeedUpActivity extends BaseActivity<ContractUtils.ISpeedUpView,SpeedUpPresenter> implements ContractUtils.ISpeedUpView {
.... @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
initdata();
} @Override
public int getLayoutId() { return R.layout.activity_speedup;
} @Override
public SpeedUpPresenter getPresenter() {
mSpeedUpPresenter = new SpeedUpPresenter(this,this); return mSpeedUpPresenter;
} @Override
protected void onResume() { super.onResume();
} private List<RunAppInfo> mlist = new ArrayList<>(); public void speedup(View view) {
mSpeedUpPresenter.startSpeedup();
} @Override
protected void onDestroy() { super.onDestroy();
} @Override
public void getMemory(long availsize, String total) {
mCircleRunView.setMemeryMsg(availsize," / "+total);
} @Override
public void updateMemory(String msg) { if (msg.equals("0")){
Toast.makeText(this, "您的电视非常流畅", Toast.LENGTH_SHORT).show();
}else{
Toast.makeText(this, "共为您节省了： "+msg, Toast.LENGTH_SHORT).show();
}
} @Override
public void fail(String errormsg) {
lg.d("speedupviewerror: "+errormsg);
} @Override
public void scanStatusShow(int current, int maxsize, long size,String path) {
mLoadingText.setText(getString(R.string.loading,current,maxsize));
}
}注意子类集成 baseactivity 的 view 和 presenter，还有抽象方法 getPresenter 即可，基本没啥区别
至于 presenter 的实现，则大家修改一下自己的就行了，比如我的：
public class SpeedUpPresenter extends BasePresenter<ContractUtils.ISpeedUpView> implements
ContractUtils.ISpeedUpPresenter{ private ISpeedUpModel mSpeedUpModel; private ContractUtils.ISpeedUpView mISpeedUpView; private Context mContext; public SpeedUpPresenter(ContractUtils.ISpeedUpView iSpeedUpView, Context context) {
mContext = context;
mISpeedUpView = iSpeedUpView;
mSpeedUpModel = new SpeedUpModel(context,this);
mSpeedUpModel.startScanRunInfo();
}
.....
}关于model的思考
上面，我们对 view 和 presenter 都进行了封装，那model是否也该封装呢？这个不好说，根据自己的项目来，不过一般很少封装，毕竟这个数据逻辑处理的，都是单独出来的；
不过，model 我一般把用单例的，当然这个也有例外，实践才是检验真理的唯一标准；再比如项目中的深度清理，model 的扫描和数据的获取是在presenter 中去初始化，然后再去扫描吗？
No No No，我们说过 p 只是一个观察者，它只负责你model的数据更新后实时更新给v，那么你 model 的怎么做，我就不管了，我只要你的数据就行，想深度扫描这种耗时的，我是在 application里面初始化的；但记得的一点是，不要在application 里做过多的操作，不然会拖慢app的启动的。
封装后与以前的区别
v 与 p 的接口，我们都可以用契约类来实现了，除了方便查阅调试之外，还减少了很多类
封装了 v 与 p 公有的方法，减少累赘代码
关于model的思考
好，以上就是这是我对 MVP 封装的初步理解，如有错误，也欢迎大家留言指正，谢谢。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
