常见的内存泄漏场景分析

博主最近遇到了很多内存泄漏的问题，其实说白了，在Android里面的内存泄漏最多的就是activity或者fragment对象，
当他们执行了ondestory周期函数之后，内存当中的对象却得不到释放，因而造成了内存泄漏。
以下是常见的几种容易造成内存泄漏的场景。

1 匿名内部类

匿名内部类非常常见，特别是一些回调函数经常会使用。匿名内部类会持有外部类的引用，如果在activity当中使用，就得注意是否可能会超出activity的生命周期。
例子
例如以下的一段代码，Runnable就是一个匿名内部类，在其内部持有了外部类的引用，若当Activity执行了ondestroy周期函数之后，Runnable还在排队或者还未执行完成，就会因为Runnable持有Activity引用，而使得Activity无法得到释放，造成内存泄漏。

ThreadPool.execute(new Runnable() {
    @Override
    public void run() {
        //持有外部类的引用
    }
});

改进
可以改成静态变量

private static Runnable myRunnable = new Runnable() {
    @Override
    public void run() {
        //不持有Activity引用
    }
};

ThreadPool.execute(myRunnable);

或者改成静态内部类

static class MyRunnable implements Runnable{

    @Override
    public void run() {
        //不持有Activity引用，或者可以通过参数的方式传递一个activity的弱饮用
    }
}

ThreadPool.execute(new MyRunnable());

2 非静态内部类

非静态内部类会隐试持有外部类，若超过了activity的生命周期，就会造成泄露
例子
MyRunnable是一个非静态内部类，会持有外部类引用，若将其放在activity内部，则会持有activity引用，会有内存泄漏的风险。

class MyRunnable implements Runnable{

    @Override
    public void run() {
        //持有Activity引用
    }
}

ThreadPool.execute(new MyRunnable());

改进
参照匿名内部类的改进方法，将其改成静态内部类

3 单例或者静态变量持有

单例和静态变量持有其实是一回事，单例模式也是一个静态变量。
例子
如下所示是一个很常见的单例模式，有时候activity需要回调函数来更新界面，例如网络访问，图片下载等场景，就有类似addCallBack的函数，当网络数据返回时，再执行callback函数。若callback持有了activity，而list持有callback，instance持有list，这样就形成了一条引用链。
当activity已经执行完ondestroy之后，instance仍旧持有这一条引用链，就会造成内存泄漏。

public class TestSingle {

    private static volatile TestSingle instance;

    private List<CallBack> list;

    private TestSingle() {
        list = new ArrayList<>();
    }

    public static TestSingle getInstance() {
        if (instance == null) {
            synchronized (TestSingle.class) {
                if (instance == null) {
                    instance = new TestSingle();
                }
            }
        }
        return instance;
    }

    public void addCallBack(CallBack callBack) {
        list.add(callBack);
    }

    public void removeCallBack(Callback callback) {
        list.remove(callback);
    }

}

改进
在周期函数里面执行removeCallBack函数，切断引用链

TestSingle.getInstance().removeCallBack(callBack);

5 Handler

如以下例子所示，activity可能已经被销毁，但是handler当中仍然有未被执行的runnable
例子

public class TestActivity extends Activity {


    private Handler handler = new Handler();

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                //message持有了activity饮用
            }
        },5000);
    }
    
}

改进
在ondestroy里面清空所有的message

handler.removeCallbacksAndMessages(null);

或者将Runnable做成静态内部类，弱引用外部activity

6 webview泄露

webview占用内存较大，产生内存泄漏也不好排查，这里不去深究造成内存泄漏的原因，只提供一种解决思路，为webview单独开辟一个进程，当使用结束之后结束进程，这样就可以避免webview造成内存泄漏了。
例子

public class WebviewActivity extends Activity {

    private WebView mWebView;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mWebView = (WebView) findViewById(R.id.test_webview);
        mWebView.loadUrl("www.baidu.com");
    }

    protected void destroyWebview(){
        if(mWebView != null){
            mWebView.pauseTimers();
            mWebView.removeAllViews();
            mWebView.destroy();
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        destroyWebview();
        android.os.Process.killProcess(Process.myPid());
    }
}

总结

这里介绍了常见的容易造成内存泄漏的场景，还有一些场景如Asynctask或者HandlerThread其实都能在这当中能够找到对应的类型，就不再单独分析了。