Android事件機制詳細解讀

1概述

在Android平臺上，主要用到兩種通訊機制，即Binder機制和事件機制，前者用於跨程式通訊，後者用於程式內部通訊。

從技術實現上來說，事件機制還是比較簡單的。從大的方面講，不光是Android平臺，各種平臺的訊息機制的原理基本上都是相近的，其中用到的主要概念大概有：

1）訊息傳送者；
2）訊息佇列；
3）訊息處理迴圈。

示意圖如下：

圖中表達的基本意思是，訊息傳送者通過某種方式，將訊息傳送到某個訊息佇列裡，同時還有一個訊息處理迴圈，不斷從訊息佇列裡摘取訊息，並進一步解析處理。

在Android平臺上，把上圖的右邊部分包裝成了一個Looper類，這個類的內部具有對應的訊息佇列（MessageQueue  mQueue）和loop函式。

但是Looper只是個簡單的類而已，它雖然提供了迴圈處理方面的成員函式loop()，卻不能自己憑空地執行起來，而只能寄身於某個真實的執行緒。而且，每個執行緒最多隻能運作一個Looper物件，這一點應該很容易理解。

Android平臺上另一個關鍵類是Handler。當訊息迴圈在其寄身的執行緒里正式運作後，外界就是通過Handler向訊息迴圈發出事件的。我們再畫一張示意圖如下：

當然，系統也允許多個Handler向同一個訊息佇列傳送訊息：

整個訊息機制的輪廓也就是這些啦，下面我們來詳細闡述。

2先說一下Looper部分

Looper類的定義截選如下：
【frameworks/base/core/java/android/os/Looper.java】

public final class Looper {
    private static final String TAG = "Looper";

    // sThreadLocal.get() will return null unless you've called prepare().
    static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
    private static Looper sMainLooper;  // guarded by Looper.class

    final MessageQueue mQueue;
    final Thread mThread;

    private Printer mLogging;
    . . . . . .
    . . . . . .

當一個執行緒執行到某處，準備運作一個Looper時，它必須先呼叫Looper類的靜態函式prepare()，做一些準備工作。說穿了就是建立一個Looper物件，並把它設定進執行緒的本地儲存區（TLS）裡。然後執行緒才能繼續呼叫Looper類的另一個靜態函式loop()，從而建立起訊息處理迴圈。示意圖如下：

prepare()函式的程式碼如下：

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));  // 建立Looper物件，並設定進TLS
}

可以看到，sThreadLocal.set()一句所完成的工作，正是把新建立的Looper物件設定進執行緒本地儲存區裡。在Looper.prepare()之後，執行緒的主運作函式就可以呼叫Looper.loop()了。

為了便於大家理解，我們多說兩句關於sThreadLocal的細節，這會牽扯一點兒本地儲存的技術。簡單地說，每個執行緒物件內部會記錄一張邏輯上的key-value表，當然，這張表在具體實現時不一定會被實現成HashMap，以我們目前的程式碼來說，它被記錄成一個陣列，其中每兩個陣列項作為一個key-value單元。反正大家從邏輯上理解概念即可，不必拘泥於具體實現。很明顯，一個執行緒內部是可以記錄多個本地儲存單元的，我們關心的sThreadLocal只是其中一個本地儲存單元的key而已。

當我們在不同Thread裡呼叫Looper.prepare()時，其實是向Thread對應的那張表裡新增一個key-value項，其中的key部分，指向的是同一個物件，即Looper.sThreadLocal靜態物件，而value部分，則彼此不同，我們可以畫出如下示意圖：

看到了吧，不同Thread會對應不同Object[]陣列，該陣列以每2個元素為一個key-value對。請注意不同Thread雖然使用同一個靜態物件作為key值，最終卻會對應不同的Looper物件，這一點系統是不會弄錯的。

為了由淺入深地闡述問題，我們暫時先不看Looper.loop()內部的程式碼，這個後文還會再講。現在我們接著說說Handler。

3接著說一下Handler部分

一般而言，運作Looper的執行緒會負責構造自己的Handler物件，當然，其他執行緒也可以針對某個Looper構造Handler物件。

