内存泄露

在开发应用的过程中，我们总会遇到内存泄露的问题。现在通过代码列出一些常见的内存泄露的情况以及解决方案。

在安卓中内存泄露常常出现的情况是指组件生命周期已经结束，但是其引用被其他对象持有，得不到释放引起的。常见的内存泄露的情况，主要是有两种：内部类和静态引用的问题。

内部类

内部类的种类

• 成员内部类
• 局部内部类
• 匿名内部类
• 静态内部类

非静态内部类的问题

问题：非静态内部类会持有其外部类的引用。而外部类则不会有这个问题，所以我们在使用内部类的时候，要慎重考虑，尽量使用静态内部类。

PS:在EffectiveJava一书中（第四章第22条：优先考虑静态成员类，P94），作者将这四种情况统一称为嵌套类，非静态内部类（除静态内部类之外的三种）统称为内部类

代码准备

• LeakCanary Square出的用来记录内存泄露的工具，非常好用
• Logger 可以详细地打印出Log信息，包括线程信息，方便查看

常见耗时类泄露

public class ThreadActivity extends BaseActivity {

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

    int i = 0;

    private void showThreadInfo() {

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    while (true) {
                        Thread.sleep(1000);
                        Logger.d(i++ + "");
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

            }
        }).start();
    }
}

在上面的代码中，当TreadActivity的生命周期结束，就会出现内存泄露。这里，主要匿名内部类new Runnable的使用，这是一个耗时的线程操作，它会持有外部类ThreadActivity的使用。当退出TreadActivity时，因Runnable持有其引用，导致其不能释放，造成内存泄露。注意，这里的new Thread并不是一个匿名内部类，仅仅是一个变量而已，Thread类并没有在TreadActivity中定义。

现在，针对这个ThreadActivity做一些改进。代码如下：

public class ThreadActivity extends BaseActivity {
    
    @Override
    protected void onCreate (Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        showWeakThreadInfo();
    }

    int i = 0;

    private void showWeakThreadInfo() {

        new MyThread(new Runnable() {
            @Override
            public void run() {
                try {
                    while (true) {
                        Thread.sleep(1000);
                        Logger.d(i++ + "");
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }

    static class MyThread extends Thread {
        WeakReference<Runnable> mWeakReference;

        public MyThread(Runnable runnable) {
            mWeakReference = new WeakReference<>(runnable);
        }

        @Override
        public void run() {
            super.run();
            if (mWeakReference.get() != null) {
                mWeakReference.get().run();
            }
        }
    }
}

这里，主要做的一个改进是，在MyThread中，持有一个Runable的弱引用，这样，MyThread的执行，就不会对Activity的执行产生什么影响了。但是，在使用Demo的过程中，还是会出现内存泄露的问题。为什么呢？原因在new MyThread的过程中，穿进去的参数new Runable还是持有ThreadActivity的引用，这种写法真的是然并卵。

Weak CallBack解决弱引用问题

主要思想：就是把上面的耗时操作Thread相关代码，提取放置到一个新的类中，进一步弱化跟Activity的引用。代码如下：

public class WeakTask {

    public void excute(CallBack callback) {
        new WeakThread(callback).start();
    }

    private static class WeakThread extends Thread {
        public WeakThread(CallBack callback) {
            this.call = new WeakReference<>(callback);
        }


        private WeakReference<CallBack> call;


        @Override
        public void run() {
            super.run();
            try {
                int i = 0;
                if (call.get() != null) {
                    call.get().onStart(i + "");
                }
                while (true) {
                    Thread.sleep(1000);

                    if (call.get() != null) {
                        call.get().onExcute(i + "");
                    } else {
                        Logger.d("Thread内部:" + i);
                    }
                    i++;

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

其中，使用到的CallBack仅仅做一个回调，代码如下：

public interface CallBack {

    void onStart(String msg);

    void onExcute(String msg);

    void onSucces(String msg);

}

然后，调用实现的代码就比较简单了：

public class WeakCallbackActivity extends BaseActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setTitle(R.string.leak_weak_callback);
        execute();
    }

    private void execute() {
        Logger.d("execute");
        new WeakTask().excute(new CallBack() {

            @Override
            public void onStart(String msg) {
                Logger.d(msg);
            }

            @Override
            public void onExcute(String msg) {
                Logger.d(msg);
            }

            @Override
            public void onSucces(String msg) {
                Logger.d(msg);
            }
        });
    }
}

以上代码所做的主要思想就是在耗时操作类中，持有的回调仅仅是一个弱引用，这样在Activity界面类中传入的CallBack匿名类因为弱引用是可以及时被回收掉的，就避免了Activity的泄露。

Handler引起的内存泄露

提到Handler，我们知道在通过Handler的post以及postDelayed方法会往对应的Looper的MessageQueue中插入一条Message，而Message中的target就是指向当前的handler。这样若是handler使用的是内部类，则会持有外部类的引用。而当这条Message还没被执行，则会导致咱们的外部类不能得到释放。所以，我们在使用Handler的时候，要谨慎一些，尽量使用静态Handler，然后持有Context的弱引用。具体详解可见：Android中Handler引起的内存泄露

静态引用

另一种，常常出现内存泄露的问题就是静态应用了。若是当前的Activity，被一个静态变量持有，会导致当前的Activity不能及时的释放，这样就会导致内存泄露。代码如下：

public class StaticReferenceActivity extends BaseActivity {

    private static Context mContext;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setTitle(R.string.leak_static_reference);
        mContext = this;
    }
}

这里举得例子是比较简单地，当前的StaticReferenceActivity被静态变量mContext所持有，这就要求我们在当前组件生命周期结束时（OnDestory回调）及时释放静态变量所持有的对象。这种常见的情况就是：在做一些静态初始化的过程中，会持有context的引用，譬如好多第三库都要求我们持有的是ApplicationContext的引用。还有就是我们给第三方库或者不知道其内部实现的代码，需要我们对其传入Context对象，这里我们就得小心一二了。

最后，这里使用到得弱引用并不是万能的，它也有自己的问题，若是当一次GC之后，它就会被回收掉，会导致我们的回调收不到。所以我们需要对使用到的耗时操作时间长短，确定使用WeakReference还是SoftWeakRefernce或者强引用做一些筛选判定。

PS:若是还有疑问，则可以针对代码进行一些修改来验证自己的猜想。