深入原始碼解析Android中的Handler,Message,MessageQueue,Looper

本文主要是對Handler和訊息迴圈的實現原理進行原始碼分析，如果不熟悉Handler可以參見博文《 Android中Handler的使用》，裡面對Android為何以引入Handler機制以及如何使用Handler做了講解。

概括來說，Handler是Android中引入的一種讓開發者參與處理執行緒中訊息迴圈的機制。我們在使用Handler的時候與Message打交道最多，Message是Hanlder機制向開發人員暴露出來的相關類，可以通過Message類完成大部分操作Handler的功能。但作為程式設計師，我不能只知道怎麼用Handler，還要知道其內部如何實現的。Handler的內部實現主要涉及到如下幾個類: Thread、MessageQueue和Looper。這幾類之間的關係可以用如下的圖來簡單說明：

Thread是最基礎的，Looper和MessageQueue都構建在Thread之上，Handler又構建在Looper和MessageQueue之上，我們通過Handler間接地與下面這幾個相對底層一點的類打交道。

---

MessageQueue

MessageQueue原始碼連結

最基礎最底層的是Thread，每個執行緒內部都維護了一個訊息佇列——MessageQueue。訊息佇列MessageQueue，顧名思義，就是存放訊息的佇列（好像是廢話…）。那佇列中儲存的訊息是什麼呢？假設我們在UI介面上單擊了某個按鈕，而此時程式又恰好收到了某個廣播事件，那我們如何處理這兩件事呢？ 因為一個執行緒在某一時刻只能處理一件事情，不能同時處理多件事情，所以我們不能同時處理按鈕的單擊事件和廣播事件，我們只能挨個對其進行處理，只要挨個處理就要有處理的先後順序。 為此Android把UI介面上單擊按鈕的事件封裝成了一個Message，將其放入到MessageQueue裡面去，即將單擊按鈕事件的Message入棧到訊息佇列中，然後再將廣播事件的封裝成以Message，也將其入棧到訊息佇列中。也就是說一個Message物件表示的是執行緒需要處理的一件事情，訊息佇列就是一堆需要處理的Message的池。執行緒Thread會依次取出訊息佇列中的訊息，依次對其進行處理。MessageQueue中有兩個比較重要的方法，一個是enqueueMessage方法，一個是next方法。enqueueMessage方法用於將一個Message放入到訊息佇列MessageQueue中，next方法是從訊息佇列MessageQueue中阻塞式地取出一個Message。在Android中，訊息佇列負責管理著頂級程式物件（Activity、BroadcastReceiver等）以及由其建立的所有視窗。需要注意的是，訊息佇列不是Android平臺特有的，其他的平臺框架也會用到訊息佇列，比如微軟的MFC框架等。

---

Looper

Looper原始碼連結

訊息佇列MessageQueue只是儲存Message的地方，真正讓訊息佇列迴圈起來的是Looper，這就好比訊息佇列MessageQueue是個水車，那麼Looper就是讓水車轉動起來的河水，如果沒有河水，那麼水車就是個靜止的擺設，沒有任何用處，Looper讓MessageQueue動了起來，有了活力。

Looper是用來使執行緒中的訊息迴圈起來的。預設情況下當我們建立一個新的執行緒的時候，這個執行緒裡面是沒有訊息佇列MessageQueue的。為了能夠讓執行緒能夠繫結一個訊息佇列，我們需要藉助於Looper：首先我們要呼叫Looper的prepare方法，然後呼叫Looper的Loop方法。典型的程式碼如下所示：

class LooperThread extends Thread {
      public Handler mHandler;

      public void run() {
          Looper.prepare();

          mHandler = new Handler() {
              public void handleMessage(Message msg) {
                  // process incoming messages here
              }
          };

          Looper.loop();
      }
  }

需要注意的是Looper.prepare()和Looper.loop()都是在新執行緒的run方法內呼叫的，這兩個方法都是靜態方法。我們通過檢視Looper的原始碼可以發現，Looper的建構函式是private的，也就是在該類的外部不能用new Looper()的形式得到一個Looper物件。根據我們上面的描述，我們知道執行緒Thread和Looper是一對一繫結的，也就是一個執行緒中最多隻有一個Looper物件，這也就能解釋Looper的建構函式為什麼是private的了，我們只能通過工廠方法Looper.myLooper()這個靜態方法獲取當前執行緒所繫結的Looper。