Handler物件在構造時，不但會把Looper物件記錄在它內部的mLooper成員變數中，還會把Looper物件的訊息佇列也一併記錄，程式碼截選如下：

public Handler(Callback callback, boolean async) 
{
    . . . . . .
    mLooper = Looper.myLooper();   // 記錄下Looper物件
    . . . . . .
    mQueue = mLooper.mQueue;        // 也記錄下Looper物件的訊息佇列
    mCallback = callback;
    mAsynchronous = async;
}

我們也可以直接傳入Looper物件，此時可以使用另一個建構函式：

public Handler(Looper looper, Callback callback, boolean async) 
{
    mLooper = looper;                // 記錄下Looper物件
    mQueue = looper.mQueue;         // 也記錄下Looper物件的訊息佇列
    mCallback = callback;
    mAsynchronous = async;
}

以後，每當執行緒需要向訊息佇列傳送訊息時，只需呼叫Handler物件的sendMessage()等成員函式就可以了。

簡單說來，只要一個執行緒可以獲取另一個目標執行緒的某個Handler物件，它就具有了向目標執行緒傳送訊息的能力。不過，也只是傳送訊息而已，訊息的真正處理卻是在目標執行緒的訊息迴圈裡完成的。

前文已經說過，在Looper準備停當後，我們的執行緒會呼叫Looper.loop()，從而進入真正的迴圈機制。loop()函式的程式碼流程非常簡單，只不過是在一個for迴圈裡不停從訊息佇列中摘取訊息，而後呼叫msg.target.dispatchMessage()對訊息進行派發處理而已。

這麼看來，msg.target域就顯得比較重要了，說穿了，這個域記錄的其實就是當初向訊息佇列傳送訊息的那個handler啦。當我們呼叫handler的send函式時，最終基本上都會走到sendMessageAtTime()，其程式碼如下：
【frameworks/base/core/java/android/os/Handler.java】

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) 
{
    // 注意這一句，訊息的target就是handler物件啦！日後msg.target.dispatchMessage()時會使用。
    msg.target = this; 

    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}

請大家注意msg.target = this;一句，記錄的就是handler物件。

當Looper的訊息迴圈最終呼叫到msg.target.dispatchMessage()時，會間接呼叫到handler的handleMessage()函式，從而對訊息進行實際處理。

在實際運用handler時，大體有兩種方式。一種方式是寫一個繼承於Handler的新類，並在新類裡實現自己的handleMessage()成員函式；另一種方式是在建立匿名Handler物件時，直接修改handleMessage()成員函式。

4訊息佇列MessageQueue

在剛剛介紹Handler的sendMessageAtTime()時，我們已經看到最終會呼叫queue.enqueueMessage()來向訊息佇列打入訊息。queue對應的類是MessageQueue，其定義截選如下：
【frameworks/base/core/java/android/os/MessageQueue.java】

public final class MessageQueue {
    // True if the message queue can be quit.
    private final boolean mQuitAllowed;

    @SuppressWarnings("unused")
    private int mPtr; // used by native code

    Message mMessages;  // 訊息佇列！
    private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>();
    private IdleHandler[] mPendingIdleHandlers;
    private boolean mQuitting;

    // Indicates whether next() is blocked waiting in pollOnce() with a non-zero timeout.
    private boolean mBlocked;

    // The next barrier token.
    // Barriers are indicated by messages with a null target whose arg1 field carries the token.
    private int mNextBarrierToken;

