從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了）。