Looper通過如下程式碼儲存了對當前執行緒的引用：

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

所以在Looper物件中通過sThreadLocal就可以找到其繫結的執行緒。ThreadLocal中有個set方法和get方法，可以通過set方法向ThreadLocal中存入一個物件，然後可以通過get方法取出存入的物件。ThreadLocal在new的時候使用了泛型，從上面的程式碼中我們可以看到此處的泛型型別是Looper，也就是我們通過ThreadLocal的set和get方法只能寫入和讀取Looper物件型別，如果我們呼叫其ThreadLocal的set方法傳入一個Looper，將該Looper繫結給了該執行緒，相應的get就能獲得該執行緒所繫結的Looper物件。

我們再來看一下Looper.prepare()，該方法是讓Looper做好準備，只有Looper準備好了之後才能呼叫Looper.loop()方法，Looper.prepare()的程式碼如下:

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));
}

上面的程式碼首先通過sThreadLocal.get()拿到執行緒sThreadLocal所繫結的Looper物件，由於初始情況下sThreadLocal並沒有繫結Looper，所以第一次呼叫prepare方法時，sThreadLocal.get()返回null，不會丟擲異常。重點是下面的程式碼sThreadLocal.set(new Looper(quitAllowed))，首先通過私有的建構函式建立了一個Looper物件的例項，然後通過sThreadLocal的set方法將該Looper繫結到sThreadLocal中。
這樣就完成了執行緒sThreadLocal與Looper的雙向繫結：
a. 在Looper內通過sThreadLocal可以獲取Looper所繫結的執行緒；
b.執行緒sThreadLocal通過sThreadLocal.get()方法可以獲取該執行緒所繫結的Looper物件。

上面的程式碼執行了Looper的建構函式，我們看一下其程式碼：

private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
}

我們可以看到在其建構函式中例項化一個訊息佇列MessageQueue，並將其賦值給其成員欄位mQueue,這樣Looper也就與MessageQueue通過成員欄位mQueue進行了關聯。

在執行完了Looper.prepare()之後，我們就可以在外部通過呼叫Looper.myLooper()獲取當前執行緒繫結的Looper物件。
myLooper的程式碼如下所示：

public static Looper myLooper() {
        return sThreadLocal.get();
}

需要注意的是，在一個執行緒中，只能呼叫一次Looper.prepare()，因為在第一次呼叫了Looper.prepare()之後，當前執行緒就已經繫結了Looper，在該執行緒內第二次呼叫Looper.prepare()方法的時候，sThreadLocal.get()會返回第一次呼叫prepare的時候繫結的Looper，不是null，這樣就會走的下面的程式碼throw new RuntimeException(“Only one Looper may be created per thread”)，從而丟擲異常，告訴開發者一個執行緒只能繫結一個Looper物件。

在呼叫了Looper.prepare()方法之後，當前執行緒和Looper就進行了雙向的繫結，這時候我們就可以呼叫Looper.loop()方法讓訊息佇列迴圈起來了。
需要注意的是Looper.loop()應該在該Looper所繫結的執行緒中執行。

Looper.loop()的程式碼如下:

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();
        }
}

上面有幾行程式碼是關鍵程式碼:
1. final MessageQueue queue = me.mQueue;
變數me是通過靜態方法myLooper()獲得的當前執行緒所繫結的Looper，me.mQueue是當前執行緒所關聯的訊息佇列。
2. for (;;)
我們發現for迴圈沒有設定迴圈終止的條件，所以這個for迴圈是個死迴圈。
3. Message msg = queue.next(); // might block
我們通過訊息佇列MessageQueue的next方法從訊息佇列中取出一條訊息，如果此時訊息佇列中有Message，那麼next方法會立即返回該Message，如果此時訊息佇列中沒有Message，那麼next方法就會阻塞式地等待獲取Message。
4. msg.target.dispatchMessage(msg);
msg的target屬性是Handler，該程式碼的意思是讓Message所關聯的Handler通過dispatchMessage方法讓Handler處理該Message，關於Handler的dispatchMessage方法將會在下面詳細介紹。

---

Handler

Handler原始碼連結