    private native static int nativeInit();
    private native static void nativeDestroy(int ptr);
    private native static void nativePollOnce(int ptr, int timeoutMillis);
    private native static void nativeWake(int ptr);
    private native static boolean nativeIsIdling(int ptr);
    . . . . . .

其中Message mMessages記錄的就是一條訊息連結串列。另外還有幾個native函式，這就說明MessageQueue會通過JNI技術呼叫到底層程式碼。mMessages域記錄著訊息佇列中所有Java層的實質訊息。請大家注意，記錄的只是Java層的訊息，不包括C++層的。MessageQueue的示意圖如下：

4.1打入訊息

4.1.1enqueueMessage()

很明顯，enqueueMessage()就是在向MessageQueue的訊息連結串列裡插入Message。其程式碼截選如下：
【frameworks/base/core/java/android/os/MessageQueue.java】

boolean enqueueMessage(Message msg, long when) {
    . . . . . .
        . . . . . .
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if (p == null || when == 0 || when < p.when) {
            // 此時，新訊息會插入到連結串列的表頭，這意味著佇列需要調整喚醒時間啦。
             msg.next = p;
            mMessages = msg;
            needWake = mBlocked;
        } else {
            // 此時，新訊息會插入到連結串列的內部，一般情況下，這不需要調整喚醒時間。
              // 但還必須考慮到當表頭為“同步分割欄”的情況
              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()) {
                    // 說明即便msg是非同步的，也不是連結串列中第一個非同步訊息，所以沒必要喚醒了
                    needWake = false;  
                }
            }
            msg.next = p;
            prev.next = msg;
        }

        if (needWake) {
            nativeWake(mPtr);
        }
    . . . . . .
}

打入訊息的動作並不複雜，無非是在訊息連結串列中找到合適的位置，插入Message節點而已。因為訊息連結串列是按時間進行排序的，所以主要是在比對Message攜帶的when資訊。訊息連結串列的首個節點對應著最先將被處理的訊息，如果Message被插到連結串列的頭部了，就意味著佇列的最近喚醒時間也應該被調整了，因此needWake會被設為true，以便程式碼下方可以走進nativeWake()。

4.1.2說說“同步分割欄”

上面的程式碼中還有一個“同步分割欄”的概念需要提一下。所謂“同步分割欄”，可以被理解為一個特殊Message，它的target域為null。它不能通過sendMessageAtTime()等函式打入到訊息佇列裡，而只能通過呼叫Looper的postSyncBarrier()來打入。

“同步分割欄”是起什麼作用的呢？它就像一個卡子，卡在訊息連結串列中的某個位置，當訊息迴圈不斷從訊息連結串列中摘取訊息並進行處理時，一旦遇到這種“同步分割欄”，那麼即使在分割欄之後還有若干已經到時的普通Message，也不會摘取這些訊息了。請注意，此時只是不會摘取“普通Message”了，如果佇列中還設定有“非同步Message”，那麼還是會摘取已到時的“非同步Message”的。

在Android的訊息機制裡，“普通Message”和“非同步Message”也就是這點兒區別啦，也就是說，如果訊息列表中根本沒有設定“同步分割欄”的話，那麼“普通Message”和“非同步Message”的處理就沒什麼大的不同了。

打入“同步分割欄”的postSyncBarrier()函式的程式碼如下：
【frameworks/base/core/java/android/os/Looper.java】

public int postSyncBarrier() {
    return mQueue.enqueueSyncBarrier(SystemClock.uptimeMillis());
}

【frameworks/base/core/java/android/os/MessageQueue.java】

