前言

Android 消息機制，一直都是 Android 應(yīng)用框架層非常重要的一部分，想更加優(yōu)雅的進行 Android 開發(fā)，我想了解消息機制是非常必要的一個過程，此前也分析過很多次 Handler 消息機制， 不過都是浮于 Java 層，對于底層的源碼并沒有深究，經(jīng)過一年的努力，筆者對于 Android 應(yīng)用框架層有了新的認(rèn)識和理解，這里重新寫下這篇文章。
本文主要從以下幾點來闡述 Androd 消息機制

• 線程消息隊列的創(chuàng)建入口
• 消息循環(huán)的準(zhǔn)備
• 消息循環(huán)的啟動
• 消息的發(fā)送與處理

一. 線程消息隊列創(chuàng)建入口

我們知道, 應(yīng)用進程主線程初始化的入口是在 ActivityThread.main() 中, 我們看看他是如何構(gòu)建消息隊列的

public class ActivityThread {static volatile Handler sMainThreadHandler; // set once in main()public static void main(String[] args) {......// 1. 做一些主線程消息循環(huán)的初始操作Looper.prepareMainLooper();......// 2. 啟動消息循環(huán)Looper.loop();}} 復(fù)制代碼

好的, 可以看到 ActivityThread 中的消息循環(huán)構(gòu)建過程如下

• 調(diào)用 Looper.prepareMainLooper, 做一些準(zhǔn)備操作
• 調(diào)用 Looper.loop 真正的開啟了消息循環(huán)

接下來我們先看看準(zhǔn)備操作中做了些什么

二. 消息循環(huán)的準(zhǔn)備

public final class Looper {private static Looper sMainLooper; // guarded by Looper.classpublic static void prepareMainLooper() {// 1. 調(diào)用 prepare 方法真正執(zhí)行主線程的準(zhǔn)備操作prepare(false);synchronized (Looper.class) {if (sMainLooper != null) {throw new IllegalStateException("The main Looper has already been prepared.");}// 2. 調(diào)用了 myLooper 方法, 獲取一個 Looper 對象給 sMainLooper 賦值sMainLooper = myLooper();}}static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();private static void prepare(boolean quitAllowed) {if (sThreadLocal.get() != null) {throw new RuntimeException("Only one Looper may be created per thread");}// 1.1 new 了一個 Looper 對象// 1.2 將這個 Looper 對象寫入 ThreadLocal 中sThreadLocal.set(new Looper(quitAllowed));}public static @Nullable Looper myLooper() {// 2.1 通過 ThreadLocal 獲取這個線程中唯一的 Looper 對象return sThreadLocal.get();}final MessageQueue mQueue;final Thread mThread;private Looper(boolean quitAllowed) {// 創(chuàng)建了一個消息隊列mQueue = new MessageQueue(quitAllowed);// 獲取了當(dāng)前的線程mThread = Thread.currentThread();}} 復(fù)制代碼

可以看到 Looper.prepareMainLooper 中主要做了如下幾件事情

• 調(diào)用 prepare 方法真正執(zhí)行主線程的準(zhǔn)備操作
  • 創(chuàng)建了一個 Looper 對象
    • 創(chuàng)建了 MessageQueue 這個消息隊列, 保存到成員變量 mQueue 中
    • 獲取該對象創(chuàng)建線程, 保存到成員變量 mThread 中
  • 將這個 Looper 對象存入 ThreadLocal 中
• 調(diào)用 myLooper 方法, 從 ThreadLocal 中獲取剛剛寫入的 Looper 對象
• 將這個 Looper 對象, 保存到靜態(tài)變量 sMainLooper 中, 表示這個是當(dāng)前應(yīng)用進程主線程的 Looper 對象

好的, 可以看到在創(chuàng)建 Looper 對象的時候, 同時會創(chuàng)建一個 MessageQueue 對象, 將它保存到 Looper 對象的成員變量 mQueue 中, 因此每一個 Looper 對象都對應(yīng)一個 MessageQueue 對象

我們接下來看看 MessageQueue 對象創(chuàng)建時, 做了哪些操作

MessageQueue 的創(chuàng)建

public final class MessageQueue {private final boolean mQuitAllowed; // true 表示這個消息隊列是可停止的private long mPtr; // 描述一個 Native 的句柄MessageQueue(boolean quitAllowed) {mQuitAllowed = quitAllowed;// 獲取一個 native 句柄mPtr = nativeInit();}private native static long nativeInit();} 復(fù)制代碼

好的, 可以看到 MessageQueue 對象在創(chuàng)建的過程中, 會調(diào)用 nativeInit 來獲取一個 native 的句柄, 我們看看這個 nativeInit 做了哪些操作

// frameworks/base/core/jni/android_os_MessageQueue.cpp static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {// 1. 創(chuàng)建了一個 NativeMessageQueue 對象NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();......// 增加 env 對它的強引用計數(shù)nativeMessageQueue->incStrong(env);// 2. 將這個 NativeMessageQueue 對象強轉(zhuǎn)成了一個句柄返回 Java 層return reinterpret_cast<jlong>(nativeMessageQueue); }class NativeMessageQueue : public MessageQueue, public LooperCallback { public:NativeMessageQueue();...... private:JNIEnv* mPollEnv;jobject mPollObj;jthrowable mExceptionObj; };NativeMessageQueue::NativeMessageQueue() :mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) {// 1.1 嘗試調(diào)用 Looper.getForThread 獲取一個 C++ 的 Looper 對象mLooper = Looper::getForThread();// 1.2 若當(dāng)前線程沒有創(chuàng)建過 Looper, 則走這個分支if (mLooper == NULL) {// 創(chuàng)建 Looper 對象mLooper = new Looper(false);// 給當(dāng)前線程綁定這個 Looper 對象Looper::setForThread(mLooper);} } 復(fù)制代碼

好的可以看到 nativeInit 方法主要做了如下的操作

• 創(chuàng)建了一個 C++ 的 NativeMessageQueue 對象
  • 嘗試通過 Looper.getForThread 獲取一個 C++ 的 Looper 對象
  • 若當(dāng)前線程沒有創(chuàng)建過 Looper
    • new 一個 C++ 的 Looper 對象
    • 給當(dāng)前線程綁定 Looper 對象

可以看到這里的流程與 Java 的相反

• Java 是先創(chuàng)建 Looper, 然后在 Looper 內(nèi)部創(chuàng)建 MessageQueue
• Native 是先創(chuàng)建 NativeMessageQueue, 在其創(chuàng)建的過程中創(chuàng)建 Looper

接下來看看這個 C++ 的 Looper 對象在實例化的過程中做了哪些事情

Looper(Native) 的實例化

// system/core/libutils/Looper.cpp Looper::Looper(bool allowNonCallbacks) :mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),mPolling(false), mEpollFd(-1), mEpollRebuildRequired(false),mNextRequestSeq(0), mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {// 1. 創(chuàng)建 pipe 管道, 返回該管道文件讀寫的描述符mWakeEventFd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);AutoMutex _l(mLock);// 處理 epoll 相關(guān)事宜rebuildEpollLocked(); }void Looper::rebuildEpollLocked() {......// 2. 創(chuàng)建一個 epoll 對象, 將其文件描述符保存在成員變量 mEpollFd 中mEpollFd = epoll_create(EPOLL_SIZE_HINT);// 3. 將 pipe 管道的文件讀寫描述符 mWakeEventFd, 添加到 epoll 中, 讓 epoll 對該管道的讀寫進行監(jiān)聽struct epoll_event eventItem;memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field unioneventItem.events = EPOLLIN;eventItem.data.fd = mWakeEventFd;int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeEventFd, & eventItem);...... } 復(fù)制代碼

好的, 可以看到 Looper 實例化時做了如下的操作

• 調(diào)用 eventfd 創(chuàng)建了一個 pipe 管道, 返回了該管道的文件讀寫描述符
• 創(chuàng)建了一個 epoll 對象
• 將 pipe 管道的文件讀寫描述符 mWakeEventFd, 添加到 epoll 中, 讓 epoll 對該管道的讀寫進行監(jiān)聽

可以看到這里引入了兩個新的名詞, pipe 管道 和 管道監(jiān)聽管理對象 epoll

• pipe 管道: 這個管道在一個線程的消息循環(huán)過程中起到的作用非常大

