Android HandlerThread 消息循環機制之源代碼解析
關於 HandlerThread 這個類。可能有些人眼睛一瞟，手指放在鍵盤上，然後就是一陣狂敲。立即就能敲出一段段華麗的代碼：
HandlerThread handlerThread = new HandlerThread("handlerThread");
handlerThread.start();
Handler handler = new Handler(handlerThread.getLooper()){
public void handleMessage(Message msg) {
...
}
};
handler.sendMessage(***); 細致一看。沒問題啊（我也沒說代碼有問題啊），那請容許我說一句，“這代碼敲也敲完了，原理懂不？”
為什麽要扯這玩意。沒什麽理由，就是不小心看了這篇文章Android消息循環機制源代碼分析。學姐說了，源代碼都沒看，沒分析。還敢說你懂。原本還認為自己懂了點，看完這句話。頓時就不確定了。
於是，自覺打開了 AS …
前言
首先，先給各位看官打個預防針。待會要講的東西可能有點多，有點繞。涉及的類包括有：HandlerThread、Thread、Handler、Looper、Message、MessageQueue，可能有些人已經遭不住啦，有種想要關閉網頁的沖動。不要慌，剛開始我看源代碼的時候我也不知道最終會牽扯這麽一大串出來，但細致理一理後，事實上就是那麽回事。
一、擒賊先擒王 HandlerThread
這件事情的源頭都是因它而起的。不先找它先找誰。
首先，HandlerThread 是什麽gui。感覺像是 Handler 和 Thread 的結合體。點進源代碼一看：public class HandlerThread extends Thread {} 沒什麽好說的，原來是一個線程的子類。那麽接下來就要看看這個 HandlerThread 究竟有什麽特殊之處。
HandlerThread handlerThread = new HandlerThread("handlerThread");
handlerThread.start(); 跟正常線程的創建、啟動步驟一樣。線程已啟動，那勢必會運行其 run() 方法。為了方便以下流程的分析，這裏先用代碼塊1表示：
#HandlerThread.java
public void run() {
mTid = Process.myTid();
Looper.prepare();
synchronized (this) {
mLooper = Looper.myLooper();
notifyAll();
}
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
}當中。Looper 就代表我們常常說的消息循環，Looper.prepare() 就代表消息循環運行前的一些準備工作。
二、抓捕各種小弟(Looper、MessageQueue、Message)
既然上面已經談到Looper。那就來看一下它的幾個方法：Looper.prepare() 和 Looper.loop()。
代碼塊2
#Looper.java
public static void prepare() {
prepare(true);
}
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));
}
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
final MessageQueue mQueue;
final Thread mThread;上面一路下來還是挺清晰的。總結一下：由於一個 Thread 僅僅能相應有一個 Looper，所以僅僅有滿足條件下才會將 Looper 對象存放在類型為 ThreadLocal 的類屬性裏。當然在這之前還是要先 new 一個 Looper 對象，而在 Looper 的構造方法中又創建了兩個對象 。分別為mQueue（消息隊列）和 mThread（當前線程）。
整個 prepare 過程事實上主要是創建了三個對象：Looper、MessageQueue、Thread。
好了，Looper.prepare() 這個過程已經分析完了。
接著我們再看代碼塊1。裏面有一段同步代碼塊，目的是為了獲取 Looper 對象。方法跳轉過去一看。原來就是將之前存進 ThreadLocal 裏的Looper 對象取出 。
#Looper.java
public static Looper myLooper() {
return sThreadLocal.get();
}接下來最關鍵的就是 Looper.loop() 這句代碼，它也是 HandlerThread 這個類存在的價值所在。僅僅要一運行這句代碼，也就代表真正的消息循環開始啦：代碼塊3
#Looper.java
public static void 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;
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// Make sure that during the course of dispatching the
// identity of the thread wasn‘t corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}
msg.recycleUnchecked();
}
}這種方法的作用就是開始從消息隊列中循環取出消息。那這個消息隊列又從哪來的呢，還記得我們在Looper.prepare() 中創建 Looper 對象的時候在其構造方法中 new 兩個對象嘛。一個 MessageQueue，一個Thread。
在這裏要想使用消息隊列。首先須要先獲取 Looper 實例。畢竟消息隊列 MessageQueue 是作為其成員屬性而存在的。接著獲得了消息隊列的對象，並進入一個貌似死循環的控制流中。
這個 for 語句幹的事情就是不斷的從消息隊列 MessageQueue 裏取出消息，然後發送出去。
詳細誰來處理這些消息立即揭曉。
以下的代碼就是不斷地取出消息：
#Looper.java
Message msg = queue.next()接下去的內容可能就須要各位看官對數據結構有點了解了，我們一步一步嵌進去看一下。代碼塊4
#MessageQueue.java
Message next() {
...
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (false) Log.v("MessageQueue", "Returning message: " + msg);
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
...
}
}其他能夠先無論。我們直接跳轉到 synchronized 這同步代碼塊裏。我們看到Message msg = mMessage; 這個 mMessage 對象就是一個消息 Message，僅僅只是這個 Message 類裏面附帶了一種數據結構：鏈表。我們最好還是看一下這個類：
public final class Message implements Parcelable {
...
// sometimes we store linked lists of these things
/*package*/ Message next;
...
}不難看出。Message 類中包括了一個 Message 類型的屬性，作用就是指向下一條消息。依次類推，最終形成一個鏈表結構。僅僅只是這裏鏈表中的消息是要經過特殊處理的，並非每進來一條消息就直接追加到尾部。由於 Android 系統中的消息是有時間機制的。每條消息都會附加一個時間。這也是handler.sendMessageDelayed() 存在的意義。
接著看代碼塊4，先是對 msg 和 msg.target 進行推斷，僅僅要鏈表中中的消息不為空，同一時候消息的觸發時間小於當前系統的時間，那麽這個消息就會被取出來作為待發送的對象。這裏 msg.target 是非常重要的，我們之所以能 handleMessage 全靠它，以下會分析到。
然後回到代碼塊3，通過
Message msg = queue.next(); // might block
拿到消息後。再由 msg.target 將消息分發出去
msg.target.dispatchMessage(msg);
那這個 msg.target 究竟是個什麽東西。看屬性定義
/*package*/ Handler target;
竟然是一個 Handler，通過它將消息分發出去。我們再看一下是如何分發的：
#Handler.java
/**
* Handle system messages here.
*/
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}是不是有種茅塞頓開的感覺。
在這我就直接透漏一下，Message 中的 callback 事實上就是一個 Runnable 對象。handleCallback(msg); 就是運行其 run() 方法。
這也是為什麽我們能夠通過 handler.post(new Runnable(){...})來發送消息，事實上就是把Runnable對象賦給了Message的Callback 屬性。
而假設是正常的 handler.sendMessage()，那麽肯定就是運行以下的語句咯。我們能夠在創建 Handler 對象的時候指定一個回調接口 Callback。
當然不指定也沒事。我們最終還是能夠通過 handleMessage(msg) 來獲取待處理的消息。最後，我們還是要對這條消息進行回收重用的嘛msg.recycleUnchecked();
好了，關於Looper.prepare() 和 Looper.loop() 這兩個方法就介紹到這。
我們再來補充一下，消息隊列之所以有消息，那肯定得有誰提供瑟。答案就是 Handler。我們常常的操作就是handler.sendMessage(msg);。代碼塊5
#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);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}#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) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w("MessageQueue", e.getMessage(), e);
msg.recycle();
return false;
}
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don‘t have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}我認為我也沒什麽好說的，赤裸裸的將流程一步一步的貼出來。一句話，對傳入進來的 Message 進行封裝，什麽 msg.when、msg.target。通通在這裏搞定。
如今細致回憶 Looper.loop() 裏面對 msg 的處理。之前的各種?是不就煙消雲散啦。後面就頂多就是將消息加入到消息鏈表中。同一時候如我前面所說的那樣。要依據 msg.when 的時間插入到合適的位置中去。
總結
至此，整個消息循環機制就分析完啦。原始代碼：
HandlerThread handlerThread = new HandlerThread("handlerThread");
handlerThread.start();
Handler handler = new Handler(handlerThread.getLooper()){
public void handleMessage(Message msg) {
...
}
};
handler.sendMessage(***);再看一下詳細操作流程:
- handlerThread.start() -> Looper.prepare() -> Looper.loop() -> queue.next() -> msg.target.dispatchMessage(msg) -> handleMessage(msg)
- handler.sendMessage(msg) -> queue.enqueueMessage(msg)
由於上面的一切操作都是在一個新線程的 run() 方法中運行，所以不會堵塞 UI 線程。分析完成。
這時可能有些人就站出來了，這 HandlerThread 感覺也沒啥啊，我直接用 Thread 也能夠搞定一切。設想一下，加入如今有10個後臺任務須要運行，依照傳統的做法就是運行10遍 new Thread(某個Runnable對象).start() 首先你是創建了10個匿名對象。這資源消耗多少暫且不說。你還不能非常好的控制它們。這樣非常easy造成內存泄漏。若是將這些後臺任務打包成成一個個 Message 然後再發送出去。首先是線程能夠得到重用，再者我們還能夠 remove 掉消息隊列中的消息，再一定程度上避免了內存泄漏。
好了，該說的都說完了。可能須要各位看官自己腦補一下、消化一下。
Android HandlerThread 消息循環機制之源代碼解析