int enqueueSyncBarrier(long when) {
    synchronized (this) {
        final int token = mNextBarrierToken++;
        final Message msg = Message.obtain();
        msg.when = when;
        msg.arg1 = token;

        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
        if (prev != null) { 
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}

要得到“非同步Message”，只需呼叫一下Message的setAsynchronous()即可：
【frameworks/base/core/java/android/os/Message.java】

public void setAsynchronous(boolean async) {
    if (async) {
        flags |= FLAG_ASYNCHRONOUS;
    } else {
        flags &= ~FLAG_ASYNCHRONOUS;
    }
}

一般，我們是通過“非同步Handler”向訊息佇列打入“非同步Message”的。非同步Handler的mAsynchronous域為true，因此它在呼叫enqueueMessage()時，可以走入：

if (mAsynchronous) {
        msg.setAsynchronous(true);
    }

現在我們畫一張關於“同步分割欄”的示意圖：

圖中的訊息佇列中有一個“同步分割欄”，因此它後面的“2”號Message即使到時了，也不會摘取下來。而“3”號Message因為是個非同步Message，所以當它到時後，是可以進行處理的。

“同步分割欄”這種卡子會一直卡在訊息佇列中，除非我們呼叫removeSyncBarrier()刪除這個卡子。
【frameworks/base/core/java/android/os/Looper.java】

public void removeSyncBarrier(int token) {
    mQueue.removeSyncBarrier(token);
}

【frameworks/base/core/java/android/os/MessageQueue.java】

void removeSyncBarrier(int token) {
    // Remove a sync barrier token from the queue.
    // If the queue is no longer stalled by a barrier then wake it.
    synchronized (this) {
        Message prev = null;
        Message p = mMessages;
        while (p != null && (p.target != null || p.arg1 != token)) {
            prev = p;
            p = p.next;
        }
        if (p == null) {
            throw new IllegalStateException("The specified message queue synchronization "
                    + " barrier token has not been posted or has already been removed.");
        }
        final boolean needWake;
        if (prev != null) {
            prev.next = p.next;
            needWake = false;
        } else {
            mMessages = p.next;
            needWake = mMessages == null || mMessages.target != null;
        }
        p.recycle();

        // If the loop is quitting then it is already awake.
        // We can assume mPtr != 0 when mQuitting is false.
        if (needWake && !mQuitting) {
            nativeWake(mPtr);
        }
    }
}

和插入訊息類似，如果刪除動作改變了連結串列的頭部，也意味著佇列的最近喚醒時間應該被調整了，因此needWake會被設為true，以便程式碼下方可以走進nativeWake()。

4.1.3nativeWake()

nativeWake()對應的C++層函式如下：
【frameworks/base/core/jni/android_os_MessageQueue.cpp】

static void android_os_MessageQueue_nativeWake(JNIEnv* env, jclass clazz, jint ptr) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    return nativeMessageQueue->wake();
}

void NativeMessageQueue::wake() {
    mLooper->wake();
}

【system/core/libutils/Looper.cpp】

void Looper::wake() {
    . . . . . .
    ssize_t nWrite;
    do {
        nWrite = write(mWakeWritePipeFd, "W", 1);
    } while (nWrite == -1 && errno == EINTR);

    if (nWrite != 1) {
        if (errno != EAGAIN) {
            ALOGW("Could not write wake signal, errno=%d", errno);
        }
    }
}

wake()動作主要是向一個管道的“寫入端”寫入了“W”。有關這個管道的細節，我們會在後文再細說，這裡先放下。

4.2訊息迴圈

接下來我們來看看訊息迴圈。我們從Looper的Loop()函式開始講起。下面是loop()函式的簡略程式碼，我們只保留了其中最關鍵的部分：
【frameworks/base/core/java/android/os/Looper.java】

public static void loop() 
{
    final Looper me = myLooper();
    . . . . . .
    final MessageQueue queue = me.mQueue;

    Binder.clearCallingIdentity();
    final long ident = Binder.clearCallingIdentity();

    for (;;) {
        Message msg = queue.next(); // might block
        . . . . . .
        msg.target.dispatchMessage(msg);  // 派發訊息
        . . . . . .
        final long newIdent = Binder.clearCallingIdentity();
        . . . . . .
        msg.recycle();
    }
}

無非是在一個for迴圈裡不斷摘取佇列裡的下一條訊息，而後dispatchMessage()訊息。呃，至少邏輯上就是這麼簡單，但如果我們希望再探索得更深一點的話，就得詳細研究MessageQueue以及其next()函式了。

對於Looper而言，它主要關心的是從訊息佇列裡摘取訊息，而後分派訊息。然而對訊息佇列而言，在摘取訊息時還要考慮更多技術細節。它關心的細節有：

1）如果訊息佇列裡目前沒有合適的訊息可以摘取，那麼不能讓它所屬的執行緒“傻轉”，而應該使之阻塞；
2）佇列裡的訊息應該按其“到時”的順序進行排列，最先到時的訊息會放在隊頭，也就是mMessages域所指向的訊息，其後的訊息依次排開；
3）阻塞的時間最好能精確一點兒，所以如果暫時沒有合適的訊息節點可摘時，要考慮連結串列首個訊息節點將在什麼時候到時，所以這個訊息節點距離當前時刻的時間差，就是我們要阻塞的時長。
4）有時候外界希望佇列能在即將進入阻塞狀態之前做一些動作，這些動作可以稱為idle動作，我們需要兼顧處理這些idle動作。一個典型的例子是外界希望佇列在進入阻塞之前做一次垃圾收集。

以上所述的細節，基本上都體現在MessageQueue的next()函式裡了，現在我們就來看這個函式的主要流程。

4.2.1MessageQueue的next()成員函式

MessageQueue的next()函式的程式碼截選如下：

Message next() 
{
    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;

    for (;;) {
        . . . . . .
        nativePollOnce(mPtr, nextPollTimeoutMillis);    // 阻塞於此
        . . . . . .
            // 獲取next訊息，如能得到就返回之。
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;  // 先嚐試拿訊息佇列裡當前第一個訊息

            if (msg != null && msg.target == null) {
                // 如果從佇列裡拿到的msg是個“同步分割欄”，那麼就尋找其後第一個“非同步訊息”
                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);
                    msg.markInUse();
                    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 (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;
            }
        . . . . . .
        // 處理idle handlers部分
        for (int i = 0; i < pendingIdleHandlerCount; i++) {
            final IdleHandler idler = mPendingIdleHandlers[i];
            mPendingIdleHandlers[i] = null; // release the reference to the handler

            boolean keep = false;
            try {
                keep = idler.queueIdle();
            } catch (Throwable t) {
                Log.wtf("MessageQueue", "IdleHandler threw exception", t);
            }

            if (!keep) {
                synchronized (this) {
                    mIdleHandlers.remove(idler);
                }
            }
        }

        pendingIdleHandlerCount = 0;
        nextPollTimeoutMillis = 0;
    }
}

這個函式裡的for迴圈並不是起迴圈摘取訊息節點的作用，而是為了連貫“當前時間點”和“處理下一條訊息的時間點”。簡單地說，當“定時機制”觸發“摘取一條訊息”的動作時，會判斷事件佇列的首條訊息是否真的到時了，如果已經到時了，就直接返回這個msg，而如果尚未到時，則會努力計算一個較精確的等待時間（nextPollTimeoutMillis），計算完後，那個for迴圈會掉過頭再次呼叫到nativePollOnce(mPtr, nextPollTimeoutMillis)，進入阻塞狀態，從而等待合適的時長。

上面程式碼中也處理了“同步分割欄”的情況。如果從佇列裡獲取的訊息是個“同步分割欄”的話，可千萬不能把“同步分割欄”給返回了，此時會嘗試找尋其後第一個“非同步訊息”。

next()裡另一個要說的是那些Idle Handler，當訊息佇列中沒有訊息需要馬上處理時，會判斷使用者是否設定了Idle Handler，如果有的話，則會嘗試處理mIdleHandlers中所記錄的所有Idle Handler，此時會逐個呼叫這些Idle Handler的queueIdle()成員函式。我們舉一個例子，在ActivityThread中，在某種情況下會在訊息佇列中設定GcIdler，進行垃圾收集，其定義如下：

final class GcIdler implements MessageQueue.IdleHandler {
    @Override
    public final boolean queueIdle() {
        doGcIfNeeded();
        return false;
    }
}

一旦佇列裡設定了這個Idle Handler，那麼當佇列中沒有馬上需處理的訊息時，就會進行垃圾收集。

4.2.1.1nativePollOnce()

前文我們已經說過，next()中呼叫的nativePollOnce()起到了阻塞作用，保證訊息迴圈不會在無訊息處理時一直在那裡“傻轉”。那麼，nativePollOnce()函式究竟是如何實現阻塞功能的呢？我們來探索一下。首先，MessageQueue類裡宣告的幾個native函式，對應的JNI實現位於android_os_MessageQueue.cpp檔案中：
【frameworks/base/core/jni/android_os_MessageQueue.cpp】

static JNINativeMethod gMessageQueueMethods[] = {
    /* name, signature, funcPtr */
    { "nativeInit", "()I", (void*)android_os_MessageQueue_nativeInit },
    { "nativeDestroy", "(I)V", (void*)android_os_MessageQueue_nativeDestroy },
    { "nativePollOnce", "(II)V", (void*)android_os_MessageQueue_nativePollOnce },
    { "nativeWake", "(I)V", (void*)android_os_MessageQueue_nativeWake },
    { "nativeIsIdling", "(I)Z", (void*)android_os_MessageQueue_nativeIsIdling }
};

而且在MessageQueue構造之時，就會呼叫nativeInit()函式。

目前我們只關心nativePollOnce對應的android_os_MessageQueue_nativePollOnce()。其程式碼如下：

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jclass clazz,
                                                             jint ptr, jint timeoutMillis) 
{
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    nativeMessageQueue->pollOnce(env, timeoutMillis);
}

