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 sThreadLocal = new ThreadLocal();
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個匿名對象，這資源消耗多少暫且不說，你還不能很好的控制它們，這樣很容易造成內存洩漏。若是將這些後台任務打包成成一個個 Message 然後再發送出去，首先是線程可以得到重用，再者我們還可以 remove 掉消息隊列中的消息，再一定程度上避免了內存洩漏。好了，該說的都說完了，可能需要各位看官自己腦補一下、消化一下。