总说 Handler 使用不当会导致内存泄露，真正的原因到底是什么？本文带你重新理解个中原因 ，并给出完整的解决方案！
1. 什么是 Handler 使用不当？
先搞清楚什么叫 Handler 使用不当？
一般具备这么几个特征：
- Handler 采用匿名内部类或内部类扩展，默认持有外部类
Activity的引用：
// 匿名内部类 override fun onCreate(savedInstanceState: Bundle?) { ... val innerHandler: Handler = object : Handler(Looper.getMainLooper()) { override fun handleMessage(msg: Message) { Log.d( "MainActivity", "Anonymous inner handler message occurred & what:${msg.what}" ) } } }
// 内部类 override fun onCreate(savedInstanceState: Bundle?) { ... val innerHandler: Handler = MyHandler(Looper.getMainLooper()) } inner class MyHandler(looper: Looper): Handler(looper) { override fun handleMessage(msg: Message) { Log.d( "MainActivity", "Inner handler message occurred & what:\${msg.what}" ) } }
- Activity 退出的时候 Handler 仍可达，有两种情况：
- 退出的时候仍有 Thread 在处理中，其引用着 Handler
- 退出的时候虽然 Thread 结束了，但 Message 尚在队列中排队处理或正在处理中，间接持有 Handler
override fun onCreate(savedInstanceState: Bundle?) { ... val elseThread: Thread = object : Thread() { override fun run() { Log.d( "MainActivity", "Thread run" ) sleep(2000L) innerHandler.sendEmptyMessage(1) } }.apply { start() } }
2. 为什么会内存泄露？
上述的 Thread 在执行的过程中，如果 Activity 进入了后台，后续因为内存不足触发了 destroy。虚拟机在标记 GC 对象的时候，会发生如下两种情形：
Thread 尚未结束，处于活跃状态
活跃的 Thread 作为 GC Root 对象，其持有 Handler 实例，Handler 又默认持有外部类 Activity 的实例，这层引用链仍可达：
Thread 虽然已结束，但发送的 Message 还未处理完毕
Thread 发送的 Message 可能还在队列中等待，又或者正好处于 handleMessage() 的回调当中。此刻 Looper 通过 MessagQueue 持有该 Message，Handler 又作为 target 属性被 Message 持有，Handler 又持有 Activity，最终导致 Looper 间接持有 Activity。
大家可能没有注意到主线程的 Main Looper 是不同于其他线程的 Looper 的。
为了能够让任意线程方便取得主线程的 Looper 实例，Looper 将其定义为了静态属性 sMainLooper。
public final class Looper { private static Looper sMainLooper; // guarded by Looper.class ... public static void prepareMainLooper() { prepare(false); synchronized (Looper.class) { sMainLooper = myLooper(); } } }
静态属性也是 GC Root 对象，其通过上述的应用链导致 Activity 仍然可达。
这两种情形都将导致 Activity 实例将无法被正确地标记，直到 Thread 结束 且 Message 被处理完毕。在此之前 Activity 实例将得不到回收。
内部类 Thread 也会导致 Activity 无法回收吧？
为了侧重阐述 Handler 导致的内存泄漏，并没有针对 Thread 直接产生的引用链作说明。
上面的代码示例中 Thread 也采用了匿名内部类形式，其当然也持有 Activity 实例。从这点上来说，尚未结束的 Thread 会直接占据 Acitvity 实例，这也是导致 Activity 内存泄露的一条引用链，需要留意！
3. 子线程 Looper 会导致内存泄露吗？
为了便于每个线程方便拿到独有的 Looper 实例，Looper 类采用静态的 sThreadLocal 属性管理着各实例。
public final class Looper { static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>(); ... public static @Nullable Looper myLooper() { return sThreadLocal.get(); } }
可是作为静态属性的话，sThreadLocal 也是 GC Root 对象。那从这个角度讲会不会也间接导致 Message 无法回收呢？
会，但本质上不是因为 ThreadLocal，而是因为 Thread。
翻看 ThreadLocal 的源码，你会发现：目标对象并不存放在 ThreadLocal 中，而是其静态内部类 ThreadLocalMap 中。加上为了线程独有，该 Map 又被 Thread 持有，两者的生命周期等同。
// TheadLocal.java public class ThreadLocal<T> { public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); } // 创建 Map 并放到了 Thread 中 void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); } ThreadLocalMap getMap(Thread t) { return t.threadLocals; } }
// Thread.java public class Thread implements Runnable { ThreadLocal.ThreadLocalMap threadLocals = null; }
更进一步的细节是：ThreadLocalMap 中的元素 Entry 采用弱引用持有作为 key 的 ThreadLocal 对象，但作为 value 的目标对象则被强引用着的。
这就导致 Thread 间接持有着目标对象，比如本次的 Looper 实例。这样可以确保 Looper 的生命周期和 Thread 保持一致，但 Looper 生命周期过长会有内存泄漏的风险（当然这不是 Looper 设计者的锅）。
// TheadLocal.java public class ThreadLocal<T> { ... static class ThreadLocalMap { private Entry[] table; static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } } } }
当弱引用的 key 实例因为 GC 发生会被切断和 Map 的引用关系，但直到下一次手动执行 Entry 的 set、get 或 remove 前，value 都没被置为 null。这段时间 value 都被强引用着，造成隐患。
The entries in this hash map extend WeakReference, using its main ref field as the key (which is always a ThreadLocal object).
Note that null keys (i.e. entry.get() == null) mean that the key is no longer referenced, so the entry can be expunged from table.
Such entries are referred to as “stale entries” in the code that follows.
但需要注意的是：本处 Looper 持有的实例 sThreadLocal 是静态的，进程结束之前都不会被回收，不可能发生上述提及的 key 被回收 value 被孤立的情况。
简言之，Looper 的 ThreadLocal 不会导致内存泄漏。
回到 Thread，因其强引用 Looper，所以 Thread 仍然会因为这个因素导致 Message 发生内存泄漏。 比如：向子线程 Handler 发送了内部类写法的 Runnable，当 Activity 结束的时候该 Runnable 尚未抵达或正在执行过程中，那么 Activity 会因为如下的引用链一直可达，即发生内存泄漏的可能。
解决办法不复杂：
Activity 结束的时候移除子线程 Handler 中所有未处理 Message，比如 Handler#removeCallbacksAndMessages()。这将会切断 MessageQueue 到 Message，以及 Message 到 Runnable 的引用关系
更好的办法是调用 Looper#quit() 或 quitSafely()，它将清空所有的 Message 或未来的 Message，并促使 loop() 轮询的结束。子线程的结束则意味着引用起点 GC Root 不复存在
最后，明确几点共识：
管理 Looper 实例的静态属性 sThreadLocal，并不持有实际存放 Looper 的 ThreadLocalMap，而是通过 Thread 去读写 。这使得 sThreadLocal 虽贵为 GC Root，但无法达成到 Looper 的引用链，进而从这条路径上并不能构成内存泄漏！
另外，因其是静态属性，也不会发生 key 被回收 value 被孤立的内存泄漏风险～
最后，由于 Thread 持有 Looper value，从这条路径上来说是存在内存泄漏的可能的
4. 非内部类的 Handler 会内存泄露吗？
上面说过匿名内部类或内部类是 Handler 造成内存泄漏的一个特征，那如果 Handler 不采用内部类的写法，会造成泄露吗？
比如这样：
override fun onCreate(...) { Handler(Looper.getMainLooper()).apply { object : Thread() { override fun run() { sleep(2000L) post { // Update ui } } }.apply { start() } } }
仍然可能造成内存泄漏。
虽然 Handler 不是内部类，但 post 的 Runnable 也是内部类，其同样会持有 Activity 的实例。另外，post 到 Handler 的 Runnable 最终会作为 callback 属性被 Message 持有。
基于这两个表现，即便 Handler 不是内部类了，但因为 Runnable 是内部类，同样会发生 Activity 被 Thread 或 Main Looper 不当持有的风险。
5. 网传的 Callback 接口真得能解决吗？
网上有种说法：创建 Handler 时不覆写 handleMessage()，而是指定 Callback 接口实例，这样子可以避免内存泄漏。理由是这种写法之后 AndroidStudio 就不会再弹出如下的警告：
This Handler class should be static or leaks might occur.
事实上，Callback 实例如果仍然是匿名内部类或内部类的写法，仍然会造成内存泄漏，只是 AS 没弹出这层警告而已。
private Handler mHandler = new Handler(new Handler.Callback() { @Override public boolean handleMessage(Message msg) { return false; } });
比如上面的这种写法，Handler 会持有传递进去的 Callback 实例，而 Callback 作为内部类写法，默认持有外部类 Activity 的引用。
public class Handler { final Callback mCallback; public Handler(@NonNull Looper looper, @Nullable Callback callback) { this(looper, callback, false); } public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) { ... mCallback = callback; } }
无论是从 Thread 活跃的角度，还是从 Thread 结束但 Message 仍然未执行完的角度来说，都将导致 Activity 仍然可被 GC Root 间接引用而发生内存泄漏的风险。
本质来说和上面的 Runnable 例子是一样的问题：
6. 如何正确使用 Handler？
GC 标记的时候 Thread 已结束并且 Message 已被处理的条件一旦没有满足，Activity 的生命周期就将被错误地延长，继而引发内存泄露！
那如何避免这种情况的发生呢？针对上面的特征，其实应该已经有了答案：
一则将强引用 Activity 改为弱引用
二则及时地切断两大 GC Root 的引用链关系：Main Looper 到 Message，以及结束子线程
代码示例简述如下：
- 将
Handler或Callback或Runnable定义为静态内部类：
```kotlin class MainActivity : AppCompatActivity() { private class MainHandler(looper: Looper?, referencedObject: MainActivity?) : WeakReferenceHandler<MainActivity?>(looper, referencedObject) { override fun handleMessage(msg: Message) { val activity: MainActivity? = referencedObject if (activity != null) { // ... } } } } ``` ※：`Kotlin` 里 `class` 中定义 `class` 即为静态内部类，内部类则需要 `inner` 的关键字描述
还需要弱引用外部类的实例：
open class WeakReferenceHandler<T>(looper: Looper?, referencedObject: T) : Handler(looper!!) { private val mReference: WeakReference<T> = WeakReference(referencedObject) protected val referencedObject: T? protected get() = mReference.get() }
onDestroy 的时候切断引用链关系，纠正生命周期：
- Activity 销毁的时候，如果子线程任务尚未结束，及时中断 Thread：
override fun onDestroy() { ... thread.interrupt() }
如果子线程中创建了 Looper 并成为了 Looper 线程的话，须手动 quit。比如 HandlerThread：
override fun onDestroy() { ... handlerThread.quitSafely() }
主线程的 Looper 无法手动 quit，所以还需手动清空主线程中 Handler 未处理的 Message：
override fun onDestroy() { ... mainHandler.removeCallbacksAndMessages(null) }
结语
回顾一下本文的几个要点：
持有 Activity 实例的 Handler 处理，其生命周期应当和 Activity 保持一致
如果 Activity 本该销毁了，但异步 Thread 仍然活跃或发送的 Message 尚未处理完毕，将导致 Activity 实例的生命周期被错误地延长
造成本该回收的 Activity 实例被子线程 或 Main Looper 占据而无法及时回收
简单来讲的正确做法：
使用 Handler 机制的时候，无论是覆写 Handler 的 handleMessage() 方式，还是指定回调的 Callback 方式，以及发送任务的 Runnable 方式，尽量采用静态内部类 + 弱引用，避免其强引用持有 Activity 的实例。
确保即便错误地延长了生命周期，Activity 也能及时被 GC 回收
同时在 Activity 结束的时候，及时地清空 Message、终止 Thread 或退出 Looper，以便回收 Thread 或 Message。
确保能彻底切断 GC Root 抵达 Activity 的引用链
