一种全方案解决内存泄漏的MVP架构

关于MVP的介绍，我们可以参考之前的文章：

Android App开发架构之：MVP

我们再来重温一下MVP架构的特点：

1. V层指的是Activity、Fragment、自定义的View，或者某一个细分了的功能module；

V层职责是专门用来处理UI更新；

注：功能module会带有view，所以也能够处理UI更新；

2. P层用来处理业务逻辑；

比如调用方法前的检测、调用方法前的数据整理，获取数据后的数据处理等；

3. M层用来获取数据；

比如网络请求的数据获取、本地数据库的数据获取、通过计算获取数据等；

解决方案

==============================================================

那么我们该如何打造一款属于自己的MVP框架呢？

常规方法

---

按照MVP层级的划分，那么我们需要构建每一个层级，也就是每一个层级需要有一个实例。

以Activity为例，Activity实例系统已经为我们创建好，那我们就需要创建P层实例和M层实例;

根据MVP层级关系，M层只跟P层对接，那么可以在M层中创建P层实例；

P层只跟M层对接，那么可以在P层中创建M层实例；

各层之间通过各层interface接口定义的函数进行相互调用。

以V层和P层为例：

public class Activity extends AppCompatActivity implements ContractView{

private Presenter mPresenter;

@Override

public void onCreate(Bundle savedInstanceState) {

…

mPresenter = new Presenter();

…

mPresenter.attachView(this);

…

mPresenter.sendMsg();

}

@Override

public void updateMsg(Boolean bool) {

…

}

}

V层创建了P层的实例，并且通过P层实现的接口attachView将自己注入P层，这样P层可以在获取数据后，调用V层的接口updateMsg，将数据返还给V层。

这就是MVP实现的全过程。

优化之泛型

---

通过上面的方法，我们实现了一个简单的MVP架构。

虽然可以用，但是这个架构不是并不完美，还是存在可以优化的地方。

我们知道，MVP对应每一个业务，比如登录有一个MVP，用户信息处理有一个MVP，一个项目下来可能存在几十处这样的MVP，而且我们看到，P层和M层都需要手工创建，那么我们想，P层和M是否可以自动生成实例，而不需要手工new呢？

我们想到了泛型。

public class Test {

…

}

T是一个类型参数，我们可以根据已知的类型参数，再通过newInstance获取这个类型参数的实例。

那么我们把P层和M层类型作为泛型的类型参数带入，那是不是就可以创建出P层和M层的实例了呢？

public class TestActivity<P, M> {

…

}

P和M的实例，我们可以通过函数来自动创建，这样我们就实现了通过泛型<P, M>的声明，能够自动创建其对应的实例，无需手工new实例。

进一步，我们可以考虑将这些每一个具体Activity都涉及到的操作抽取出来，放入一个抽象类BaseActivity中，由BaseActivity处理创建P层和M层实例的工作。

public abstract class BaseActivity<P, M> {

…

}

具体的业务Activity只要继承它既可：

public class TestActivity extends BaseActivity<P, M> {

…

}

优化之减少接口

---

MVP架构每个层之间通过接口交互，这样就会导致接口过多，代码复杂度也随之提升，并且带来了阅读和调试的不便。

为了解决这样的不便，我们考虑减少接口的数量。

总体来看，接口是显示层和数据层之间的桥梁，P层和M层总体上都是为V层提供数据的。所以我们决定做以下条件的优化：

1. 为了减少接口的泛滥，只在V层和P层之间定义接口；

2. P层和M层之间只存在P层对M层的单向调用；

3. M层专门用来获取数据，包括异步操作和耗时操作；

4. M层返回Observable类型给P层；

举例来看，P层对M层的调用：

public class DisposablePresenter extends DisposableContract.Presenter {

@Override

void sendMsg() {

addSubscribe(

getModel().executeMSg()

.compose(RxUtil.applySchedulers())

.subscribe(bool -> getView().updateMsg(bool))

);

}

}

M层的处理：

public class DisposableModel implements DisposableContract.Model {

@Override

public Observable executeMSg() {

return Observable.create(emitter -> {

try {

Thread.sleep(2000); // 假设此处是耗时操作

} catch (Exception e) {

e.printStackTrace();

emitter.onError(new RuntimeException());

}

emitter.onNext(true);

}

);

}

}

优化之生命周期

---

通过泛型的优化，我们看到了一个使用更加便捷的MVP。

但是是不是可以放心使用高枕无忧呢？答案并不是这样的。

我们知道MVP的特点是各层分而治之，各层之间通过接口连接。

有个明显的问题是，以Activity这个V层为例，Activity是存在生命周期的，也就是Activity可能已经被系统回收掉了，但是P层仍然持有V层的引用，这样就导致了内存泄漏。

如果解决这个内存泄漏的问题呢？

我们通过以下4种解决方案来一一解决。

1. 弱引用

内存泄漏是因为P层对V层的强引用导致的。那么我们就可以通过P层对V层的弱引用来解决。

private Reference mRefView;

@Override

public void attachView(V view) {

mRefView = new WeakReference<>(view);

}

@Override

public void detachView() {

if (mRefView != null) {

mRefView.clear();

mRefView = null;

}

}

可以看到，在将V层通过attachView注入到P层时，使用WeakReference实现P层对V层的弱引用。

并且在页面销毁的时候通过detachView主动解除弱引用。

但是这里有一个问题，就是如果V层被系统回收了，P层也解除了对V层的引用。也不存在内存泄漏问题。但是，P层处理完后又开始调用V层，那么这个时候就会遇到V层为null，如果没有处理这个null，app就会崩溃。这也是我们不愿意见到的。

那是否在每一个使用到V层的地方都加一个null判断呢？理论上是这样，但是这样会增加很多代码量，而且代码阅读起来也不美观。

那么我们的解决方案是，在调用V的地方抛出一个异常，然后在自定义的CrashHandler里面对这个专门的异常不进行处理，这也app就不会有感知。

protected V getView() {

if (!isViewAttached()) {

throw new IllegalStateException(“mvp’s view is not attached, please check again!”);

}

return mRefView.get();

}

扔出IllegalStateException异常。

public class CrashHandler implements Thread.UncaughtExceptionHandler {

private Context mContext;

private Thread.UncaughtExceptionHandler mDefaultHandler;

private static CrashHandler INSTANCE = new CrashHandler();

public static CrashHandler getInstance() {

return INSTANCE;

}

public void init(Context context) {

mContext = context.getApplicationContext();

mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler();// 获取系统默认的UncaughtException处理器

Thread.setDefaultUncaughtExceptionHandler(this);// 设置该CrashHandler为程序的默认处理器

}

@Override

public void uncaughtException(Thread t, Throwable e) {

if (mDefaultHandler != null) {

if (Constant.EXCEPTION_MVP_VIEW_NOT_ATTACHED.equals(e.getMessage())) {// for MVP when presenter calls view but view has already destroyed

return;

}

mDefaultHandler.uncaughtException(t, e);// 退出程序

}

}

}

自定义CrashHandler中，遇到这个异常直接return；

2. RxJava之Disposable

每一个RxJava调用返回disposable，然后通过CompositeDisposable对disposable进行管理。

通过CompositeDisposable添加disposable类，并且通过CompositeDisposable切断所有订阅事件，解除上下游之间的引用关切，并且切断上下游之间的数据传递。

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**

[外链图片转存中…(img-P2fVu4H3-1715808623076)]

[外链图片转存中…(img-lHJl1O5P-1715808623077)]

[外链图片转存中…(img-VYMcctAQ-1715808623079)]

[外链图片转存中…(img-8KZfmWZm-1715808623080)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！