轉(zhuǎn)自：http://www.codeceo.com/article/android-event.html

?

1概述

在Android平臺(tái)上，主要用到兩種通信機(jī)制，即Binder機(jī)制和事件機(jī)制，前者用于跨進(jìn)程通信，后者用于進(jìn)程內(nèi)部通信。

從技術(shù)實(shí)現(xiàn)上來說，事件機(jī)制還是比較簡單的。從大的方面講，不光是Android平臺(tái)，各種平臺(tái)的消息機(jī)制的原理基本上都是相近的，其中用到的主要概念大概有：

1）消息發(fā)送者；
2）消息隊(duì)列；
3）消息處理循環(huán)。

示意圖如下：

圖中表達(dá)的基本意思是，消息發(fā)送者通過某種方式，將消息發(fā)送到某個(gè)消息隊(duì)列里，同時(shí)還有一個(gè)消息處理循環(huán)，不斷從消息隊(duì)列里摘取消息，并進(jìn)一步解析處理。

在Android平臺(tái)上，把上圖的右邊部分包裝成了一個(gè)Looper類，這個(gè)類的內(nèi)部具有對(duì)應(yīng)的消息隊(duì)列（MessageQueue? mQueue）和loop函數(shù)。

但是Looper只是個(gè)簡單的類而已，它雖然提供了循環(huán)處理方面的成員函數(shù)loop()，卻不能自己憑空地運(yùn)行起來，而只能寄身于某個(gè)真實(shí)的線程。而且，每個(gè)線程最多只能運(yùn)作一個(gè)Looper對(duì)象，這一點(diǎn)應(yīng)該很容易理解。

Android平臺(tái)上另一個(gè)關(guān)鍵類是Handler。當(dāng)消息循環(huán)在其寄身的線程里正式運(yùn)作后，外界就是通過Handler向消息循環(huán)發(fā)出事件的。我們?cè)佼嬕粡埵疽鈭D如下：

當(dāng)然，系統(tǒng)也允許多個(gè)Handler向同一個(gè)消息隊(duì)列發(fā)送消息：

整個(gè)消息機(jī)制的輪廓也就是這些啦，下面我們來詳細(xì)闡述。

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.classfinal MessageQueue mQueue;final Thread mThread;private Printer mLogging;. . . . . .. . . . . .

當(dāng)一個(gè)線程運(yùn)行到某處，準(zhǔn)備運(yùn)作一個(gè)Looper時(shí)，它必須先調(diào)用Looper類的靜態(tài)函數(shù)prepare()，做一些準(zhǔn)備工作。說穿了就是創(chuàng)建一個(gè)Looper對(duì)象，并把它設(shè)置進(jìn)線程的本地存儲(chǔ)區(qū)（TLS）里。然后線程才能繼續(xù)調(diào)用Looper類的另一個(gè)靜態(tài)函數(shù)loop()，從而建立起消息處理循環(huán)。示意圖如下：

prepare()函數(shù)的代碼如下：

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)); // 創(chuàng)建Looper對(duì)象，并設(shè)置進(jìn)TLS }

可以看到，sThreadLocal.set()一句所完成的工作，正是把新創(chuàng)建的Looper對(duì)象設(shè)置進(jìn)線程本地存儲(chǔ)區(qū)里。在Looper.prepare()之后，線程的主運(yùn)作函數(shù)就可以調(diào)用Looper.loop()了。

為了便于大家理解，我們多說兩句關(guān)于sThreadLocal的細(xì)節(jié)，這會(huì)牽扯一點(diǎn)兒本地存儲(chǔ)的技術(shù)。簡單地說，每個(gè)線程對(duì)象內(nèi)部會(huì)記錄一張邏輯上的key-value表，當(dāng)然，這張表在具體實(shí)現(xiàn)時(shí)不一定會(huì)被實(shí)現(xiàn)成HashMap，以我們目前的代碼來說，它被記錄成一個(gè)數(shù)組，其中每兩個(gè)數(shù)組項(xiàng)作為一個(gè)key-value單元。反正大家從邏輯上理解概念即可，不必拘泥于具體實(shí)現(xiàn)。很明顯，一個(gè)線程內(nèi)部是可以記錄多個(gè)本地存儲(chǔ)單元的，我們關(guān)心的sThreadLocal只是其中一個(gè)本地存儲(chǔ)單元的key而已。

