Handler可能造成内存泄漏（四） Handler可能造成内存泄漏（四）

Handler可能造成内存泄漏（四）

本文原创，转载请经过本人准许。

写在前面：
不知不觉中我们已经进行了三篇有关Android消息机制的研究，温故知新，我们先来回顾一下：
子线程为何不能更新UI（一）
第一篇中我们探究了，在Android设计之时，为何子线程允许更新UI。官方给出的解释是由于线程安全（Thread Safe）问题。（当然也有一些其他方面的猜想）
解决在子线程更新UI崩溃问题（二）
第二篇中，我们总结了三种崩溃解决的办法。

Activity.runOnUIThread();
View.post();
Handler;

我们本着寻找最优解的思路比较了三种解决办法，发现代码的实现方式都为Handler，从而真正引出了Android消息机制，Handler。
带着这篇去通关所有Handler的提问（三）
第三篇文章是我们这个系列的重头戏，我用一个还算生动的故事，为大家解释了Handler和相关核心类的关系。
OK，回顾之后，我们正式来开始本篇文章。
内存泄漏是怎么一回事？可以看到，标题中有一个显眼的名词，就是内存泄漏，我想有必要给初学的朋友们讲讲何为内存泄漏。
在讨论内存泄漏之前，先简单的说说Android中内存的回收
Dalivik虚拟机扮演了常规的垃圾回收角色，为了GC能够从App中及时回收内存，我们需要时时刻刻在适当的时机来释放引用对象，Dalvik的GC会自动把离开活动线程的对象进行回收。
什么是Android内存泄漏：
虽然Android是一个自动管理内存的开发环境，但是垃圾回收器只会移除那些已经失去引用的、不可达的对象，在十几万、几十万行代码中，由于你的失误使得一个本应该被销毁的对象仍然被错误的持有，那么该对象就永远不会被释放掉，这些已经没有任何价值的对象，仍然占据聚集在你的堆内存中，GC就会被频繁触发，多说几句，如果手机不错，一次GC的时间70毫秒，不会对应用的性能产生什么影响，但是如果一个手机的性能不是那么出色，一次GC时间120毫秒，出现大量的GC操作，我相信用户就能感觉到了吧。这些无用的引用堆积在堆内存中，越积越多最终导致Crash。
有关一些性能优化推荐给大家一个我总结的博客。
Android性能优化总结
【Handler可能造成内存泄漏（四）】扯得好像远了一点，既然明白了内存泄漏是怎么回事，那与Handler又有什么关系呢？
Handler造成的内存泄漏参考一篇外文：
inner-class-handler-memory-leak

文章图片
使用Handler时，给出的warnning 当我们正常使用Handler时，会给出一个warning提示。翻译过来就是，这个Handler类应该是静态的，否则可能造成内存泄漏。
当我们简单的使用Handler的时候，并不会踩到内存泄漏这个坑，不过当Handler作为一个内部类或者匿名类时，这个问题就可能发生。
在上篇中，我们知道，当Android启动之时，ActivityThread类中，会创建UI线程的Looper和MessageQueue
MessageQueue中的消息会被一个接一个处理。应用的所有事件(比如Activity生命周期回调方法，按钮点击等等)都会被当做一个消息对象放入到Looper的消息队列中，然后再被逐一执行。UI线程的Looper存在于整个应用的生命周期内。
当在UI线程中创建Handler对象时，它就会和UI线程中Looper的消息队列进行关联。发送到这个消息队列中的消息会持有这个Handler的引用，这样当Looper最终处理这个消息的时候framework就会调用Handler#handleMessage(Message)方法来处理具体的逻辑。
在Java中，非静态的内部类或者匿名类会隐式的持有其外部类的引用，而静态的内部类则不会。
那么，内存到底是在哪里泄露的呢？其实泄漏发生的还是比较隐晦的，但是再看看下面这段代码：

public class SampleActivity extends Activity {private final Handler mLeakyHandler = new Handler() { @Override public void handleMessage(Message msg) { // ... } }@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Post a message and delay its execution for 10 minutes. mLeakyHandler.postDelayed(new Runnable() { @Override public void run() { /* ... */ } }, 1000 * 60 * 10); // Go back to the previous Activity. finish(); } }

当activity被finish的时候，延迟发送的消息仍然会存活在UI线程的消息队列中，直到10分钟后它被处理掉。这个消息持有activity的Handler的引用，Handler又隐式的持有它的外部类(这里就是SampleActivity)的引用。这个引用会一直存在直到这个消息被处理，所以垃圾回收机制就没法回收这个activity，内存泄露就发生了。需要注意的是：15行的匿名Runnable子类也会导致内存泄露。非静态的匿名类会隐式的持有外部类的引用，所以context会被泄露掉。
解决这个问题也很简单：在新的类文件中实现Handler的子类或者使用static修饰内部类。静态的内部类不会持有外部类的引用，所以activity不会被泄露。如果你要在Handler内调用外部activity类的方法的话，可以让Handler持有外部activity类的弱引用，这样也不会有泄露activity的风险。关于匿名类造成的泄露问题，我们可以用static修饰这个匿名类对象解决这个问题，因为静态的匿名类也不会持有它外部类的引用。

public class SampleActivity extends Activity {/** * Instances of static inner classes do not hold an implicit * reference to their outer class. */ private static class MyHandler extends Handler { private final WeakReference mActivity; public MyHandler(SampleActivity activity) { mActivity = new WeakReference(activity); }@Override public void handleMessage(Message msg) { SampleActivity activity = mActivity.get(); if (activity != null) { // ... } } }private final MyHandler mHandler = new MyHandler(this); /** * Instances of anonymous classes do not hold an implicit * reference to their outer class when they are "static". */ private static final Runnable sRunnable = new Runnable() { @Override public void run() { /* ... */ } }; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Post a message and delay its execution for 10 minutes. mHandler.postDelayed(sRunnable, 1000 * 60 * 10); // Go back to the previous Activity. finish(); } }

静态和非静态内部类的区别是非常微妙的，但这个区别是每个Android开发者应该清楚的。那么底线是什么？如果要实例化一个超出activity生命周期的内部类对象，避免使用非静态的内部类。建议使用静态内部类并且在内部类中持有外部类的弱引用。