Android中常见的内存泄漏 & 解决方案

内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。简单得讲就是本该被释放的内存无法被释放。

Java语言的一个极大的优势就是通过垃圾收集器（Garbage Collection，GC）自动管理内存的分配与回收，尽管在很大程度上减轻了开发人员维护和管理内存分配回收的负担，但是这并不意味着Java中就不存在内存泄漏，我们在日常开发中还是会碰到一些内存泄漏的场景。

学习如何判断Java中是否有内存泄露，以及如何解决内存泄漏的问题之前，我们应该了解Java是如何管理内存的，想了解更多推荐阅读：

垃圾收集算法
内存分配与回收策略

接下来总结一些在Android开发过程中比较常见的内存泄漏场景

1、Handler

由于Android开发规范的限制，系统是不允许开发者在子线程中更新UI控件，如果你试图这么做，程序就会抛出CalledFromWrongThreadException异常。

android.view.ViewRoot$CalledFromWrongThreadException:
Only the original thread that created a view hierarchy can touch its views.

这个情况下，子线程可以通过Handler 向主线程发送消息，来通知主线程更新UI控件。Handler比较简单的用法就是直接创建一个Handler对象供子线程使用。

private Handler handler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case 0:
                //更新UI操作
                break;
            case 1:
                break;
            default:
                break;
        }
        super.handleMessage(msg);
    }
};

这看起来好像没什么问题，幸运的是，AndroidStudio为我们提供了HandlerLeak警告信息。

image.png

翻译过来大致的意思是这样的：

Handler类应该被定义为静态的，否则可能会发生内存泄漏。
由于Handler被声明为一个内部类，因此它可能会阻止垃圾回收器回收它的外部类。如果Handler使用的不是主线程的Looper或MessageQueue，不会有什么问题，否则你就需要采取正确的措施防止问题的发生。具体方法如下：Handler需要声明为静态类；如果你需要使用外部类对象来创建一个Handler实例，确保所有对外部类对象的引用都是弱引用。弱引用的特点是：垃圾回收时，无论内存是否足够，都会回收。

引用链：Message -> MessageQueue -> Looper -> Handler -> Activity

改进方案：

private static class SafeHandler extends Handler {

    private WeakReference<Context> contextWeakReference;

    public SafeHandler(Context context) {
        this.contextWeakReference = new WeakReference<>(context);
    }

    @Override
    public void handleMessage(Message msg) {
        if (contextWeakReference != null) {
            Context context = contextWeakReference.get();
            if (context != null) {
                //更新UI操作
                switch (msg.what) {
                    case 0:
                        break;
                    case 1:
                        break;
                    default:
                        break;
                }
            }
        }
        super.handleMessage(msg);
    }
}

现在我们假设外部类是一个Activity，并且已经被结束掉了。这个时候Handler内还有消息正在处理，由于Handler只是持有Activity对象的弱引用，所以GC仍然会在检查的时候把Activity回收掉。这样就避免了内存泄漏了。

2、非静态内部类

大部分情况下，使用内部类可以提高代码的封装性和可读性。但是如果我们创建了一个静态的内部类实例，这个时候我们就要警惕内存泄漏发生的可能性了。

private static Object inner;

    void createInnerClass() {
        class InnerClass {
        }
        inner = new InnerClass();
    }

内部类的优势之一就是它会隐式地持有其外部类的引用，但是不幸的是，导致内存泄漏的原因，就是内部类持有外部类实例的强引用。

3、在异步任务中使用匿名类

与非静态内部类类似，匿名类也会隐式地持有其外部类的引用，所以很容易导致内存泄漏。

   void startAsyncTask() {
        new AsyncTask<Void, Void, Void>() {
            @Override protected Void doInBackground(Void... params) {
                while(true);
            }
        }.execute();
    }

例如：当异步任务在后台执行耗时任务期间，Activity不幸被销毁了，这个被AsyncTask持有的Activity实例就不会被垃圾回收器回收，直到异步任务结束。
类似的例子还有Thread和TimerTask。

4、单例模式

很多时候，我们为了防止创建过多不必要的实例，往往会使用到单例设计模式。但是单例设计模式的静态特性会使他的生命周期和应用程序的生命周期一样长，这就说明了如果一个对象不再使用了，而这时单例对象还在持有该对象的引用，这时GC就会无法回收该对象，造成了内存泄露的情况。

    private static volatile ImageLoaderManager mInstance;
    public static ImageLoaderManager getInstance(Context context) {
        if (mInstance == null) {
            synchronized (ImageLoaderManager.class) {
                if (mInstance == null) {
                    mInstance = new ImageLoaderManager(context);
                }
            }
        }
        return mInstance;
    }

这是一个很常用的单例模式，假设我们传入的Context是Activity，那么即使我们销毁了宿主Activity，但我们的静态实例仍然持有对Activity对象的引用，这时候就会造成内存泄漏。所以正确的写法应该是：

    private static ImageLoaderManager mInstance;
    public static ImageLoaderManager getInstance(Context context) {
        if (mInstance == null) {
            synchronized (ImageLoaderManager.class) {
                if (mInstance == null) {
                    //传入ApplicationContext
                    mInstance = new ImageLoaderManager(context.getApplicationContext());
                }
            }
        }
        return mInstance;
    }

这样我们不论传入哪种Context，最后使用的始终是Application的Context，这样单例的生命周期和应用一样长，就不会造成内存泄漏了。

5、静态View

思考这样一个场景，如果一个View初始化过程会耗费大量资源，而且在一个Activity生命周期内保持不变，那可以把它变成static，这样就可以避免每次启动Activity都要读取并渲染View，但是强制延长Activity的生命周期是相当危险而且不必要的，所以还是尽量避免这种情况的发生。

6、注册监听器

有些时候，当我们把服务注册到监听器中，这会让服务持有 activity 的引用，如果程序员忘记在 activity 销毁时取消注册，就可能会导致 activity 泄漏。例如EditText内容变化监听：

editText.addTextChangedListener(new TextWatcher() {
            @Override
            public void beforeTextChanged(CharSequence s, int start, int count, int after) {

            }

            @Override
            public void onTextChanged(CharSequence s, int start, int before, int count) {
                //执行耗时任务
            }

            @Override
            public void afterTextChanged(Editable s) {

            }
        });

当Activity被销毁，但是耗时任务还在执行，这个时候TextWatcher对Activity的引用依然存在，导致Activity无法被回收。因此正确的做法是在Activity被销毁时移除监听事件：

editText.removeTextChangedListener(textWatcher);

---

参考链接

https://www.jianshu.com/p/ac00e370f83d
http://tryenough.com/android-momeryleak
https://blog.csdn.net/unicorn97/article/details/81009204