當(dāng)我們?cè)诓煌琓hread里調(diào)用Looper.prepare()時(shí)，其實(shí)是向Thread對(duì)應(yīng)的那張表里添加一個(gè)key-value項(xiàng)，其中的key部分，指向的是同一個(gè)對(duì)象，即Looper.sThreadLocal靜態(tài)對(duì)象，而value部分，則彼此不同，我們可以畫出如下示意圖：

看到了吧，不同Thread會(huì)對(duì)應(yīng)不同Object[]數(shù)組，該數(shù)組以每2個(gè)元素為一個(gè)key-value對(duì)。請(qǐng)注意不同Thread雖然使用同一個(gè)靜態(tài)對(duì)象作為key值，最終卻會(huì)對(duì)應(yīng)不同的Looper對(duì)象，這一點(diǎn)系統(tǒng)是不會(huì)弄錯(cuò)的。

為了由淺入深地闡述問題，我們暫時(shí)先不看Looper.loop()內(nèi)部的代碼，這個(gè)后文還會(huì)再講。現(xiàn)在我們接著說說Handler。

3接著說一下Handler部分

一般而言，運(yùn)作Looper的線程會(huì)負(fù)責(zé)構(gòu)造自己的Handler對(duì)象，當(dāng)然，其他線程也可以針對(duì)某個(gè)Looper構(gòu)造Handler對(duì)象。

Handler對(duì)象在構(gòu)造時(shí)，不但會(huì)把Looper對(duì)象記錄在它內(nèi)部的mLooper成員變量中，還會(huì)把Looper對(duì)象的消息隊(duì)列也一并記錄，代碼截選如下：