看到了吧，ptr引數會被強制轉換成NativeMessageQueue*。

NativeMessageQueue的pollOnce()如下：
【frameworks/base/core/jni/android_os_MessageQueue.cpp】

void NativeMessageQueue::pollOnce(JNIEnv* env, int timeoutMillis) {
    mInCallback = true;
    mLooper->pollOnce(timeoutMillis);   // 用到C++層的Looper物件
    mInCallback = false;
    if (mExceptionObj) {
        env->Throw(mExceptionObj);
        env->DeleteLocalRef(mExceptionObj);
        mExceptionObj = NULL;
    }
}

這裡會用到C++層的Looper類，它和Java層的Looper類可是不一樣的哩。C++層的Looper類的定義截選如下：
【system/core/include/utils/Looper.h】

class Looper : public ALooper, public RefBase {
protected:
    virtual ~Looper();

public:
    Looper(bool allowNonCallbacks);
    bool getAllowNonCallbacks() const;
    int pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData);
    . . . . . .
    int pollAll(int timeoutMillis, int* outFd, int* outEvents, void** outData);
    . . . . . .
    void wake();

    int addFd(int fd, int ident, int events, ALooper_callbackFunc callback, void* data);
    int addFd(int fd, int ident, int events, const sp<LooperCallback>& callback, void* data);
    int removeFd(int fd);

    void sendMessage(const sp<MessageHandler>& handler, const Message& message);
    void sendMessageDelayed(nsecs_t uptimeDelay, const sp<MessageHandler>& handler,
            const Message& message);
    void sendMessageAtTime(nsecs_t uptime, const sp<MessageHandler>& handler,
            const Message& message);
    void removeMessages(const sp<MessageHandler>& handler);
    void removeMessages(const sp<MessageHandler>& handler, int what);

    bool isIdling() const;
    static sp<Looper> prepare(int opts);
    static void setForThread(const sp<Looper>& looper);
    static sp<Looper> getForThread();
    . . . . . .
    . . . . . .
};

