本篇文章已授權微信公眾號 guolin_blog （郭霖）獨家釋出
本文首發於本人簡書
前言
好記性不如爛筆頭。
這是一個系列文章，將會包括：
- Handler全家桶之 —— Handler 原始碼解析
- Handler全家桶之 —— HandlerThread & IntentService 原始碼解析
- Handler全家桶之 —— AsyncTask 原始碼解析
- Handler全家桶之 —— View.post() 原始碼解析
Handler 是 Android 開發中舉足輕重的一種執行緒機制，很多地方，包括 Android 原始碼都不少地方用到了這個。
這篇文章將會從原始碼角度分析 Handler 機制以及一些常見的疑惑點。
注意：文章較長，推薦閱讀順序如下
- 順序閱讀(推薦)
- 時間不充足，或者感覺枯燥，可以先看3.7的梳理以及第5點總結部分，再回頭看其他細節
- 檢視目錄，根據感興趣的內容閱讀
- 收藏後慢慢看(牆裂推薦【手動滑稽】)
目錄
1. 作用
2. 基本用法
3. 原始碼解析
-
3.1 為什麼 Handler 能夠切換執行緒執行？
-
3.2 Handler.post(Runnable) 方法是執行在新的執行緒嗎？
-
3.3 Handler(Callback) 跟 Handler() 這兩個構造方法的區別在哪？
-
3.4 子執行緒可以建立 Handler 嗎？
-
3.5 為什麼主執行緒不用呼叫 Looper.prepare() ？
-
3.6 為什麼建立 Message 物件推薦使用
Message.obtain()獲取？ -
3.7 梳理
4. 常見問題&技巧
-
4.1 為什麼 Handler 會造成記憶體洩漏？
-
4.2 怎麼防止 Handler 記憶體洩漏？
-
4.3 Loop.loop() 為什麼不會造成應用卡死？
5. 總結
1. 作用
Handler 是一種用於執行緒間的訊息傳遞機制。
因為 Android 中不允許在非主執行緒更新UI，所以最常使用的地方就是用於子執行緒獲取某些資料後進行UI的更新。
2.基本用法
step1:建立Handler例項
//1.自定義Handler類
static class CustomHandler extends Handler{
@Override
public void handleMessage(Message msg) {
//更新UI等操作
}
}
CustomHandler customHandler = new CustomHandler();
//2.內部類
Handler innerHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
//更新UI等操作
}
};
//3.callback方式
Handler callbackHandler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
//更新UI等操作
return true;
}
});
複製程式碼step2:傳送訊息
//1.傳送普通訊息
Message msg = Message.obtain();
msg.what = 0; //標識
msg.obj = "這是訊息體"; //訊息內容
innerHandler.sendMessage(msg);
//2.傳送Runnale訊息
innerHandler.post(new Runnable() {
@Override
public void run() {
//更新UI等操作，訊息接收後執行此方法
}
});
複製程式碼Handler 的建立以及訊息的傳送都有很多種方法，各種方式的異同會在下面講到。
3. 原始碼分析
帶著問題看原始碼 —— 魯某
ps：本文原始碼基於 API 28 ，即 Android P / Android 9
先丟擲我們的第一個問題：
3.1 為什麼 Handler 能夠切換執行緒執行？
我們在傳送 Message 的時候在子執行緒，為什麼執行的時候就切換成了主執行緒？想要知道答案，基本就要把 Handler 的執行流程給瞭解一遍。
因為最終的處理是在 handleMessage方法中進行的，所以我們看看 handleMessage方法是怎麼被呼叫起來的。
先打個 debug , 看看呼叫鏈：
畫個圖直觀一點：
可能有點奇怪，整個呼叫流程都沒有出現我們傳送訊息的方法，那我們傳送的 Message 物件在哪裡被使用了呢？
看下上圖的 Step 2 ，在 loop() 方法裡面呼叫了 msg.target.dispatchMessage(msg) 方法，debug 中檢視 msg 物件的屬性，發現這個 msg 正是我們傳送的那個 Message物件，這個 target 就是在 MainActivity 中建立的 Handler 物件。
也就是說，我們傳送訊息後，不知道什麼原因，Looper.loop() 方法內會拿到我們傳送的訊息，並且最終會呼叫傳送該訊息的 Handler 的 handleMessage(Message msg)方法。先看看 loop() 方法是怎麼拿到我們的 Message 的：
// Looper.java ，省略部分程式碼
loop(){
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block , 從佇列取出一個msg
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
msg.target.dispatchMessage(msg); //Handler處理訊息
msg.recycleUnchecked(); //回收msg
}
}
複製程式碼首先，loop()方法會判斷當前執行緒是否已經呼叫了 Looper.prepare()，如果沒有，則拋異常，這就是我們建立非主執行緒的 Handler 為什麼要呼叫Looper.prepare()的原因。而主執行緒中會在上面流程圖的 Step 1 中，即 main() 方法裡面呼叫了 prepare 方法，所以我們建立預設（主執行緒）的 Handler 不需要額外建立 Looper 。
loop() 裡面是一個死迴圈，只有當msg為空時才退出該方法。msg 是從 queue.next 中取出來的，這個 queue 就是我們經常聽到的訊息佇列了（MessageQueue ），看看 next 方法的實現：
//MessageQueue.java ,刪減部分程式碼
Message next() {
final long ptr = mPtr;
if (ptr == 0) {
//如果佇列已經停止了（quit or dispose）
return null;
}
for (;;) {
synchronized (this) {
final long now = SystemClock.uptimeMillis(); //獲取當前時間
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
//msg == target 的情況只能是屏障訊息，即呼叫postSyncBarrier()方法
//如果存在屏障，停止同步訊息，非同步訊息還可以執行
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous()); //找出非同步訊息，如果有的話
}
if (msg != null) {
if (now < msg.when) {
//當前訊息還沒準備好(時間沒到)
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// 訊息已準備，可以取出
if (prevMsg != null) {
//有屏障，prevMsg 為非同步訊息 msg 的前一節點，相當於拿出 msg ,連結前後節點
prevMsg.next = msg.next;
} else {
//沒有屏障,msg 即頭節點，將 mMessages 設為新的頭結點
mMessages = msg.next;
}
msg.next = null; //斷開即將執行的 msg
msg.markInUse(); //標記為使用狀態
return msg; //返回取出的訊息，交給Looper處理
}
}
// Process the quit message now that all pending messages have been ha
if (mQuitting) {
//佇列已經退出
dispose();
return null; //返回null後Looper.loop()方法也會結束迴圈
}
}
}
複製程式碼原始碼中可以發現，雖然 MessageQueue 叫訊息佇列，但卻是使用了連結串列的資料結構來儲存訊息。 next()方法會從連結串列的頭結點開始，先看看頭結點是不是訊息屏障(ViewRootImpl使用了這個機制)，如果是，那麼就停止同步訊息的讀取，非同步訊息照常運作。
如果有訊息，還會判斷是否到了訊息的使用時間，比如我們傳送了延時訊息，這個訊息不會馬上呼叫，而是繼續迴圈等待，直到訊息可用。這裡就有一個新的問題2：**問什麼 next()中一直迴圈卻不會導致應用卡死？**這個問題等下再說。
到這裡，我們就大致能理清 Handler.handleMessage()方法是怎麼調起來的了。但是MessageQueue裡面的訊息是怎麼來的呢？這個其實不看原始碼也能猜出來了，肯定是由我們傳送的訊息那裡傳過來的，但是為了理解更深刻，還是得看看訊息是怎麼傳遞到訊息佇列中的（MessageQueue ）；
//Handler.java
public final boolean sendMessage(Message msg){
return sendMessageDelayed(msg, 0);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis){
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(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);
}
複製程式碼可以看到，sendMessage()方法最終是呼叫了 sendMessageAtTime()方法，分析下這個方法，首先將會拿到一個訊息佇列 mQueue，這個佇列是在建立 Looper的時候預設初始化的，然後會呼叫enqueueMessage()方法進隊:
//Handler.java
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
複製程式碼這個進隊方法裡面會將msg.target設為當前Handler,也就是上面說到的 Looper.loop()方法內最終呼叫的msg.target.dispatchMessage(msg)的這個 msg 的 target 來源。
如果當前 Handler 是非同步的話，還會將傳送的訊息置為同步訊息，這個 mAsynchronous 標識是我們構造 Handler 的是否傳遞的引數，預設為 false。
最後就是真正的進隊方法 MessageQueue.enqueueMessage :
//MessageQueue.java 刪減部分程式碼
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {
msg.recycle();
return false;
}
msg.markInUse();
msg.when = when; //賦值呼叫時間
Message p = mMessages; //頭結點
if (p == null || when == 0 || when < p.when) {
//佇列中沒有訊息 或者 時間為0 或者 比頭結點的時間早
//插入到頭結點中
msg.next = p;
mMessages = msg;
} else {
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) { //類似插入排序，找到合適的位置
break;
}
}
// 結點插入
msg.next = p;
prev.next = msg;
}
}
return true;
}
複製程式碼剛開始會進行一系列的判斷，然後根據時間來作為一個排隊依據進行進隊操作，需要注意的是：訊息佇列是使用連結串列作為資料的儲存結構，是可以插隊的，即不存在傳送了延時訊息不會阻塞訊息佇列。
再跟上面的出隊方法聯絡起來，就會發現，非同步訊息並不會立刻執行，而是根據時間，完全跟同步訊息一樣的順序插入佇列中。非同步訊息與同步訊息唯一的區別就是當有訊息屏障時，非同步訊息還可以執行，而同步訊息則不行。
整個Handler的大體執行機制到此應該有了一個比較清晰的輪廓了。
總結一下：Handler 傳送的執行緒不處理訊息，只有Looper.loop()將訊息取出來後再進行處理，所以在Handler機制中，無論傳送訊息的Handler物件處於什麼執行緒，最終的處理都是執行在 Looper.loop() 所在的執行緒。
比如：一個新的執行緒 Thread1 傳送了一個訊息 Msg1，這個執行緒的工作僅僅是將訊息儲存到訊息佇列而已，並沒有下一步了，然後等待 Looper.loop() 處理到 Msg1 的時候（loop()方法一直執行在最開始呼叫它的執行緒，比如主執行緒），再將 Msg1 進行處理，所以最終就從 Thread1 切換到了主執行緒中執行。
可以拉到下面3.7小節看下流程圖，更清晰一些
3.2 Handler.post(Runnable) 方法是執行在新的執行緒嗎？
Handler 中傳送訊息的方法多達十幾個，分為 sendXXX 以及 postXXX ,這裡看看主要的幾個 post 型別方法：
//Handler.java
public final boolean post(Runnable r){
return sendMessageDelayed(getPostMessage(r), 0);
}
public final boolean postAtTime(Runnable r, long uptimeMillis){
return sendMessageAtTime(getPostMessage(r), uptimeMillis);
}
...
複製程式碼幾個 post 方法都是呼叫了相應的sendXXX 方法，然後用getPostMessage(Runnable r) 構建 Message 物件：
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
複製程式碼這裡獲取到訊息後，將 Runnable賦值給 Message.callback ,那這個 callback 有什麼用呢？上面的整體流程分析中，我們知道 Looper.loop()會呼叫 msg.target.dispatchMessage(msg)，這個target 就是 Handler 了，那麼看一下這個方法的具體實現：
// Handler.java
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
複製程式碼到這一步終於水落石出了，如果是用 postXXX 方法傳送的訊息，就會呼叫 handleCallback(msg) 方法，即呼叫我們post方法裡傳遞的 Runnable 物件的run()方法。
也就是說，Runnable 跟執行緒沒有半毛錢關係，他只是一個回撥方法而已，只不過我們平時建立執行緒的時候使用多了，誤以為他跟執行緒有什麼py交易。
3.3 Handler(Callback) 跟 Handler() 這兩個構造方法的區別在哪？
接著看3.2講到的 dispatchMessage() 方法剩下的邏輯。
如果 msg 沒有 callback 的話，那麼將會判斷 mCallback 是否為空，這個 mCallback 就是構造方法種傳遞的那個 Callback ,如果 mCallback為空,那麼就呼叫 Handler 的 handleMessage(msg) 方法，否則就呼叫 mCallback.handleMessage(msg) 方法，然後根據 mCallback.handleMessage(msg)的返回值判斷是否攔截訊息，如果攔截(返回 true)，則結束，否則還會呼叫 Handler#handleMessage(msg)方法。
也就是說：Callback.handleMessage() 的優先順序比 Handler.handleMessage()要高 。如果存在Callback,並且Callback#handleMessage() 返回了 true ,那麼Handler#handleMessage()將不會呼叫。
除了這點，還有什麼區別嗎？暫時真沒發現。
3.4 子執行緒可以建立 Handler 嗎？
問題可能有些模糊，意思是可以在子執行緒回撥 handleMessage()嗎。
上面理清了 Handler 的執行流程，但是建立流程好像還沒怎麼說，先看看 Handler 是怎麼建立的：
public Handler() {
this(null, false);
}
public Handler(Callback callback) {
this(callback, false);
}
public Handler(boolean async) {
this(null, async);
}
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
}
}
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;
mCallback = callback;
mAsynchronous = async;
}
複製程式碼先看上面這部分不傳 Looper 的構造方法，這些方法最終都是呼叫了Handler(Callback callback, boolean async) 方法，所以直接看這個方法就行，一開始會在方法體內檢測是否有潛在的記憶體洩漏風險，相信大家都有過被這東西煩過，看圖：
這種被黃色支配的感覺不太舒服，可以在例項上面新增註解@SuppressLint("HandlerLeak")來去掉提示，但是這只是去掉提示而已，別忘了處理潛在的記憶體洩漏。
接著看下面，首先會呼叫 Looper.myLooper()方法拿到當前執行緒的 Looper 例項，如果為空，則拋異常，看看myLooper()具體是怎樣的：
//Looper.java
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
複製程式碼直接就是呼叫了 sThreadLocal的 get 方法，這個sThreadLocal是一個靜態的 ThreadLocal 常量，看名字就能猜到與執行緒相關，具體的就不深究了。可以先把他看成一個執行緒id 與 Looper 的 map 鍵值對。既然有 get() ，那麼就應該有 set() ,那麼 Looper 是在哪裡被存進去的呢？
//Looper.java
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}
複製程式碼原來是在 Looper.prepare() 方法中被傳進去的，並且 sThreadLocal 中每個執行緒都只能有一個 Looper 例項。需要注意的是，prepare()方法並沒有呼叫 Looper#loop()方法，經過上面的流程分析也知道，這個 loop() 方法啟動才能處理髮送的訊息，所以子執行緒建立 Handler 除了需要呼叫 Looper.prepare()外，還需要呼叫 Looper.loop()啟動。
也就說明，任何執行緒都可以建立 Handler,只要當前執行緒呼叫了 Looper.prepare()方法，那麼就可以使用 Handler 了，而且同一執行緒內就算建立 n 個 Handler 例項，也只對應一個 Looper,即對應一個訊息佇列。
理一理邏輯：Handler 機制要求建立 Handler 的執行緒必須先呼叫 Looper.prepare() 方法來初始化，初始化過程中會將當前執行緒的 Looper 存起來，如果沒有進行 Looper 的初始化，將會拋異常，要啟動 Looper ，還需要呼叫 loop() 方法。
3.5 為什麼主執行緒不用呼叫 Looper.prepare() ？
上面說了，每個執行緒要建立 Handler 就必須要呼叫 Looper.prepare進行初始化，那麼為什麼我們平時在主執行緒建立 Handler 則不需要呼叫？
通過3.1 中的 debug 呼叫鏈就可以知道，主執行緒的 loop()方法是在 ActivityThread#main()方法中被呼叫的，那麼看看 main() 方法：
//ActivityThread.java 刪減部分程式碼
public static void main(String[] args) {
Looper.prepareMainLooper();
Looper.loop();
}
複製程式碼到這裡就能明白了，在App啟動的時候系統預設啟動了一個主執行緒的 Looper,prepareMainLooper()也是呼叫了 prepare()方法，裡面會建立一個不可退出的 Looper,並 set 到 sThreadLocal物件當中。
3.6 為什麼建立 Message 物件推薦使用 Message.obtain()獲取？
Message 物件有兩種方式可以獲得，一種是直接 new 一個例項，另一種就是呼叫 Message.obtain()方法了，Handler.obtainMessage() 也是呼叫Message.obtain()實現的，看看這個方法：
//Message.java
private static Message sPool;
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
}
}
return new Message();
}
複製程式碼可以看到，obtain() 方法會在以 sPool作為頭結點的訊息池（連結串列）中遍歷，如果找到，那麼取出來，並置為非使用狀態，然後返回，如果訊息池為空，則新建一個訊息。
知道有訊息池這個東西了，那麼這個訊息池的訊息是怎麼來的呢？
使用 AS 搜尋一下，發現只有兩個方法對 sPool 這個節點進行了賦值，一個是上面的 obtain()，另一個是下面這個：
//Message.java
private static final int MAX_POOL_SIZE = 50;
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
複製程式碼看方法名也可以知道，這是一個回收的方法，方法體內將 Message 物件的各種引數清空，如果訊息池的數量小於最大數量(50)的話，就當前訊息插入快取池的頭結點中。
已經知道 Message 是會被回收的了，那麼什麼情況才會被回收呢？
繼續檢視呼叫鏈：
// Looper.java ，省略部分程式碼
loop(){
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block , 從佇列取出一個msg
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
msg.target.dispatchMessage(msg); //Handler處理訊息
...
msg.recycleUnchecked(); //回收msg
}
}
複製程式碼其中的一個呼叫是在 Looper.loop()方法中，呼叫時機是在 Handler 處理事件之後，既然是 Handler 處理後就會回收，那麼如果在 Handler.handleMessage() 中用新的執行緒使用這個 msg 會怎樣呢？
//MainActivity.java
@SuppressLint("HandlerLeak")
static Handler innerHandler = new Handler() {
@Override
public void handleMessage(final Message msg) {
new Thread(new Runnable() {
@Override
public void run() {
boolean isRecycle = msg.obj == null;
Log.e("====是否已經回收===", "" + isRecycle);
}
}).start();
}
};
private void send(){
Message msg = Message.obtain();
msg.what = 0; //標識
msg.obj = "這是訊息體"; //訊息內容
innerHandler.sendMessage(msg);
}
複製程式碼當呼叫 send()方法傳送訊息後，發現打出 log:
E/====是否已經回收===: true
複製程式碼也就說明我們的推斷是正確的。所以在平時使用中，不要在 handleMessage(Message msg)方法中對 msg 進行非同步處理，因為非同步處理後，該方法會馬上返回，相當於告訴 Looper 已經處理完成了，Looper 就會將其回收。
如果真要在非同步中使用，那麼可以建立一個新的 Message 物件，並將值賦值過去。
回到前面的問題，我們目前發現了一個 Message 被回收的地方，那麼其他地方有呼叫這個 Message .recycleUnchecked() 嗎？接著看看：
//Message.java
public void recycle() {
if (isInUse()) {
if (gCheckRecycle) {
throw new IllegalStateException("This message cannot be recycled because it "
+ "is still in use.");
}
return;
}
recycleUnchecked();
}
複製程式碼Message 還有一個公共的回收方法，就是上面這個了，我們可以手動呼叫這個進行回收。還有就是訊息佇列中各種 removeMessage 也會觸發回收，呼叫鏈太多了，就不貼程式碼了。
總而言之，因為 Handler 機制在整個 Android 系統中使用太頻繁，所以 Android 就採用了一個快取策略。就是 Message 裡面會快取一個靜態的訊息池，當訊息被處理或者移除的時候就會被回收到訊息池，所以推薦使用 Message.obtain()來獲取訊息物件。
3.7 梳理
到此就把Handler的大致流程分析完了，再畫個圖重新梳理一下思路：
把整個Handler機制比作一個流水線的話，那麼 Handler 就是工人，可以在不同執行緒傳遞 Message到傳送帶(MessageQueue)，而傳送帶是被馬達（Looper）運輸的，馬達又是一開始就執行了(Looper.loop())，並且只會在一開始的執行緒，所以無論哪個工人(Handler)在哪裡(任意執行緒)傳遞產品(Message)，都只會在一條傳送帶(MessageQueue)上被唯一的馬達(Looper)運送到終點處理，即 Message 只會在呼叫 Looper.loop() 的執行緒被處理。
4 常見問題&技巧
4.1 為什麼 Handler 會造成記憶體洩漏？
先來回顧下基礎知識，可能造成記憶體洩漏的原因可以大致概括如下：
生命週期長的物件引用了生命週期短的物件。
Handler 跟其他一些類一樣，本身是不會造成記憶體洩漏的，Handler 造成記憶體洩漏的一般原因都是由於匿名內部類引起的，因為匿名內部類隱性地持有外部類的引用(如果不持有引用怎麼可以使用外部類的變數方法呢？)。
所以當內部類的生命週期比較長，如跑一個新的執行緒，碰巧又碰到生命週期短的物件(如Activity)需要回收，就會導致生命週期短的物件還在被生命週期長的物件所引用，進而回收不了。
典型的例子：
public class Main {
int _10m = 10*1024*1024;
byte[] bytes = new byte[4*_10m];
public void run() {
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(100*1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
}
public static void main(String args[]) {
Main object = new Main();
object.run();
object =null;
System.gc();
}
}
複製程式碼輸出log:
[GC (System.gc()) [PSYoungGen: 3341K->880K(38400K)] 44301K->41848K(125952K) [Full GC (System.gc()) [PSYoungGen: 880K->0K(38400K)] [ParOldGen: 40968K->41697K(87552K)] 41848K->41697K(125952K)
可以看到，即使object引用為空，object 物件還是沒有被回收。這就會發生了記憶體洩漏，如果出現很多次這樣的情況，那麼就很有可能發生記憶體溢位(OutOfMemery)。
在 Handler 裡面其實是類似的道理，匿名內部類的 Handler 持有 Activity 的引用，而傳送的 Message 又持有 Handler 的引用，Message 又存在於 MessageQueue 中，而 MessageQueue 又是 Looper 的成員變數，並且 Looper 物件又是存在於靜態常量 sThreadLocal 中。
所以反推回來，因為 sThreadLocal 是方法區常量，所以不會被回收，而 sThreadLocal 又持有 Looper 的引用...balabala...還是看圖吧：
即 sThreadLocal 間接的持有了 Activity 的引用，當 Handler 傳送的訊息還沒有被處理完畢時，比如延時訊息，而 Activity 又被使用者返回了，即 onDestroy() 後，系統想要對 Activity 物件進行回收，但是發現還有引用鏈存在，回收不了，就造成了記憶體洩漏。
4.2 怎麼防止 Handler 記憶體洩漏？
從上面的分析中，可以知道，想要防止 Handler 記憶體洩漏，一種方法是把 sThreadLocal 到 Activity 的引用鏈斷開就行了。
**最簡單的方法就是在 onPause()中使用 Handler 的 removeCallbacksAndMessages(null)方法清除所有訊息及回撥。**就可以把引用鏈斷開了。
Android 原始碼中這種方式也很常見，不在 onDestroy()裡面呼叫主要是 onDestroy() 方法不能保證每次都能執行到。
第二種方法就是使用靜態類加弱引用的方式：
public class MainActivity extends AppCompatActivity {
public TextView textView;
static class WeakRefHandler extends Handler {
//弱引用
private WeakReference<MainActivity> reference;
public WeakRefHandler(MainActivity mainActivity) {
this.reference = new WeakReference<MainActivity>(mainActivity);
}
@Override
public void handleMessage(Message msg) {
MainActivity activity = reference.get();
if (activity != null) {
activity.textView.setText("雞湯程式設計師");
}
}
}
}
複製程式碼因為靜態類不會持有外部類的引用，所以需要傳一個 Activity 過來,並且使用一個弱引用來引用 Activity 的例項，弱引用在 gc 的時候會被回收，所以也就相當於把強引用鏈給斷了，自然也就沒有記憶體洩漏了。
4.3 Loop.loop() 為什麼不會造成應用卡死？
上面也提了這個問題，按照一般的想法來說，loop() 方法是一個死迴圈，那麼肯定會佔用大量的 cpu 而導致應用卡頓，甚至說 ANR 。
但是 Android 中即使使用大量的 Looper ，也不會造成這種問題，問什麼呢？
由於這個問題涉及到的知識比較深，主要是通過 Linux 的 epoll 機制實現的，這裡需要 Linux 、 jni 等知識，我等菜鳥就不分析了，推薦一些相關文章：
Android中為什麼主執行緒不會因為Looper.loop()裡的死迴圈卡死？
5. 總結
以上就是篇文章的全部分析了，這裡總結一下：
1. Handler 的回撥方法是在 Looper.loop()所呼叫的執行緒進行的；
2. Handler 的建立需要先呼叫 Looper.prepare() ，然後再手動呼叫 loop()方法開啟迴圈；
3. App 啟動時會在ActivityThread.main()方法中建立主執行緒的 Looper ,並開啟迴圈，所以主執行緒使用 Handler 不用呼叫第2點的邏輯；
4. 延時訊息並不會阻塞訊息佇列；
5. 非同步訊息不會馬上執行，插入佇列的方式跟同步訊息一樣，唯一的區別是當有訊息屏障時，非同步訊息可以繼續執行，同步訊息則不行；
6. Callback.handleMessage() 的優先順序比 Handler.handleMessage()要高
7. Handler.post(Runnable)傳遞的 Runnale 物件並不會在新的執行緒執行；
8. Message 的建立推薦使用 Message.obtain() 來獲取，內部採用快取訊息池實現；
9. 不要在 handleMessage()中對訊息進行非同步處理；
10. 可以通過removeCallbacksAndMessages(null)或者靜態類加弱引用的方式防止記憶體洩漏；
11. Looper.loop()不會造成應用卡死，裡面使用了 Linux 的 epoll 機制。
寫文章真是費時費力，特別是想寫點詳細點的文章，實習了多半年，越學越發現需要學的東西越多，越多東西就說明不記下來就很容易忘記，而且經過系統的整理與記錄，會加深自己的理解。
本菜鳥的水平有限，如果發現有錯誤或不足懇請指正。
如果文章對你有幫助，歡迎點贊收藏。
感謝閱讀。
作者：
簡書：雞湯程式設計師
掘金：gminibird
微信公眾號：雞湯程式設計師
- 我們正在招募小夥伴，有興趣的小夥伴可以把簡歷發到 app@talkmoney.cn，備註：來自掘金社群
- 詳情可以戳這裡--> 廣州蘆葦資訊科技