  • 當(dāng)一個線程沒有新的消息需要處理時, 它就會睡眠在這個管道的讀端文件描述符上, 直到有新的消息需要處理為止
  • 當(dāng)其他線程向這個線程發(fā)送了一個消息之后, 其他線程就會通過這個管道的寫端文件描述符寫入一個數(shù)據(jù), 從而將這個線程喚醒, 以便它可以對剛才發(fā)送到它消息隊列中的消息進行處理

• epoll: epoll 機制是 Linux 為了同時監(jiān)聽多個文件描述符的 IO 讀寫事件而設(shè)計的 多路復(fù)用 IO 接口

  • 當(dāng) epoll 監(jiān)聽了大量文件描述符的 IO 讀寫事件, 但只有少量的文件描述符是活躍的, 那么這個 epoll 會顯著的減少 CPU 的使用率

相互依賴的結(jié)構(gòu)圖

到這里消息循環(huán)的準(zhǔn)備工作就已經(jīng)完成了, 這里分析一下它們的結(jié)構(gòu)圖

三. 消息循環(huán)的啟動

public final class Looper {public static void loop() {// 1. 獲取調(diào)用線程的 Looper 對象final Looper me = myLooper();......// 2. 獲取 Looper 對應(yīng)的消息隊列final MessageQueue queue = me.mQueue;// 3. 死循環(huán), 不斷的處理消息隊列中的消息for (;;) {// 3.1 獲取消息隊列中的消息, 取不到消息會阻塞Message msg = queue.next(); // might blockif (msg == null) {// 若取到的消息為 null, 這個 Looper 就結(jié)束了return;}......try {// 3.2 處理消息msg.target.dispatchMessage(msg);} finally {......}......}}} 復(fù)制代碼

好的, 可以看到 Looper 的 loop 方法主要做了如下幾件事情

• 從方法調(diào)用的線程中取 Looper 對象
• 獲取這個 Looper 對應(yīng)的消息隊列
• 通過死循環(huán), 不斷地處理消息隊列中的數(shù)據(jù)
  • 通過 MessageQueue.next() 獲取下一條要處理的 Msg
  • 通過 msg.target.dispatchMessage(msg); 分發(fā)處理消息(本次不細究)

好的, 可以看到獲取消息的方式是通過 MessageQueue.next 拿到的, 我們接下來看看它是如何獲取的

從隊列中取消息

public final class MessageQueue {Message next() {// 獲取 NativeMessageQueue 的句柄final long ptr = mPtr;if (ptr == 0) {return null;}// 描述空閑事件處理者的數(shù)量, 初始值為 -1 int pendingIdleHandlerCount = -1; // 描述當(dāng)前線程沒有新消息處理時, 可睡眠的時間int nextPollTimeoutMillis = 0;// 死循環(huán), 獲取可執(zhí)行的 Message 對象for (;;) {// 1. 若 nextPollTimeoutMillis 不為 0, 則說明距離下一個 Message 執(zhí)行, 有一定的時間間隔if (nextPollTimeoutMillis != 0) {// 在空閑期間, 執(zhí)行 Binder 通信相關(guān)的指令Binder.flushPendingCommands();}// 2. 這里調(diào)用了 nativePollOnce, 在 native 層檢查消息隊列中是否有 msg 可讀, 若無可執(zhí)行的 msg, 則執(zhí)行線程的睡眠, 時間由 nextPollTimeoutMillis 決定nativePollOnce(ptr, nextPollTimeoutMillis);// 3. 取隊列中下一條要執(zhí)行的 Message 對象, 并返回出去synchronized (this) {final long now = SystemClock.uptimeMillis(); // 獲取當(dāng)前時刻Message prevMsg = null;Message msg = mMessages;// 3.1 移除消息隊列中無效的 Message // Condition: msg 不為 null & msg 的處理者為 nullif (msg != null && msg.target == null) {do {prevMsg = msg;msg = msg.next;} while (msg != null && !msg.isAsynchronous());}// 3.2 隊列首部存在有效的 msg if (msg != null) {// 3.2.1 若當(dāng)前的時刻 早于 隊首消息要執(zhí)行的時刻if (now < msg.when) {// 給 nextPollTimeoutMillis 賦值, 表示當(dāng)前線程, 可睡眠的時間nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);} else {// 3.2.2 若當(dāng)前的時刻 不小于 隊首消息要執(zhí)行的時刻mBlocked = false;// 更改標(biāo)記位置if (prevMsg != null) {prevMsg.next = msg.next;} else {mMessages = msg.next;}msg.next = null;// 將隊首消息返回出去return msg;}} else {// 3.3 說明消息隊列中無消息, 則給 nextPollTimeoutMillis 置為 -1, // 表示可以無限睡眠, 直至消息隊列中有消息可讀nextPollTimeoutMillis = -1;}// 4. 獲取一些空閑事件的處理者if (pendingIdleHandlerCount < 0&& (mMessages == null || now < mMessages.when)) {pendingIdleHandlerCount = mIdleHandlers.size();}// 若無空閑事件, 則進行下一次 for 循環(huán)if (pendingIdleHandlerCount <= 0) {mBlocked = true;continue;}.......}// 4.1 處理空閑事件......// 4.2 走到這里, 說明所有的空閑事件都已經(jīng)處理好了// 將需要處理的空閑事件,置為 0 pendingIdleHandlerCount = 0;// 5. 因為處理空閑事件是耗時操作, 期間可能有新的 Message 入隊列, 因此將可睡眠時長置為 0, 表示需要再次檢查nextPollTimeoutMillis = 0;}}// native 方法private native void nativePollOnce(long ptr, int timeoutMillis); /*non-static for callbacks*/} 復(fù)制代碼

可以看到 MessageQueue.next 內(nèi)部維護了一個死循環(huán), 用于獲取下一條 msg, 這個 for 循環(huán)做了如下的操作

• 若 nextPollTimeoutMillis 不為 0, 則說明距離下一個 Message 執(zhí)行, 有一定的時間間隔
  • 在空閑期間, 執(zhí)行 Binder 通信相關(guān)的指令
• 調(diào)用 nativePollOnce 根據(jù) nextPollTimeoutMillis 時長, 執(zhí)行當(dāng)前線程的睡眠操作
• 取隊列中下一條要執(zhí)行的 Message
  • 移除消息隊列中無效的 Message
  • 隊列首部存在有效的 msg
    • 若當(dāng)前的時刻 < 隊首消息要執(zhí)行的時刻
      • 則更新 nextPollTimeoutMillis, 下次進行 for 循環(huán)時, 會進行睡眠操作
    • 若當(dāng)前的時刻 >= 隊首消息要執(zhí)行的時刻
      • 則將隊首消息的描述返回出去
  • 隊列首部不存在有效的 msg
    • 將 nextPollTimeoutMillis 置為 -1, 下次 for 循環(huán)時可以無限睡眠, 直至消息隊列中有消息可讀
• 空閑消息的獲取和處理(本次不細究)
  • 獲取空閑事件的處理者
  • 若無空閑事件, 則進行下一次 for 循環(huán)
  • 若存在空閑事件, 則處理空閑事件
    • 將 pendingIdleHandlerCount 置為 0, 表示空閑事件都已經(jīng)處理完成了
    • 將 nextPollTimeoutMillis 置為 0, 因為處理空閑事件是耗時操作, 期間可能有新的 Message 入隊列, 因此將可睡眠時長置為 0, 表示需要再次檢查

至此一次 for 循環(huán)就結(jié)束了, 可以看到 Message.next() 中其他的邏輯都非常的清晰, 但其睡眠是一個 native 方法, 我們繼續(xù)看看它的內(nèi)部實現(xiàn)

消息隊列中無消息時線程睡眠的實現(xiàn)

// frameworks/base/core/jni/android_os_MessageQueue.cpp static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,jlong ptr, jint timeoutMillis) {NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);// 調(diào)用了 NativeMessageQueue 的 pollOncenativeMessageQueue->pollOnce(env, obj, timeoutMillis); }void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {......// 1. 調(diào)用了 Looper 的 pollOnemLooper->pollOnce(timeoutMillis);...... }// system/core/libutils/Looper.cpp int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {int result = 0;for (;;) {......// result 不為 0 說明讀到了消息if (result != 0) {......return result;}// 2. 若未讀到消息, 則調(diào)用 pollInnerresult = pollInner(timeoutMillis);} }int Looper::pollInner(int timeoutMillis) {......int result = POLL_WAKE;......struct epoll_event eventItems[EPOLL_MAX_EVENTS];// 3. 調(diào)用 epoll_wait 來監(jiān)聽 pipe 中的 IO 事件, 若無事件, 則睡眠在文件讀操作上, 時長由 timeoutMillis 決定int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);// 4. 走到這里, 說明睡眠結(jié)束了for (int i = 0; i < eventCount; i++) {int fd = eventItems[i].data.fd; // 獲取文件描述uint32_t epollEvents = eventItems[i].events;// 5. 若為喚醒事件的文件描述, 則執(zhí)行喚醒操作if (fd == mWakeEventFd) {if (epollEvents & EPOLLIN) {awoken();// 喚醒} else {......}} else {......}}......return result; } 復(fù)制代碼

好的可以看到 JNI 方法 nativePollOnce, 其內(nèi)部流程如下

• 將 Poll 操作轉(zhuǎn)發(fā)給了 Looper.pollOne
• 若未讀到消息, 則調(diào)用 Looper.pollInner
• 調(diào)用 epoll_wait 來監(jiān)聽 pipe 中的 IO 事件, 若無事件, 則睡眠在文件讀操作上, 時長由 timeoutMillis 決定
• 睡眠結(jié)束后調(diào)用 awoken 喚醒

好的, 至此線程是睡眠的機制也明了了, 這里通過 UML 圖總結(jié)一下, 線程消息隊列的創(chuàng)建與循環(huán)

四. 消息的發(fā)送與處理

我們都知道, Android 系統(tǒng)提供了 Handler 類, 描述一個消息的處理者, 它負責(zé)消息的發(fā)送與處理

public class Handler {final Looper mLooper;final MessageQueue mQueue;final Callback mCallback;public Handler() {this(null, false);}public Handler(Callback callback, boolean async) {// 調(diào)用該方法的線程的 LoopermLooper = Looper.myLooper();// 這里扔出了 Runtime 異常, 因此 Handler 是無法在沒有 Looper 的線程中執(zhí)行的if (mLooper == null) {throw new RuntimeException("Can't create handler inside thread " + Thread.currentThread()+ " that has not called Looper.prepare()");}// 獲取消息隊列mQueue = mLooper.mQueue;// 給 Callback 賦值mCallback = callback;......}public final boolean sendMessage(Message msg){......}public void handleMessage(Message msg) {}} 復(fù)制代碼

好的, 可以看到 Handler 的結(jié)構(gòu)如上述代碼所示, 本次只 focus 以下三個方法

• 構(gòu)造方法
  • 獲取當(dāng)前線程的 Looper
  • 獲取當(dāng)前線程的 MessageQueue
  • 給 Callback 賦值(這個 Callback 的作用, 在后面描述)
• 發(fā)送消息的方法
  • sendMessage
• 處理消息的方法
  • handleMessage

好的, 接下來我們先看看如何發(fā)送消息的

消息的發(fā)送

我們先看看, Android 中的消息是如何發(fā)送的

public class Handler {......public final boolean sendMessage(Message msg) {// 回調(diào)了發(fā)送延時消息的方法return sendMessageDelayed(msg, 0);}public final boolean sendMessageDelayed(Message msg, long delayMillis) {if (delayMillis < 0) {delayMillis = 0;}// 回調(diào)了發(fā)送指定時刻消息的方法return sendMessageAtTime(msg, /*指定時刻 = 當(dāng)前時刻 + 延時時間*/SystemClock.uptimeMillis() + delayMillis);}public boolean sendMessageAtTime(Message msg, long uptimeMillis) {MessageQueue queue = mQueue;......// 回調(diào)了入消息隊列的方法return enqueueMessage(queue, msg, uptimeMillis);}private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {// 將這個消息的處理者, 設(shè)置為其自身msg.target = this;......// 調(diào)用 MessageQueue 的 enqueueMessage 執(zhí)行入隊列的操作return queue.enqueueMessage(msg, uptimeMillis);} } 復(fù)制代碼

可以看到發(fā)送消息的操作, 進過了一系列方法的調(diào)用, 會走到 sendMessageAtTime 中, 表示發(fā)送指定時刻的消息, 然后會調(diào)用 enqueueMessage 執(zhí)行入消息隊列操作

• 將這個消息的 target 賦值為自身, 表示這個消息到時候會被當(dāng)前 Handler 對象執(zhí)行
• 調(diào)用了 MessageQueue.enqueueMessage 將消息投遞到消息隊列中去

接下來看看 MessageQueue.enqueueMessage 做了哪些操作

public final class MessageQueue {boolean enqueueMessage(Message msg, long when) {......synchronized (this) {......msg.when = when; // 將消息要執(zhí)行的時刻寫入成員變量Message p = mMessages; // 獲取當(dāng)前隊首的消息boolean needWake; // 描述是否要喚醒該 MessageQueue 所綁定的線程// Case1: // 1. p == null, 隊列為空// 2. 入隊列消息需要立即執(zhí)行// 3. 入隊列消息執(zhí)行的時間 早于 當(dāng)前隊首消息執(zhí)行的時間if (p == null || when == 0 || when < p.when) {// 將該消息放置到隊首msg.next = p;mMessages = msg;needWake = mBlocked; // 隊首元素變更了, 有可能需要立即執(zhí)行} else {// Case2: 入隊列的消息執(zhí)行時間 晚于 隊首消息執(zhí)行時間......// 將該消息插入到消息隊列合適的位置Message prev;for (;;) {prev = p;p = p.next;if (p == null || when < p.when) {break;}// 將 needWake 置為 false, 因為該消息插入到了后面, 因此不需要喚醒if (needWake && p.isAsynchronous()) {needWake = false;}}msg.next = p;prev.next = msg;}// 處理該消息隊列綁定線程的喚醒操作if (needWake) {nativeWake(mPtr);}}return true;}private native static void nativeWake(long ptr);} 復(fù)制代碼

可以看到 MessageQueue 在執(zhí)行消息入隊列時, 做了如下操作

• 隊列為空/入隊列消息需要立即執(zhí)行/入隊列消息執(zhí)行的時間早于當(dāng)前隊首消息執(zhí)行的時間 時
  • 將該消息插入到隊列的首部
  • 需要立即喚醒 MessageQueue 綁定的線程
• 入隊列的消息執(zhí)行時間 晚于 隊首消息執(zhí)行時間 時
  • 將該消息按照時間從早到晚的順序插入隊列
  • 不需要立即喚醒 MessageQueue 綁定的線程
• 根據(jù) flag 處理該消息隊列綁定線程的喚醒操作

消息入隊列的過程還是很清晰明了的, 從上一篇文章的分析中我們知道, 若 MessageQueue 在當(dāng)前時刻沒有要執(zhí)行的消息時, 會睡眠在 MessageQueue.next() 方法上, 接下來看看它是如何通過 nativeWake 喚醒的

// frameworks/base/core/jni/android_os_MessageQueue.cpp static void android_os_MessageQueue_nativeWake(JNIEnv* env, jclass clazz, jlong ptr) {NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);nativeMessageQueue->wake(); }void NativeMessageQueue::wake() {mLooper->wake(); }// system/core/libutils/Looper.cpp void Looper::wake() {// 向 Looper 綁定的線程 pipe 管道中寫入一個新的數(shù)據(jù)uint64_t inc = 1;ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));.... } 復(fù)制代碼

可以看到, nativeWake 是通過向 Looper 綁定的線程 pipe 管道中寫入一個新的數(shù)據(jù)的方式喚醒目標(biāo)線程的

• 通過上一篇的分析可知, 此時 Looper::pollInner 中 epoll 在讀操作上的睡眠便會停止

消息的處理

通過上一篇的分析可知, 當(dāng) MessageQueue.next 返回一個 Message 時, Looper 中的 loop 方法便會處理消息的執(zhí)行, 先回顧一下代碼

public final class Looper {public static void loop() {final Looper me = myLooper();......final MessageQueue queue = me.mQueue;for (;;) {Message msg = queue.next(); // might blockif (msg == null) {// 若取到的消息為 null, 這個 Looper 就結(jié)束了return;}......try {// 處理消息msg.target.dispatchMessage(msg);} finally {......}......}}} 復(fù)制代碼

好的, 可以看到當(dāng) MessageQueue.next 返回一個 Message 時, 便會調(diào)用 msg.target.dispatchMessage(msg) 去處理這個 msg

• msg.target 為一個 Handler 對象, 在上面的分析中可知, 在通過 Handler 發(fā)送消息的 enqueueMessage 方法中, 會將 msg.target 設(shè)置為當(dāng)前的 Handler
• 可以看到, 這個 msg 正是由將它投遞到消息隊列的 Handler 處理了, 它們是一一對應(yīng)的

接下來我們看看 Handler 處理消息的流程

public class Handler {public void dispatchMessage(Message msg) {// 1. 若 msg 對象中存在 callback, 則調(diào)用 handleCallbackif (msg.callback != null) {handleCallback(msg);} else {// 2. 若當(dāng)前 Handler 設(shè)值了 Callback, 進入這個分支if (mCallback != null) {// 2.1 若這個 Callback 的 handleMessage 返回 true, 則不會將消息繼續(xù)向下分發(fā)if (mCallback.handleMessage(msg)) {return;}}// 3. 若消息沒有被 mCallback 攔截, 則會調(diào)用 handleMessage 進行最后的處理handleMessage(msg);}} /*** 方式一: 優(yōu)先級最高*/private static void handleCallback(Message message) {message.callback.run();}public interface Callback {/*** 方式二: 優(yōu)先級次高* @return True if no further handling is desired*/public boolean handleMessage(Message msg);}public Handler(Callback callback, boolean async) {......// Callback 由構(gòu)造函數(shù)傳入mCallback = callback;......} /*** 方式三: 這個處理消息的方式, 由子類重寫, 優(yōu)先級最低*/public void handleMessage(Message msg) {}} 復(fù)制代碼

可以看到 Handler 的 dispatchMessage 處理消息主要有三種方式

• 若是 Message 對象內(nèi)部設(shè)置了 callback, 則調(diào)用 handleCallback 方法直接處理, 不會再往下分發(fā)
• 若 Handler 設(shè)置 Callback, 則會調(diào)用 Callback.handleMessage 方法
  • Callback.handleMessage 返回 false, 則會將消息處理繼續(xù)分發(fā)給 Handler.handleMessage

好的, 消息的發(fā)送和處理到這里就分析結(jié)束了, 最后再了解一下 MessageQueue 中空閑處理者的相關(guān)知識

空閑處理者的添加與處理

1. 什么是空閑處理者

通過上一篇文章的分析可知 MessageQueue 通過 next 方法通過死循環(huán)獲取下一個要處理的 Message, 若當(dāng)前時刻不存在要處理的消息, 下次循環(huán)會進行睡眠操作

• 在沒有取到可執(zhí)行消息 ---> 下次 for 循環(huán)進行睡眠 之間的時間間隔, 稱之為空閑時間
• 在空閑時間處理事務(wù)的對象, 稱之為空閑處理者

public final class MessageQueue {Message next() {for (;;) {// 睡眠操作nativePollOnce(ptr, nextPollTimeoutMillis);synchronized (this) {Message prevMsg = null;Message msg = mMessages;......if (msg != null) {// ...... return msg;}// 空閑時間....... }// 空閑時間......}}} 復(fù)制代碼

2. 空閑處理者的添加

public final class MessageQueue {public static interface IdleHandler {/*** 處理空閑消息*/boolean queueIdle();}// 空閑消息集合private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>();public void addIdleHandler(@NonNull IdleHandler handler) {synchronized (this) {mIdleHandlers.add(handler);}}} 復(fù)制代碼

通過上述代碼可以得到以下的信息

• 空閑處理者使用 IdleHandler 接口描述
• 空閑處理者通過 MessageQueue.addIdleHandler() 添加
• 空閑處理者使用 MessageQueue.mIdleHandlers 維護

好的, 結(jié)下來看看處理細節(jié)

3. 空閑消息的處理

public final class MessageQueue {// 空閑消息集合private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>();// 空閑消息處理者的數(shù)組private IdleHandler[] mPendingIdleHandlers;Message next() {...... for (;;) {......synchronized (this) {// 省略獲取 msg 的代碼......// 1. 從空閑消息集合 mIdleHandlers 中獲取 空閑處理者 數(shù)量if (pendingIdleHandlerCount < 0&& (mMessages == null || now < mMessages.when)) {pendingIdleHandlerCount = mIdleHandlers.size();}// 2 若無空閑處理者, 則進行下一次 for 循環(huán)if (pendingIdleHandlerCount <= 0) {mBlocked = true;continue;}......// 3. 將空閑消息處理者集合轉(zhuǎn)為數(shù)組mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);}// 4. 處理空閑消息for (int i = 0; i < pendingIdleHandlerCount; i++) {final IdleHandler idler = mPendingIdleHandlers[i];// 獲取第 i 給位置的空閑處理者mPendingIdleHandlers[i] = null; // 置空boolean keep = false; try {// 4.1 處理空閑消息keep = idler.queueIdle(); } catch (Throwable t) {......}if (!keep) {synchronized (this) {// 4.2 走到這里表示它是一次性的處理者, 從 mIdleHandlers 移除mIdleHandlers.remove(idler);}}}......}}} 復(fù)制代碼

好的, 可以看到 MessageQueue.next 在獲取不到 msg 時, 會進行一些空閑消息的處理

• 從空閑消息集合 mIdleHandlers 中獲取 空閑處理者 數(shù)量
• 若無空閑處理者, 則進行下一次 for 循環(huán)
• 若存在空閑處理者, 則空閑消息處理者集合轉(zhuǎn)為數(shù)組 mPendingIdleHandlers
• for 循環(huán)處理空閑消息
  • 調(diào)用 IdleHandler.queueIdle 處理空閑消息
    • 返回 true, 下次再 MessageQueue.next 獲取不到 msg 的空閑時間會繼續(xù)處理
    • 返回 false 表示它是一次性的處理者, 從 mIdleHandlers 移除

總結(jié)

至此 Android 的消息機制就全部結(jié)束了, 此前分析過消息機制, 但一直沒有深度到 Native 層, 只是浮于表面, 本次深入到了 Native 層, 看到了更底層的 epoll 監(jiān)控管道相關(guān)的知識, 可以說發(fā)現(xiàn)了新的天地, 對 Handler 的機制有了更加深刻的理解, 本文中有分析的不正確或者不到位的地方, 希望大家多多批評指出, 筆者希望與大家共同成長。

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

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

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