public Handler(Callback callback, boolean async) {. . . . . .mLooper = Looper.myLooper(); // 記錄下Looper對(duì)象. . . . . .mQueue = mLooper.mQueue; // 也記錄下Looper對(duì)象的消息隊(duì)列mCallback = callback;mAsynchronous = async; }

我們也可以直接傳入Looper對(duì)象，此時(shí)可以使用另一個(gè)構(gòu)造函數(shù)：

public Handler(Looper looper, Callback callback, boolean async) {mLooper = looper; // 記錄下Looper對(duì)象mQueue = looper.mQueue; // 也記錄下Looper對(duì)象的消息隊(duì)列mCallback = callback;mAsynchronous = async; }

以后，每當(dāng)線程需要向消息隊(duì)列發(fā)送消息時(shí)，只需調(diào)用Handler對(duì)象的sendMessage()等成員函數(shù)就可以了。

簡單說來，只要一個(gè)線程可以獲取另一個(gè)目標(biāo)線程的某個(gè)Handler對(duì)象，它就具有了向目標(biāo)線程發(fā)送消息的能力。不過，也只是發(fā)送消息而已，消息的真正處理卻是在目標(biāo)線程的消息循環(huán)里完成的。

前文已經(jīng)說過，在Looper準(zhǔn)備停當(dāng)后，我們的線程會(huì)調(diào)用Looper.loop()，從而進(jìn)入真正的循環(huán)機(jī)制。loop()函數(shù)的代碼流程非常簡單，只不過是在一個(gè)for循環(huán)里不停從消息隊(duì)列中摘取消息，而后調(diào)用msg.target.dispatchMessage()對(duì)消息進(jìn)行派發(fā)處理而已。

這么看來，msg.target域就顯得比較重要了，說穿了，這個(gè)域記錄的其實(shí)就是當(dāng)初向消息隊(duì)列發(fā)送消息的那個(gè)handler啦。當(dāng)我們調(diào)用handler的send函數(shù)時(shí)，最終基本上都會(huì)走到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對(duì)象啦！日后msg.target.dispatchMessage()時(shí)會(huì)使用。msg.target = this; if (mAsynchronous) {msg.setAsynchronous(true);}return queue.enqueueMessage(msg, uptimeMillis); }

請(qǐng)大家注意msg.target = this;一句，記錄的就是handler對(duì)象。

當(dāng)Looper的消息循環(huán)最終調(diào)用到msg.target.dispatchMessage()時(shí)，會(huì)間接調(diào)用到handler的handleMessage()函數(shù)，從而對(duì)消息進(jìn)行實(shí)際處理。

在實(shí)際運(yùn)用handler時(shí)，大體有兩種方式。一種方式是寫一個(gè)繼承于Handler的新類，并在新類里實(shí)現(xiàn)自己的handleMessage()成員函數(shù)；另一種方式是在創(chuàng)建匿名Handler對(duì)象時(shí)，直接修改handleMessage()成員函數(shù)。

4消息隊(duì)列MessageQueue

在剛剛介紹Handler的sendMessageAtTime()時(shí)，我們已經(jīng)看到最終會(huì)調(diào)用queue.enqueueMessage()來向消息隊(duì)列打入消息。queue對(duì)應(yīng)的類是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 codeMessage mMessages; // 消息隊(duì)列！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記錄的就是一條消息鏈表。另外還有幾個(gè)native函數(shù)，這就說明MessageQueue會(huì)通過JNI技術(shù)調(diào)用到底層代碼。mMessages域記錄著消息隊(duì)列中所有Java層的實(shí)質(zhì)消息。請(qǐng)大家注意，記錄的只是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) {// 此時(shí)，新消息會(huì)插入到鏈表的表頭，這意味著隊(duì)列需要調(diào)整喚醒時(shí)間啦。msg.next = p;mMessages = msg;needWake = mBlocked;} else {// 此時(shí)，新消息會(huì)插入到鏈表的內(nèi)部，一般情況下，這不需要調(diào)整喚醒時(shí)間。// 但還必須考慮到當(dāng)表頭為“同步分割欄”的情況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是異步的，也不是鏈表中第一個(gè)異步消息，所以沒必要喚醒了needWake = false; }}msg.next = p;prev.next = msg;}if (needWake) {nativeWake(mPtr);}. . . . . . }

打入消息的動(dòng)作并不復(fù)雜，無非是在消息鏈表中找到合適的位置，插入Message節(jié)點(diǎn)而已。因?yàn)橄㈡湵硎前磿r(shí)間進(jìn)行排序的，所以主要是在比對(duì)Message攜帶的when信息。消息鏈表的首個(gè)節(jié)點(diǎn)對(duì)應(yīng)著最先將被處理的消息，如果Message被插到鏈表的頭部了，就意味著隊(duì)列的最近喚醒時(shí)間也應(yīng)該被調(diào)整了，因此needWake會(huì)被設(shè)為true，以便代碼下方可以走進(jìn)nativeWake()。

4.1.2說說“同步分割欄”

上面的代碼中還有一個(gè)“同步分割欄”的概念需要提一下。所謂“同步分割欄”，可以被理解為一個(gè)特殊Message，它的target域?yàn)閚ull。它不能通過sendMessageAtTime()等函數(shù)打入到消息隊(duì)列里，而只能通過調(diào)用Looper的postSyncBarrier()來打入。

“同步分割欄”是起什么作用的呢？它就像一個(gè)卡子，卡在消息鏈表中的某個(gè)位置，當(dāng)消息循環(huán)不斷從消息鏈表中摘取消息并進(jìn)行處理時(shí)，一旦遇到這種“同步分割欄”，那么即使在分割欄之后還有若干已經(jīng)到時(shí)的普通Message，也不會(huì)摘取這些消息了。請(qǐng)注意，此時(shí)只是不會(huì)摘取“普通Message”了，如果隊(duì)列中還設(shè)置有“異步Message”，那么還是會(huì)摘取已到時(shí)的“異步Message”的。