Handler是暴露給開發者最頂層的一個類，其構建在Thread、Looper與MessageQueue之上。
Handler具有多個建構函式，簽名分別如下所示：
1. publicHandler()
2. publicHandler(Callbackcallback)
3. publicHandler(Looperlooper)
4. publicHandler(Looperlooper, Callbackcallback)
第1個和第2個建構函式都沒有傳遞Looper，這兩個建構函式都將通過呼叫Looper.myLooper()獲取當前執行緒繫結的Looper物件，然後將該Looper物件儲存到名為mLooper的成員欄位中。
第3個和第4個建構函式傳遞了Looper物件，這兩個建構函式會將該Looper儲存到名為mLooper的成員欄位中。
第2個和第4個建構函式還傳遞了Callback物件，Callback是Handler中的內部介面，需要實現其內部的handleMessage方法，Callback程式碼如下:

public interface Callback {
        public boolean handleMessage(Message msg);
}

Handler.Callback是用來處理Message的一種手段，如果沒有傳遞該引數，那麼就應該重寫Handler的handleMessage方法，也就是說為了使得Handler能夠處理Message，我們有兩種辦法：
1. 向Hanlder的建構函式傳入一個Handler.Callback物件，並實現Handler.Callback的handleMessage方法
2. 無需向Hanlder的建構函式傳入Handler.Callback物件，但是需要重寫Handler本身的handleMessage方法
也就是說無論哪種方式，我們都得通過某種方式實現handleMessage方法，這點與Java中對Thread的設計有異曲同工之處。
在Java中，如果我們想使用多執行緒，有兩種辦法：
1. 向Thread的建構函式傳入一個Runnable物件，並實現Runnable的run方法
2. 無需向Thread的建構函式傳入Runnable物件，但是要重寫Thread本身的run方法
所以只要用過多執行緒Thread，應該就對Hanlder這種需要實現handleMessage的兩種方式瞭然於心了。

我們知道通過sendMessageXXX系列方法可以向訊息佇列中新增訊息，我們通過原始碼可以看出這些方法的呼叫順序，
sendMessage呼叫了sendMessageDelayed，sendMessageDelayed又呼叫了sendMessageAtTime。
Handler中還有一系列的sendEmptyMessageXXX方法，而這些sendEmptyMessageXXX方法在其內部又分別呼叫了其對應的sendMessageXXX方法。

通過以下呼叫關係圖我們可以看的更清楚些:

由此可見所有的sendMessageXXX方法和sendEmptyMessageXXX最終都呼叫了sendMessageAtTime方法。

我們再來看看postXXX方法，會發現postXXX方法在其內部又呼叫了對應的sendMessageXXX方法，我們可以檢視下sendMessage的原始碼:

public final boolean post(Runnable r)
{
       return  sendMessageDelayed(getPostMessage(r), 0);
}

可以看到內部呼叫了getPostMessage方法，該方法傳入一個Runnable物件，得到一個Message物件，getPostMessage的原始碼如下:

private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
 }

通過上面的程式碼我們可以看到在getPostMessage方法中，我們建立了一個Message物件，並將傳入的Runnable物件賦值給Message的callback成員欄位，然後返回該Message，然後在post方法中該攜帶有Runnable資訊的Message傳入到sendMessageDelayed方法中。由此我們可以看到所有的postXXX方法內部都需要藉助sendMessageXXX方法來實現，所以postXXX與sendMessageXXX並不是對立關係，而是postXXX依賴sendMessageXXX，所以postXXX方法可以通過sendMessageXXX方法向訊息佇列中傳入訊息，只不過通過postXXX方法向訊息佇列中傳入的訊息都攜帶有Runnable物件（Message.callback）。

我們可以通過如下關係圖看清楚postXXX系列方法與sendMessageXXX方法之間的呼叫關係：

通過分別分析sendEmptyMessageXXX、postXXX方法與sendMessageXXX方法之間的關係，我們可以看到在Handler中所有可以直接或間接向訊息佇列傳送Message的方法最終都呼叫了sendMessageAtTime方法，該方法的原始碼如下：

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);
}

該方法內部呼叫了enqueueMessage方法，該方法的原始碼如下：

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
        //注意下面這行程式碼
        msg.target = this;
        if (mAsynchronous) {
            msg.setAsynchronous(true);
        }
        //注意下面這行程式碼
        return queue.enqueueMessage(msg, uptimeMillis);
}