我們把C++層的NativeMessageQueue和Looper融入前文的示意圖，可以得到一張新的示意圖，如下所示：

C++層的Looper的建構函式如下：

Looper::Looper(bool allowNonCallbacks) :
        mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
        mResponseIndex(0), mNextMessageUptime(LLONG_MAX) 
{
    int wakeFds[2];
    int result = pipe(wakeFds);  // 建立一個管道
    LOG_ALWAYS_FATAL_IF(result != 0, "Could not create wake pipe.  errno=%d", errno);

    mWakeReadPipeFd = wakeFds[0];    // 管道的“讀取端”
    mWakeWritePipeFd = wakeFds[1];   // 管道的“寫入端”

    result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK);
    LOG_ALWAYS_FATAL_IF(result != 0, 
                       "Could not make wake read pipe non-blocking.  errno=%d", errno);

    result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK);
    LOG_ALWAYS_FATAL_IF(result != 0, 
                       "Could not make wake write pipe non-blocking.  errno=%d", errno);
    mIdling = false;

    // 建立一個epoll
    mEpollFd = epoll_create(EPOLL_SIZE_HINT);
    LOG_ALWAYS_FATAL_IF(mEpollFd < 0, "Could not create epoll instance.  errno=%d", errno);

    struct epoll_event eventItem;
    memset(& eventItem, 0, sizeof(epoll_event)); 
    eventItem.events = EPOLLIN;
    eventItem.data.fd = mWakeReadPipeFd;   
    // 監聽管道的read端
    result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
    LOG_ALWAYS_FATAL_IF(result != 0, 
                     "Could not add wake read pipe to epoll instance.  errno=%d", errno);
}