在Android的消息機(jī)制里，“普通Message”和“異步Message”也就是這點(diǎn)兒區(qū)別啦，也就是說，如果消息列表中根本沒有設(shè)置“同步分割欄”的話，那么“普通Message”和“異步Message”的處理就沒什么大的不同了。

打入“同步分割欄”的postSyncBarrier()函數(shù)的代碼如下：
【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”，只需調(diào)用一下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”向消息隊(duì)列打入“異步Message”的。異步Handler的mAsynchronous域?yàn)閠rue，因此它在調(diào)用enqueueMessage()時(shí)，可以走入：

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

現(xiàn)在我們畫一張關(guān)于“同步分割欄”的示意圖：

圖中的消息隊(duì)列中有一個(gè)“同步分割欄”，因此它后面的“2”號(hào)Message即使到時(shí)了，也不會(huì)摘取下來。而“3”號(hào)Message因?yàn)槭莻€(gè)異步Message，所以當(dāng)它到時(shí)后，是可以進(jìn)行處理的。

“同步分割欄”這種卡子會(huì)一直卡在消息隊(duì)列中，除非我們調(diào)用removeSyncBarrier()刪除這個(gè)卡子。
【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);}} }

和插入消息類似，如果刪除動(dòng)作改變了鏈表的頭部，也意味著隊(duì)列的最近喚醒時(shí)間應(yīng)該被調(diào)整了，因此needWake會(huì)被設(shè)為true，以便代碼下方可以走進(jìn)nativeWake()。

4.1.3nativeWake()

nativeWake()對(duì)應(yīng)的C++層函數(shù)如下：
【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()動(dòng)作主要是向一個(gè)管道的“寫入端”寫入了“W”。有關(guān)這個(gè)管道的細(xì)節(jié)，我們會(huì)在后文再細(xì)說，這里先放下。

4.2消息循環(huán)

接下來我們來看看消息循環(huán)。我們從Looper的Loop()函數(shù)開始講起。下面是loop()函數(shù)的簡略代碼，我們只保留了其中最關(guān)鍵的部分：
【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); // 派發(fā)消息. . . . . .final long newIdent = Binder.clearCallingIdentity();. . . . . .msg.recycle();} }

無非是在一個(gè)for循環(huán)里不斷摘取隊(duì)列里的下一條消息，而后dispatchMessage()消息。呃，至少邏輯上就是這么簡單，但如果我們希望再探索得更深一點(diǎn)的話，就得詳細(xì)研究MessageQueue以及其next()函數(shù)了。

對(duì)于Looper而言，它主要關(guān)心的是從消息隊(duì)列里摘取消息，而后分派消息。然而對(duì)消息隊(duì)列而言，在摘取消息時(shí)還要考慮更多技術(shù)細(xì)節(jié)。它關(guān)心的細(xì)節(jié)有：

1）如果消息隊(duì)列里目前沒有合適的消息可以摘取，那么不能讓它所屬的線程“傻轉(zhuǎn)”，而應(yīng)該使之阻塞；
2）隊(duì)列里的消息應(yīng)該按其“到時(shí)”的順序進(jìn)行排列，最先到時(shí)的消息會(huì)放在隊(duì)頭，也就是mMessages域所指向的消息，其后的消息依次排開；
3）阻塞的時(shí)間最好能精確一點(diǎn)兒，所以如果暫時(shí)沒有合適的消息節(jié)點(diǎn)可摘時(shí)，要考慮鏈表首個(gè)消息節(jié)點(diǎn)將在什么時(shí)候到時(shí)，所以這個(gè)消息節(jié)點(diǎn)距離當(dāng)前時(shí)刻的時(shí)間差，就是我們要阻塞的時(shí)長。
4）有時(shí)候外界希望隊(duì)列能在即將進(jìn)入阻塞狀態(tài)之前做一些動(dòng)作，這些動(dòng)作可以稱為idle動(dòng)作，我們需要兼顧處理這些idle動(dòng)作。一個(gè)典型的例子是外界希望隊(duì)列在進(jìn)入阻塞之前做一次垃圾收集。

