从GcRoot角度来分析Handler 内存泄漏
引言
看了好多博客发现都只说了handler会有内存泄漏风险，原因是handler持有了activity的引用。
但是为什么会发生内存泄漏，好像都没讲清楚。
我研究了一下，说一下我的理解。
开始分析
下面我们就来分析内存泄漏的具体原因，我们分两步来说。
- handler是怎么持有Activity引用的
- handler是怎么发生内存泄漏的
handler是怎么持有Activity引用的
Handler的使用，如果不考虑内存泄漏问题，我们一般都这么用，直接在activity中声明handler，并实现handleMessage方法。
public class MainActivity extends AppCompatActivity {
Handler handler = new Handler(){
@Override
public void handleMessage(@NonNull Message msg) {
super.handleMessage(msg);
}
};
}
如果用android studio 3.0以上的版本开发的话，会默认给你一大坨黄色来提示你有内存泄漏风险（This Handler class should be static or leaks might occur ），如下图：
当然这个提示也可以加 “@SuppressLint("HandlerLeak")” 来消除提示。
首先我们要了解什么是匿名内部类，直观点，给两个图。
那么很显然，后面这个大括号就是所谓的匿名内部类，查了下定义，给出关键的两点：
- 匿名内部类就是没有名字的内部类；
- 匿名内部类默认会持有外部类对象；
所以，这里的handler中的内部类持有了Activity这个外部类的引用，即handler持有了Activity的引用。
handler是怎么发生内存泄漏的
上面解释了handler是怎么持有Actvity引用的，这里来解释为什么handler有可能会发生内存泄漏。
说起内存泄漏，不得不提一下gc的原理
简单说明一下，android中使用了很多种算法来进行gc，其中有一个叫“可达性分析算法”，即，从根节点出发，一节一节往下找引用，如果某个对象没有被引用到，那将会标记成“可回收对象”，反之有被引用到，将会被标记为“不可回收对象”。
如下图(图来自：https://blog.csdn.net/luzhensmart/article/details/81431212 ，侵删)
那么哪些对象可以作为gcRoot（根节点）呢，有四种
- 虚拟机栈（栈帧中的本地变量表）中引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
提前透露下，handler中引起内存泄漏的根节点（造成无法被gc回收的原因），是一个静态对象，即“方法区中类静态属性引用的对象”
这里有一点要说明下，上文中的handler使用写法是有可能发生内存泄漏，不是一定会发内存泄漏。那什么时候一定会发生呢，大家肯定都知道，即当某个延时任务没完成，而activity已经退出了，这个时候回发生。
我们来倒推一下。先回忆一下handler的原理。
搞过android的都知道，handler由三部分组成。
- Message(被发送的对象)
- MessageQueue(储存Message对象的阻塞队列)
- Looper(不断从消息队列中取出消息交给handler处理)
如果一个任务没执行完，即handler中有一个message没被执行，那么message 肯定持有messageQueue的引用，因为它是放在这个队列中的。
让我们来看下源码，如果你调用
handler.sendMessage(new Message());
最终会执行到
public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}
第二行的MessageQueue queue = mQueue;我们找一下mQueue在哪里定义的.
这是handler的2个构造方法，空参数会默认调用2个参数的。
public Handler() {
this(null, false);
}
public Handler(@Nullable Callback callback, boolean async) {
...
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
...
}
在14行可以看到mQueue = mLooper.mQueue;,而8行mLooper = Looper.myLooper();，继续跟进去看下myLooper()这个方法：
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
sThreadLocals是啥，看下他的定义。
它是一个静态变量！可以作为gcRoot的根节点变量
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
其实到这里就差不多讲完了，最终就是这个sThreadLocal静态变量作为gcRoot，导致activity无法被回收。
总结
最后总结一下：
handler的内存泄漏原因：
- 当直接在activity中声明handler时，由于后面的匿名内部类，使handler持有了activity的引用。
- 当任务未执行完，即message未被执行完时，message持有了messageQueue的引用。
- messageQueue持有了mLooper的引用。
- mLooper持有sThreadLocal 的引用。
- sThreadLocal 是一个静态变量，无法被回收，最终导致了activity无法被回收，造成了内存泄漏。
最后还有个小问题，handleMessage方法还可以作为参数实现，这样是不是就没有内存泄漏风险了呢。这样写android studio也没提示有风险。
[图片上传失败...(image-6d368f-1592202503163)]
确实这么写可以避免ide的风险提示，但是实际上并没有解决泄漏问题，因为编译后的class中出现了一个extends Handler.Callback的内部类，内部类会持有外部类的引用，因此还是有泄漏风险。
解决办法
- 在destroy中用removeMessage来移除消息
- 试用WeakReference来包裹Activity（有风险，因为gc是无法控制的，万一gc发生导致acivity回收了，就无法正常work了）。