可以看到在構造Looper物件時，其內部除了建立了一個管道以外，還建立了一個epoll來監聽管道的“讀取端”。也就是說，是利用epoll機制來完成阻塞動作的。每當我們向訊息佇列傳送事件時，最終會間接向管道的“寫入端”寫入資料，這個前文已有敘述，於是epoll通過管道的“讀取端”立即就感知到了風吹草動，epoll_wait()在等到事件後，隨即進行相應的事件處理。這就是訊息迴圈阻塞並處理的大體流程。當然，因為向管道寫資料只是為了通知風吹草動，所以寫入的資料是非常簡單的“W”字串。現在大家不妨再看看前文闡述“nativeWake()”的小節，應該能明白了吧。

我們還是繼續說訊息迴圈。Looper的pollOnce()函式如下：
【system/core/libutils/Looper.cpp】

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) 
{
    int result = 0;
    for (;;) {
        . . . . . .
        if (result != 0) {
            . . . . . .
            if (outFd != NULL) *outFd = 0;
            if (outEvents != NULL) *outEvents = 0;
            if (outData != NULL) *outData = NULL;
            return result;
        }

        result = pollInner(timeoutMillis);
    }
}

int Looper::pollInner(int timeoutMillis) 
{
. . . . . .
    // 阻塞、等待
int eventCount = epoll_wait( mEpollFd, eventItems, 
                                   EPOLL_MAX_EVENTS, timeoutMillis);
    . . . . . .
    . . . . . .
    // 處理所有epoll事件
    for (int i = 0; i < eventCount; i++) 
    {
        int fd = eventItems[i].data.fd;
        uint32_t epollEvents = eventItems[i].events;
        if (fd == mWakeReadPipeFd) 
        {
            if (epollEvents & EPOLLIN) {
                awoken();  // 從管道中感知到EPOLLIN，於是呼叫awoken()
            } 
            . . . . . .
        } 
        else 
        {
            // 如果是除管道以外的其他fd發生了變動，那麼根據其對應的request，
            // 將response先記錄進mResponses
            ssize_t requestIndex = mRequests.indexOfKey(fd);
            if (requestIndex >= 0) {
                int events = 0;
                if (epollEvents & EPOLLIN ) events |= ALOOPER_EVENT_INPUT;
                if (epollEvents & EPOLLOUT) events |= ALOOPER_EVENT_OUTPUT;
                if (epollEvents & EPOLLERR) events |= ALOOPER_EVENT_ERROR;
                if (epollEvents & EPOLLHUP) events |= ALOOPER_EVENT_HANGUP;
                // 內部會呼叫 mResponses.push(response);
                pushResponse(events, mRequests.valueAt(requestIndex));
            } 
            . . . . . .
        }
    }

Done: ;
    . . . . . .
    // 呼叫尚未處理的事件的回撥
    while (mMessageEnvelopes.size() != 0) 
    {
        nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
        const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
        if (messageEnvelope.uptime <= now) 
        {
            { 
                sp<MessageHandler> handler = messageEnvelope.handler;
                Message message = messageEnvelope.message;
                mMessageEnvelopes.removeAt(0);
                . . . . . .
                handler->handleMessage(message);
            }
            . . . . . .
        } 
        else {
            mNextMessageUptime = messageEnvelope.uptime;
            break;
        }
    }

    . . . . . .
    // 呼叫所有response記錄的回撥
    for (size_t i = 0; i < mResponses.size(); i++) {
        Response& response = mResponses.editItemAt(i);
        if (response.request.ident == ALOOPER_POLL_CALLBACK) {
            . . . . . .
            int callbackResult = response.request.callback->handleEvent(fd, events, data);
            if (callbackResult == 0) {
                removeFd(fd);
            }
            . . . . . .
        }
    }
    return result;
}

現在我們可以畫一張呼叫示意圖，理一下loop()函式的呼叫關係，如下：

pollInner()呼叫epoll_wait()時傳入的timeoutMillis引數，其實來自於前文所說的MessageQueue的next()函式裡的nextPollTimeoutMillis，next()函式裡在以下3種情況下，會給nextPollTimeoutMillis賦不同的值：