以上所述的細(xì)節(jié)，基本上都體現(xiàn)在MessageQueue的next()函數(shù)里了，現(xiàn)在我們就來看這個(gè)函數(shù)的主要流程。

4.2.1MessageQueue的next()成員函數(shù)

MessageQueue的next()函數(shù)的代碼截選如下：

Message next() {int pendingIdleHandlerCount = -1; // -1 only during first iterationint nextPollTimeoutMillis = 0;for (;;) {. . . . . .nativePollOnce(mPtr, nextPollTimeoutMillis); // 阻塞于此. . . . . .// 獲取next消息，如能得到就返回之。final long now = SystemClock.uptimeMillis();Message prevMsg = null;Message msg = mMessages; // 先嘗試拿消息隊(duì)列里當(dāng)前第一個(gè)消息if (msg != null && msg.target == null) {// 如果從隊(duì)列里拿到的msg是個(gè)“同步分割欄”，那么就尋找其后第一個(gè)“異步消息”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; // 重新設(shè)置一下消息隊(duì)列的頭部}msg.next = null;if (false) Log.v("MessageQueue", "Returning message: " + msg);msg.markInUse();return msg; // 返回得到的消息對(duì)象}} 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 handlerboolean 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;} }

這個(gè)函數(shù)里的for循環(huán)并不是起循環(huán)摘取消息節(jié)點(diǎn)的作用，而是為了連貫“當(dāng)前時(shí)間點(diǎn)”和“處理下一條消息的時(shí)間點(diǎn)”。簡單地說，當(dāng)“定時(shí)機(jī)制”觸發(fā)“摘取一條消息”的動(dòng)作時(shí)，會(huì)判斷事件隊(duì)列的首條消息是否真的到時(shí)了，如果已經(jīng)到時(shí)了，就直接返回這個(gè)msg，而如果尚未到時(shí)，則會(huì)努力計(jì)算一個(gè)較精確的等待時(shí)間（nextPollTimeoutMillis），計(jì)算完后，那個(gè)for循環(huán)會(huì)掉過頭再次調(diào)用到nativePollOnce(mPtr, nextPollTimeoutMillis)，進(jìn)入阻塞狀態(tài)，從而等待合適的時(shí)長。

上面代碼中也處理了“同步分割欄”的情況。如果從隊(duì)列里獲取的消息是個(gè)“同步分割欄”的話，可千萬不能把“同步分割欄”給返回了，此時(shí)會(huì)嘗試找尋其后第一個(gè)“異步消息”。

next()里另一個(gè)要說的是那些Idle Handler，當(dāng)消息隊(duì)列中沒有消息需要馬上處理時(shí)，會(huì)判斷用戶是否設(shè)置了Idle Handler，如果有的話，則會(huì)嘗試處理mIdleHandlers中所記錄的所有Idle Handler，此時(shí)會(huì)逐個(gè)調(diào)用這些Idle Handler的queueIdle()成員函數(shù)。我們舉一個(gè)例子，在ActivityThread中，在某種情況下會(huì)在消息隊(duì)列中設(shè)置GcIdler，進(jìn)行垃圾收集，其定義如下：

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

一旦隊(duì)列里設(shè)置了這個(gè)Idle Handler，那么當(dāng)隊(duì)列中沒有馬上需處理的消息時(shí)，就會(huì)進(jìn)行垃圾收集。

4.2.1.1nativePollOnce()

前文我們已經(jīng)說過，next()中調(diào)用的nativePollOnce()起到了阻塞作用，保證消息循環(huán)不會(huì)在無消息處理時(shí)一直在那里“傻轉(zhuǎn)”。那么，nativePollOnce()函數(shù)究竟是如何實(shí)現(xiàn)阻塞功能的呢？我們來探索一下。首先，MessageQueue類里聲明的幾個(gè)native函數(shù)，對(duì)應(yīng)的JNI實(shí)現(xiàn)位于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構(gòu)造之時(shí)，就會(huì)調(diào)用nativeInit()函數(shù)。

目前我們只關(guān)心nativePollOnce對(duì)應(yīng)的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參數(shù)會(huì)被強(qiáng)制轉(zhuǎn)換成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對(duì)象mInCallback = false;if (mExceptionObj) {env->Throw(mExceptionObj);env->DeleteLocalRef(mExceptionObj);mExceptionObj = NULL;} }