在該方法中有兩件事需要注意：
1. msg.target = this
該程式碼將Message的target繫結為當前的Handler
2. queue.enqueueMessage
變數queue表示的是Handler所繫結的訊息佇列MessageQueue，通過呼叫queue.enqueueMessage(msg, uptimeMillis)我們將Message放入到訊息佇列中。

所以我們通過下圖可以看到完整的方法呼叫順序：

我們在分析Looper.loop()的原始碼時發現，Looper一直在不斷的從訊息佇列中通過MessageQueue的next方法獲取Message，然後通過程式碼msg.target.dispatchMessage(msg)讓該msg所繫結的Handler（Message.target）執行dispatchMessage方法以實現對Message的處理。
Handler的dispatchMessage的原始碼如下：

public void dispatchMessage(Message msg) {
        //注意下面這行程式碼
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
             //注意下面這行程式碼
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
             //注意下面這行程式碼
            handleMessage(msg);
        }
}

我們來分析下這段程式碼：

1.首先會判斷msg.callback存不存在，msg.callback是Runnable型別，如果msg.callback存在，那麼說明該Message是通過執行Handler的postXXX系列方法將Message放入到訊息佇列中的，這種情況下會執行handleCallback(msg), handleCallback原始碼如下：

private static void handleCallback(Message message) {
        message.callback.run();
}

這樣我們我們就清楚地看到我們執行了msg.callback的run方法，也就是執行了postXXX所傳遞的Runnable物件的run方法。

2.如果我們不是通過postXXX系列方法將Message放入到訊息佇列中的，那麼msg.callback就是null，程式碼繼續往下執行，接著我們會判斷Handler的成員欄位mCallback存不存在。mCallback是Hanlder.Callback型別的，我們在上面提到過，在Handler的建構函式中我們可以傳遞Hanlder.Callback型別的物件，該物件需要實現handleMessage方法，如果我們在建構函式中傳遞了該Callback物件，那麼我們就會讓Callback的handleMessage方法來處理Message。

3.如果我們在建構函式中沒有傳入Callback型別的物件，那麼mCallback就為null,那麼我們會呼叫Handler自身的hanldeMessage方法，該方法預設是個空方法，我們需要自己是重寫實現該方法。

綜上，我們可以看到Handler提供了三種途徑處理Message，而且處理有前後優先順序之分：首先嚐試讓postXXX中傳遞的Runnable執行，其次嘗試讓Handler建構函式中傳入的Callback的handleMessage方法處理，最後才是讓Handler自身的handleMessage方法處理Message。

---

一圖勝千言

我們在本文討論了Thread、MessageQueue、Looper以及Hanlder的之間的關係，我們可以通過如下一張傳送帶的圖來更形象的理解他們之間的關係。

在現實生活的生產生活中，存在著各種各樣的傳送帶，傳送帶上面灑滿了各種貨物，傳送帶在發動機滾輪的帶動下一直在向前滾動，不斷有新的貨物放置在傳送帶的一端，貨物在傳送帶的帶動下送到另一端進行收集處理。

我們可以把傳送帶上的貨物看做是一個個的Message，而承載這些貨物的傳送帶就是裝載Message的訊息佇列MessageQueue。傳送帶是靠傳送機滾輪帶動起來轉動的，我們可以把傳送機滾輪看做是Looper，而發動機的轉動是需要電源的，我們可以把電源看做是執行緒Thread，所有的訊息迴圈的一切操作都是基於某個執行緒的。一切準備就緒，我們只需要按下電源開關發動機就會轉動起來，這個開關就是Looper的loop方法，當我們按下開關的時候，我們就相當於執行了Looper的loop方法，此時Looper就會驅動著訊息佇列迴圈起來。

那Hanlder在傳送帶模型中相當於什麼呢？我們可以將Handler看做是放入貨物以及取走貨物的管道：貨物從一端順著管道劃入傳送帶，貨物又從另一端順著管道劃出傳送帶。我們在傳送帶的一端放入貨物的操作就相當於我們呼叫了Handler的sendMessageXXX、sendEmptyMessageXXX或postXXX方法，這就把Message物件放入到了訊息佇列MessageQueue中了。當貨物從傳送帶的另一端順著管道劃出時，我們就相當於呼叫了Hanlder的dispatchMessage方法，在該方法中我們完成對Message的處理。

囉囉嗦嗦說了很多，希望本文對於大家理解Android中的Handler和訊息迴圈機制有所幫助。