Activity被回收掉之后的网络请求依然请求加载导致崩溃处理方法详解

最新推荐文章于 2023-03-30 10:43:23 发布

Mr_Duoduo

最新推荐文章于 2023-03-30 10:43:23 发布

阅读量1.9k

点赞数

分类专栏：开发随笔文章标签： Activity被回收掉之后的网络请求依然请求加载导致崩溃

本文链接：https://blog.csdn.net/Maiduoudo/article/details/90517438

版权

开发随笔专栏收录该内容

37 篇文章 0 订阅

订阅专栏

在开发中，我们会遇到Activity被回收掉之后，网络请求依然请求加载中，当然数据响应后，数据依然按照逻辑处理回调到想要设置的界面上，但是界面销毁，就会发生崩溃问题。那么如何解决呢？

这里以MVP模式为例进行着述。

这里总结两种方法：

Presenter将持有View置空，即View=null。
Presenter中对View进行弱引用持有。

一、Presenter将持有View置空操作（这里倾向于这种操作方法）

1.对所要操作的Activity或者Fragment进行Ondestroy()监听。

如若界面执行Ondestroy()，即界面销毁被回收，则持有引用需解绑。

 @Override
    public void onDestroy() {
        super.onDestroy();
        if (mPresenter != null){
            mPresenter.detachView();
        }
    }

其中MVP中如何attachView();如何detachView(),这里就不过多赘述，请自行研习。

2.在业务类中IPresenter中对持有View进行判空操作。

if (mView != null){
      mView.showData(data);
      ILog.e(TAG,"View没销毁----------持有界面引用");
}else {
      ILog.e(TAG,"View被销毁--不持有界面引用");
}

这里即避免数据垃圾式回调和应用崩溃。

二、在presenter中对activity对象（View）实行弱引用

也就是不直接持有activity对象的引用，那么当我们的activity被销毁后，我们的presenter所持有的弱引用也能够被内存回收。

1.首先是activity_main.xml文件布局

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/activity_main"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerInParent="true"
        android:text="模拟网络请求" />
</RelativeLayout>

2.创建一个接口ICallBackView

public interface ICallBackView {
    void getMessageSuccess(String msg);
}

3.MainActivity实现这个接口

public class MainActivity extends Activity implements ICallBackView {

    private static final String TAG = "MainActivity";
    private MyPresenter mPresenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        requestWindowFeature(Window.FEATURE_NO_TITLE);
        setContentView(R.layout.activity_main);
        mPresenter = new MyPresenter(this);
        findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                mPresenter.requestMessage();
                finish();
            }
        });
    }

    /**
     * 模拟网络请求成功的回调
     *
     * @param msg
     */
    @Override
    public void getMessageSuccess(String msg) {
        Log.e(TAG, "getMessageSuccess: " + msg);
    }
}

4.创建我们的presenter

public class MyPresenter {

    private static final String TAG = "MyPresenter";
    private WeakReference<ICallBackView> weakReference;

    public MyPresenter(ICallBackView callBackView) {
        weakReference = new WeakReference<>(callBackView);
    }

    /**
     * 模拟请求网络
     */
    public void requestMessage() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    //模拟网络阻塞
                    Log.e(TAG, "run: 正在进行网络请求......");
                    Thread.sleep(3000);

                    ICallBackView view = weakReference.get();
                    if (view != null) {
                        //说明引用还存在，可以进行回调
                        view.getMessageSuccess("请求成功，这是返回的内容......");
                    } else {
                        //说明引用已经被内存回收了
                        Log.e(TAG, "run: 当前引用为null，不进行回调......");
                    }

                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

代码比较简单，当我们的按钮点击模拟网络请求，我们在presenter中模拟网络请求耗时，然后通过弱引用判断activity是否还在，当然我们这里演示所用，不得已在点击按钮后将activity关闭了，正常情况下我们还需要在代码中判断一下activity是否被finish掉了，如下代码所示：

ICallBackView view = weakReference.get();
if (view != null) {
    //说明引用还存在，可以进行回调
    if (!((MainActivity) view).isFinishing()) {
        view.getMessageSuccess("请求成功，这是返回的内容......");
    }
} else {
    //说明引用已经被内存回收了
    Log.e(TAG, "run: 当前引用为null，不进行回调......");
}

我们这里为了演示回调，所以没有加上判断activity是否被finish掉，请大家注意并理解。

下面我们来运行程序看看后台的输入的日志，我们先进行睡眠3秒，时间较短，activity被finish掉后可能还没有被回收掉：

è¿éåå¾çæè¿°
可以看到，虽然MainActivity被finish掉了，但是还没来得及回收掉，所以还能进行回调（当然这里activity被finish掉了，不应该进行回调，不过这里我们要模拟activity被回收的场景，所以不得已这样做，大家理解）。

下面我们模拟一下网络请求比较耗时的场景，睡眠10秒，来看看如何输出日志：

è¿éåå¾çæè¿°
可以看到，当我们的网络请求比较耗时时，我们的activity已经finish掉并且已经被回收了，这里我们的弱引用就拿不到对象activity的引用，所以这里就不会进行网络回调，避免了一些异常的产生。

首先大家理解弱引用的使用，当我们的引用对象为null时，弱引用持有的对象引用就会为null，结合我们的使用场景，我们在准备进行网络回调的时候，应该先判断一下弱引用的引用是否为空，并且应该判断一下要回调的activity是否被finish或destroy掉了，这才是正确的使用方式，如果弱引用持有的引用不为null并且activity没有被finish掉的话，就进行回调方法的调用，这样才能最大限度上保持页面不会引用数据回到导致的各种异常。

这里我选择的第一种方式进行解决问题，个中优劣在于选择。

写在最后，如有不妥及不翔实之处，请指正！