1）如果訊息佇列中的下一條訊息還要等一段時間才到時的話，那麼nextPollTimeoutMillis賦值為Math.min(msg.when – now, Integer.MAX_VALUE)，即時間差；

2）如果訊息佇列已經是空佇列了，那麼nextPollTimeoutMillis賦值為-1；

3）不管前兩種情況下是否已給nextPollTimeoutMillis賦過值了，只要佇列中有Idle Handler需要處理，那麼在處理完所有Idle Handler之後，會強制將nextPollTimeoutMillis賦值為0。這主要是考慮到在處理Idle Handler時，不知道會耗時多少，而在此期間訊息佇列的“到時情況”有可能已發生改變。

不管epoll_wait()的超時閥值被設定成什麼，只要程式從epoll_wait()中返回，就會嘗試處理等到的epoll事件。目前我們的主要關心點是事件機制，所以主要討論當fd 等於mWakeReadPipeFd時的情況，此時會呼叫一下awoken()函式。該函式很簡單，只是在讀取mWakeReadPipeFd而已：

void Looper::awoken() {
#if DEBUG_POLL_AND_WAKE
    ALOGD("%p ~ awoken", this);
#endif

    char buffer[16];
    ssize_t nRead;
    do {
        nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
    } while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer));
}

為什麼要起個名字叫awoken()呢？這是因為當初傳送事件時，最終是呼叫一個wake()函式來通知訊息佇列的，現在epoll_wait()既然已經感應到了，自然相當於“被喚醒”（awoken）了。

除了感知mWakeReadPipeFd管道的情況以外，epoll還會感知其他一些fd對應的事件。在Looper中有一個mRequests鍵值向量表（KeyedVector<int, Request> mRequests），其鍵值就是感興趣的fd。如果收到的epoll事件所攜帶的fd可以在這張表裡查到，那麼就將該fd對應的Request整理進Response物件，並將該Response物件記入mResponses表。在pollInner()的最後，會用一個for迴圈遍歷mResponses表，分析每個Response表項對應的Request是不是需要callback，如果需要的話，執行對應的回撥函式：

int callbackResult = response.request.callback->handleEvent(fd, events, data);
if (callbackResult == 0) {
    removeFd(fd);
}

可以看到，handleEvent()的返回值將決定那個Request表項是否繼續保留在mRequests表中，如果返回值為0，說明不必保留了，所以刪除之。刪除時會同時從epoll中登出這個Request對應的fd，表示不再對這個fd感興趣了。

pollInner()內部還會集中處理所記錄的所有C++層的Message。在一個while迴圈中，不斷摘取mMessageEnvelopes向量表的第0個MessageEnvelope，如果訊息已經到時，則回撥handleMessage()。

sp<MessageHandler> handler = messageEnvelope.handler;
Message message = messageEnvelope.message;
mMessageEnvelopes.removeAt(0);
. . . . . .

handler->handleMessage(message);

而如果訊息未到時，說明while迴圈可以break了。

C++層的Looper及這個層次的訊息連結串列，再加上對應其他fd的Request和Response，可以形成下面這張示意圖：

從我們的分析中可以知道，在Android中，不光是Java層可以傳送Message，C++層也可以傳送，當然，不同層次的Message是放在不同層次的訊息鏈中的。在Java層，每次嘗試從佇列中獲取一個Message，而後dispatch它。而C++層的訊息則儘量在一次pollOnce中集中處理完畢，這是它們的一點不同。

5尾聲

關於Android的事件機制，我們就先說這麼多。總體上的而言還是比較簡單的，無非是通過Handler向Looper的訊息佇列中插入Message，而後再由Looper在訊息迴圈裡具體處理。因為訊息佇列本身不具有連結串列一變動就能馬上感知的功能，所以它需要藉助管道和epoll機制來監聽變動。當外界向訊息佇列中打入新訊息後，就向管道的“寫入端”寫入簡單資料，於是epoll可以立即感知到管道的變動，從何激發從訊息佇列中摘取訊息的動作。這就是Android事件機制的大體情況。