這里會(huì)用到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的構(gòu)造函數(shù)如下：

Looper::Looper(bool allowNonCallbacks) :mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {int wakeFds[2];int result = pipe(wakeFds); // 創(chuàng)建一個(gè)管道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;// 創(chuàng)建一個(gè)epollmEpollFd = 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; // 監(jiān)聽管道的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); }

可以看到在構(gòu)造Looper對(duì)象時(shí)，其內(nèi)部除了創(chuàng)建了一個(gè)管道以外，還創(chuàng)建了一個(gè)epoll來監(jiān)聽管道的“讀取端”。也就是說，是利用epoll機(jī)制來完成阻塞動(dòng)作的。每當(dāng)我們向消息隊(duì)列發(fā)送事件時(shí)，最終會(huì)間接向管道的“寫入端”寫入數(shù)據(jù)，這個(gè)前文已有敘述，于是epoll通過管道的“讀取端”立即就感知到了風(fēng)吹草動(dòng)，epoll_wait()在等到事件后，隨即進(jìn)行相應(yīng)的事件處理。這就是消息循環(huán)阻塞并處理的大體流程。當(dāng)然，因?yàn)橄蚬艿缹憯?shù)據(jù)只是為了通知風(fēng)吹草動(dòng)，所以寫入的數(shù)據(jù)是非常簡單的“W”字符串。現(xiàn)在大家不妨再看看前文闡述“nativeWake()”的小節(jié)，應(yīng)該能明白了吧。

我們還是繼續(xù)說消息循環(huán)。Looper的pollOnce()函數(shù)如下：
【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，于是調(diào)用awoken()} . . . . . .} else {// 如果是除管道以外的其他fd發(fā)生了變動(dòng)，那么根據(jù)其對(duì)應(yīng)的request，// 將response先記錄進(jìn)mResponsesssize_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;// 內(nèi)部會(huì)調(diào)用 mResponses.push(response);pushResponse(events, mRequests.valueAt(requestIndex));} . . . . . .}}Done: ;. . . . . .// 調(diào)用尚未處理的事件的回調(diào)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;}}. . . . . .// 調(diào)用所有response記錄的回調(diào)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; }

現(xiàn)在我們可以畫一張調(diào)用示意圖，理一下loop()函數(shù)的調(diào)用關(guān)系，如下：

pollInner()調(diào)用epoll_wait()時(shí)傳入的timeoutMillis參數(shù)，其實(shí)來自于前文所說的MessageQueue的next()函數(shù)里的nextPollTimeoutMillis，next()函數(shù)里在以下3種情況下，會(huì)給nextPollTimeoutMillis賦不同的值：

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

2）如果消息隊(duì)列已經(jīng)是空隊(duì)列了，那么nextPollTimeoutMillis賦值為-1；

3）不管前兩種情況下是否已給nextPollTimeoutMillis賦過值了，只要隊(duì)列中有Idle Handler需要處理，那么在處理完所有Idle Handler之后，會(huì)強(qiáng)制將nextPollTimeoutMillis賦值為0。這主要是考慮到在處理Idle Handler時(shí)，不知道會(huì)耗時(shí)多少，而在此期間消息隊(duì)列的“到時(shí)情況”有可能已發(fā)生改變。

不管epoll_wait()的超時(shí)閥值被設(shè)置成什么，只要程序從epoll_wait()中返回，就會(huì)嘗試處理等到的epoll事件。目前我們的主要關(guān)心點(diǎn)是事件機(jī)制，所以主要討論當(dāng)fd 等于mWakeReadPipeFd時(shí)的情況，此時(shí)會(huì)調(diào)用一下awoken()函數(shù)。該函數(shù)很簡單，只是在讀取mWakeReadPipeFd而已：

void Looper::awoken() { #if DEBUG_POLL_AND_WAKEALOGD("%p ~ awoken", this); #endifchar buffer[16];ssize_t nRead;do {nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));} while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer)); }

為什么要起個(gè)名字叫awoken()呢？這是因?yàn)楫?dāng)初發(fā)送事件時(shí)，最終是調(diào)用一個(gè)wake()函數(shù)來通知消息隊(duì)列的，現(xiàn)在epoll_wait()既然已經(jīng)感應(yīng)到了，自然相當(dāng)于“被喚醒”（awoken）了。

除了感知mWakeReadPipeFd管道的情況以外，epoll還會(huì)感知其他一些fd對(duì)應(yīng)的事件。在Looper中有一個(gè)mRequests鍵值向量表（KeyedVector<int, Request> mRequests），其鍵值就是感興趣的fd。如果收到的epoll事件所攜帶的fd可以在這張表里查到，那么就將該fd對(duì)應(yīng)的Request整理進(jìn)Response對(duì)象，并將該Response對(duì)象記入mResponses表。在pollInner()的最后，會(huì)用一個(gè)for循環(huán)遍歷mResponses表，分析每個(gè)Response表項(xiàng)對(duì)應(yīng)的Request是不是需要callback，如果需要的話，執(zhí)行對(duì)應(yīng)的回調(diào)函數(shù)：

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

可以看到，handleEvent()的返回值將決定那個(gè)Request表項(xiàng)是否繼續(xù)保留在mRequests表中，如果返回值為0，說明不必保留了，所以刪除之。刪除時(shí)會(huì)同時(shí)從epoll中注銷這個(gè)Request對(duì)應(yīng)的fd，表示不再對(duì)這個(gè)fd感興趣了。

pollInner()內(nèi)部還會(huì)集中處理所記錄的所有C++層的Message。在一個(gè)while循環(huán)中，不斷摘取mMessageEnvelopes向量表的第0個(gè)MessageEnvelope，如果消息已經(jīng)到時(shí)，則回調(diào)handleMessage()。

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

而如果消息未到時(shí)，說明while循環(huán)可以break了。

C++層的Looper及這個(gè)層次的消息鏈表，再加上對(duì)應(yīng)其他fd的Request和Response，可以形成下面這張示意圖：

從我們的分析中可以知道，在Android中，不光是Java層可以發(fā)送Message，C++層也可以發(fā)送，當(dāng)然，不同層次的Message是放在不同層次的消息鏈中的。在Java層，每次嘗試從隊(duì)列中獲取一個(gè)Message，而后dispatch它。而C++層的消息則盡量在一次pollOnce中集中處理完畢，這是它們的一點(diǎn)不同。

5尾聲

關(guān)于Android的事件機(jī)制，我們就先說這么多。總體上的而言還是比較簡單的，無非是通過Handler向Looper的消息隊(duì)列中插入Message，而后再由Looper在消息循環(huán)里具體處理。因?yàn)橄㈥?duì)列本身不具有鏈表一變動(dòng)就能馬上感知的功能，所以它需要借助管道和epoll機(jī)制來監(jiān)聽變動(dòng)。當(dāng)外界向消息隊(duì)列中打入新消息后，就向管道的“寫入端”寫入簡單數(shù)據(jù)，于是epoll可以立即感知到管道的變動(dòng)，從何激發(fā)從消息隊(duì)列中摘取消息的動(dòng)作。這就是Android事件機(jī)制的大體情況。

?

轉(zhuǎn)載于:https://www.cnblogs.com/wllearnandroid/p/5332400.html

總結(jié)

以上是生活随笔為你收集整理的Android事件机制详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。