Android 訊息機制詳解(Android P)

訊息系統安卓開發 · 發表 2019-01-31 10:05:42

摘要：前言 Android 訊息機制，一直都是 Android 應用框架層非常重要的一部分，想更加優雅的進行 Android 開發，我想了解訊息機制是非常必要的一個過程，此前也分析過很多次 Handler 訊息機制，不過都是浮於 Java 層，對於底層的原始碼並沒有深究，經過一年的努力，筆者對...

前言

Android 訊息機制，一直都是 Android 應用框架層非常重要的一部分，想更加優雅的進行 Android 開發，我想了解訊息機制是非常必要的一個過程，此前也分析過很多次 Handler 訊息機制，不過都是浮於 Java 層，對於底層的原始碼並沒有深究，經過一年的努力，筆者對於 Android 應用框架層有了新的認識和理解，這裡重新寫下這篇文章。

本文主要從以下幾點來闡述 Androd 訊息機制

執行緒訊息佇列的建立入口
訊息迴圈的準備
訊息迴圈的啟動
訊息的傳送與處理

一. 執行緒訊息佇列建立入口

我們知道, 應用程序主執行緒初始化的入口是在 ActivityThread.main() 中, 我們看看他是如何構建訊息佇列的

public class ActivityThread {

static volatile Handler sMainThreadHandler;// set once in main()

public static void main(String[] args) {
......
// 1. 做一些主執行緒訊息迴圈的初始操作
Looper.prepareMainLooper();

......

// 2. 啟動訊息迴圈
Looper.loop();
}

}

好的, 可以看到 ActivityThread 中的訊息迴圈構建過程如下

呼叫 Looper.prepareMainLooper, 做一些準備操作
呼叫 Looper.loop 真正的開啟了訊息迴圈

接下來我們先看看準備操作中做了些什麼

二. 訊息迴圈的準備

public final class Looper {

private static Looper sMainLooper;// guarded by Looper.class

public static void prepareMainLooper() {
// 1. 呼叫 prepare 方法真正執行主執行緒的準備操作
prepare(false);

synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
// 2. 呼叫了 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) {
// 建立了一個訊息佇列
mQueue = new MessageQueue(quitAllowed);
// 獲取了當前的執行緒
mThread = Thread.currentThread();
}

}

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

呼叫 prepare 方法真正執行主執行緒的準備操作
- 建立了一個 Looper 物件
  - 建立了 MessageQueue 這個訊息佇列, 儲存到成員變數 mQueue 中
  - 獲取該物件建立執行緒, 儲存到成員變數 mThread 中
- 將這個 Looper 物件存入 ThreadLocal 中
呼叫 myLooper 方法, 從 ThreadLocal 中獲取剛剛寫入的 Looper 物件
將這個 Looper 物件, 儲存到靜態變數 sMainLooper 中, 表示這個是當前應用程序主執行緒的 Looper 物件

好的, 可以看到在建立 Looper 物件的時候, 同時會建立一個 MessageQueue 物件, 將它儲存到 Looper 物件的成員變數 mQueue 中, 因此每一個 Looper 物件都對應一個 MessageQueue 物件

我們接下來看看 MessageQueue 物件建立時, 做了哪些操作

MessageQueue 的建立

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

}

好的, 可以看到 MessageQueue 物件在建立的過程中, 會呼叫 nativeInit 來獲取一個 native 的控制代碼, 我們看看這個 nativeInit 做了哪些操作

// frameworks/base/core/jni/android_os_MessageQueue.cpp
static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
// 1. 建立了一個 NativeMessageQueue 物件
NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
......
// 增加 env 對它的強引用計數
nativeMessageQueue->incStrong(env);
// 2. 將這個 NativeMessageQueue 物件強轉成了一個控制代碼返回 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 嘗試呼叫 Looper.getForThread 獲取一個 C++ 的 Looper 物件
mLooper = Looper::getForThread();
// 1.2 若當前執行緒沒有建立過 Looper, 則走這個分支
if (mLooper == NULL) {
// 建立 Looper 物件
mLooper = new Looper(false);
// 給當前執行緒繫結這個 Looper 物件
Looper::setForThread(mLooper);
}
}

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

建立了一個 C++ 的 NativeMessageQueue 物件
- 嘗試通過 Looper.getForThread 獲取一個 C++ 的 Looper 物件
- 若當前執行緒沒有建立過 Looper
  - new 一個 C++ 的 Looper 物件
  - 給當前執行緒繫結 Looper 物件

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

Java 是先建立 Looper, 然後在 Looper 內部建立 MessageQueue
Native 是先建立 NativeMessageQueue, 在其建立的過程中建立 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. 建立 pipe 管道, 返回該管道檔案讀寫的描述符
mWakeEventFd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
AutoMutex _l(mLock);
// 處理 epoll 相關事宜
rebuildEpollLocked();
}

void Looper::rebuildEpollLocked() {
......
// 2. 建立一個 epoll 物件, 將其檔案描述符儲存在成員變數 mEpollFd 中
mEpollFd = epoll_create(EPOLL_SIZE_HINT);
// 3. 將 pipe 管道的檔案讀寫描述符 mWakeEventFd, 新增到 epoll 中, 讓 epoll 對該管道的讀寫進行監聽
struct epoll_event eventItem;
memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
eventItem.events = EPOLLIN;
eventItem.data.fd = mWakeEventFd;
int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeEventFd, & eventItem);
......
}

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

呼叫 eventfd 建立了一個 pipe 管道, 返回了該管道的檔案讀寫描述符
建立了一個 epoll 物件
將 pipe 管道的檔案讀寫描述符 mWakeEventFd, 新增到 epoll 中, 讓 epoll 對該管道的讀寫進行監聽

可以看到這裡引入了兩個新的名詞, pipe 管道 和 管道監聽管理物件 epoll

pipe 管道: 這個管道在一個執行緒的訊息迴圈過程中起到的作用非常大
- 當一個執行緒沒有新的訊息需要處理時, 它就會睡眠在這個管道的讀端檔案描述符上 , 直到有新的訊息需要處理為止
- 當其他執行緒向這個執行緒傳送了一個訊息之後, 其他執行緒就會通過這個管道的寫端檔案描述符寫入一個數據, 從而將這個執行緒喚醒 , 以便它可以對剛才傳送到它訊息佇列中的訊息進行處理
epoll: epoll 機制是 Linux 為了同時監聽多個檔案描述符的 IO 讀寫事件而設計的 多路複用 IO 介面
- 當 epoll 監聽了大量檔案描述符的 IO 讀寫事件, 但只有少量的檔案描述符是活躍的, 那麼這個 epoll 會顯著的減少 CPU 的使用率

相互依賴的結構圖

到這裡訊息迴圈的準備工作就已經完成了, 這裡分析一下它們的結構圖

訊息迴圈相互依賴關係圖

三. 訊息迴圈的啟動

public final class Looper {

public static void loop() {
// 1. 獲取呼叫執行緒的 Looper 物件
final Looper me = myLooper();
......
// 2. 獲取 Looper 對應的訊息佇列
final MessageQueue queue = me.mQueue;
// 3. 死迴圈, 不斷的處理訊息佇列中的訊息
for (;;) {
// 3.1 獲取訊息佇列中的訊息, 取不到訊息會阻塞
Message msg = queue.next(); // might block
if (msg == null) {
// 若取到的訊息為 null, 這個 Looper 就結束了
return;
}
......
try {
// 3.2 處理訊息
msg.target.dispatchMessage(msg);
} finally {
......
}
......
}
}

}

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

從方法呼叫的執行緒中取 Looper 物件
獲取這個 Looper 對應的訊息佇列
通過死迴圈, 不斷地處理訊息佇列中的資料
- 通過 MessageQueue.next() 獲取下一條要處理的 Msg
- 通過 msg.target.dispatchMessage(msg); 分發處理訊息(本次不細究)

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

從佇列中取訊息

public final class MessageQueue {

Message next() {
// 獲取 NativeMessageQueue 的控制代碼
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
// 描述空閒事件處理者的數量, 初始值為 -1 
int pendingIdleHandlerCount = -1; 
// 描述當前執行緒沒有新訊息處理時, 可睡眠的時間
int nextPollTimeoutMillis = 0;
// 死迴圈, 獲取可執行的 Message 物件
for (;;) {
// 1. 若 nextPollTimeoutMillis 不為 0, 則說明距離下一個 Message 執行, 有一定的時間間隔
if (nextPollTimeoutMillis != 0) {
// 在空閒期間, 執行 Binder 通訊相關的指令
Binder.flushPendingCommands();
}
// 2. 這裡呼叫了 nativePollOnce, 在 native 層檢查訊息佇列中是否有 msg 可讀, 若無可執行的 msg, 則執行執行緒的睡眠, 時間由 nextPollTimeoutMillis 決定
nativePollOnce(ptr, nextPollTimeoutMillis);
// 3. 取佇列中下一條要執行的 Message 物件, 並返回出去
synchronized (this) {
final long now = SystemClock.uptimeMillis(); // 獲取當前時刻
Message prevMsg = null;
Message msg = mMessages;
// 3.1 移除訊息佇列中無效的 Message 
// Condition: msg 不為 null & msg 的處理者為 null
if (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 若當前的時刻 早於 隊首訊息要執行的時刻
if (now < msg.when) {
// 給 nextPollTimeoutMillis 賦值, 表示當前執行緒, 可睡眠的時間
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// 3.2.2 若當前的時刻 不小於 隊首訊息要執行的時刻
mBlocked = false;// 更改標記位置
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 迴圈
if (pendingIdleHandlerCount <= 0) {
mBlocked = true;
continue;
}
.......
}

// 4.1 處理空閒事件
......

// 4.2 走到這裡, 說明所有的空閒事件都已經處理好了
// 將需要處理的空閒事件,置為 0 
pendingIdleHandlerCount = 0;

// 5. 因為處理空閒事件是耗時操作, 期間可能有新的 Message 入佇列, 因此將可睡眠時長置為 0, 表示需要再次檢查
nextPollTimeoutMillis = 0;
}
}

// native 方法
private native void nativePollOnce(long ptr, int timeoutMillis); /*non-static for callbacks*/
 
}

可以看到 MessageQueue.next 內部維護了一個死迴圈, 用於獲取下一條 msg, 這個 for 迴圈做了如下的操作

若 nextPollTimeoutMillis 不為 0, 則說明距離下一個 Message 執行, 有一定的時間間隔
- 在空閒期間, 執行 Binder 通訊相關的指令
呼叫 nativePollOnce 根據 nextPollTimeoutMillis 時長, 執行當前執行緒的睡眠操作
取佇列中下一條要執行的 Message
- 移除訊息佇列中無效的 Message
- 佇列首部存在有效的 msg
  - 若當前的時刻 < 隊首訊息要執行的時刻
    - 則更新 nextPollTimeoutMillis, 下次進行 for 迴圈時, 會進行睡眠操作
  - 若當前的時刻 >= 隊首訊息要執行的時刻
    - 則將隊首訊息的描述返回出去
- 佇列首部不存在有效的 msg
  - 將 nextPollTimeoutMillis 置為 -1, 下次 for 迴圈時可以無限睡眠, 直至訊息佇列中有訊息可讀
空閒訊息的獲取和處理 (本次不細究)
- 獲取空閒事件的處理者
- 若無空閒事件, 則進行下一次 for 迴圈
- 若存在空閒事件, 則處理空閒事件
  - 將 pendingIdleHandlerCount 置為 0, 表示空閒事件都已經處理完成了
  - 將 nextPollTimeoutMillis 置為 0, 因為處理空閒事件是耗時操作, 期間可能有新的 Message 入佇列, 因此將可睡眠時長置為 0, 表示需要再次檢查

至此一次 for 迴圈就結束了, 可以看到 Message.next() 中其他的邏輯都非常的清晰, 但其睡眠是一個 native 方法, 我們繼續看看它的內部實現

訊息佇列中無訊息時執行緒睡眠的實現

// 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);
// 呼叫了 NativeMessageQueue 的 pollOnce
nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}

void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
......
// 1. 呼叫了 Looper 的 pollOne
mLooper->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. 若未讀到訊息, 則呼叫 pollInner
result = pollInner(timeoutMillis);
}
}


int Looper::pollInner(int timeoutMillis) {
......
int result = POLL_WAKE;
......
struct epoll_event eventItems[EPOLL_MAX_EVENTS];
// 3. 呼叫 epoll_wait 來監聽 pipe 中的 IO 事件, 若無事件, 則睡眠在檔案讀操作上, 時長由 timeoutMillis 決定
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
// 4. 走到這裡, 說明睡眠結束了
for (int i = 0; i < eventCount; i++) {
int fd = eventItems[i].data.fd;// 獲取檔案描述
uint32_t epollEvents = eventItems[i].events;
// 5. 若為喚醒事件的檔案描述, 則執行喚醒操作
if (fd == mWakeEventFd) {
if (epollEvents & EPOLLIN) {
awoken();// 喚醒
} else {
......
}
} else {
......
}
}
......
return result;
}

好的可以看到 JNI 方法 nativePollOnce, 其內部流程如下

將 Poll 操作轉發給了 Looper.pollOne
若未讀到訊息, 則呼叫 Looper.pollInner
呼叫 epoll_wait 來監聽 pipe 中的 IO 事件, 若無事件, 則睡眠在檔案讀操作上 , 時長由 timeoutMillis 決定
睡眠結束後呼叫 awoken 喚醒

好的, 至此執行緒是睡眠的機制也明瞭了, 這裡通過 UML 圖總結一下, 執行緒訊息佇列的建立與迴圈

執行緒訊息的建立與迴圈的流程圖

四. 訊息的傳送與處理

我們都知道, Android 系統提供了 Handler 類, 描述一個訊息的處理者, 它 負責訊息的傳送與處理

public class Handler {

final Looper mLooper;
final MessageQueue mQueue;
final Callback mCallback;

public Handler() {
this(null, false);
}

public Handler(Callback callback, boolean async) {
// 呼叫該方法的執行緒的 Looper
mLooper = Looper.myLooper();
// 這裡扔出了 Runtime 異常, 因此 Handler 是無法在沒有 Looper 的執行緒中執行的
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) {

}

}

好的, 可以看到 Handler 的結構如上述程式碼所示, 本次只 focus 以下三個方法

構造方法
- 獲取當前執行緒的 Looper
- 獲取當前執行緒的 MessageQueue
- 給 Callback 賦值(這個 Callback 的作用, 在後面描述)
傳送訊息的方法
- sendMessage
處理訊息的方法
- handleMessage

好的, 接下來我們先看看如何傳送訊息的

訊息的傳送

我們先看看, Android 中的訊息是如何傳送的

public class Handler {

......
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;
......
// 回調了入訊息佇列的方法
return enqueueMessage(queue, msg, uptimeMillis);
}

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
// 將這個訊息的處理者, 設定為其自身
msg.target = this;
......
// 呼叫 MessageQueue 的 enqueueMessage 執行入佇列的操作
return queue.enqueueMessage(msg, uptimeMillis);
}
}

可以看到傳送訊息的操作, 進過了一系列方法的呼叫, 會走到 sendMessageAtTime 中, 表示 傳送指定時刻的訊息 , 然後會呼叫 enqueueMessage 執行入訊息佇列操作

將這個訊息的 target 賦值為自身, 表示這個訊息到時候會被當前 Handler 物件執行
呼叫了 MessageQueue.enqueueMessage 將訊息投遞到訊息佇列中去

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

public final class MessageQueue {

boolean enqueueMessage(Message msg, long when) {
......
synchronized (this) {
......
msg.when = when;// 將訊息要執行的時刻寫入成員變數
Message p = mMessages;// 獲取當前隊首的訊息
boolean needWake;// 描述是否要喚醒該 MessageQueue 所繫結的執行緒
// Case1: 
// 1. p == null, 佇列為空
// 2. 入佇列訊息需要立即執行
// 3. 入佇列訊息執行的時間 早於 當前隊首訊息執行的時間
if (p == null || when == 0 || when < p.when) {
// 將該訊息放置到隊首
msg.next = p;
mMessages = msg;
needWake = mBlocked;// 隊首元素變更了, 有可能需要立即執行
} else {
// Case2: 入佇列的訊息執行時間 晚於 隊首訊息執行時間
......
// 將該訊息插入到訊息佇列合適的位置
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);

}

可以看到 MessageQueue 在執行訊息入佇列時, 做了如下操作

佇列為空/入佇列訊息需要立即執行/入佇列訊息執行的時間早於當前隊首訊息執行的時間時
- 將該訊息插入到佇列的首部
- 需要立即喚醒 MessageQueue 繫結的執行緒
入佇列的訊息執行時間晚於隊首訊息執行時間 時
- 將該訊息按照時間從早到晚的順序插入佇列
- 不需要立即喚醒 MessageQueue 繫結的執行緒
根據 flag 處理該訊息佇列繫結執行緒的喚醒操作

訊息入佇列的過程還是很清晰明瞭的, 從上一篇文章的分析中我們知道, 若 MessageQueue 在當前時刻沒有要執行的訊息時, 會睡眠在 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 管道中寫入一個新的資料
uint64_t inc = 1;
ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));
....
}

可以看到, nativeWake 是通過向 Looper 繫結的執行緒 pipe 管道中寫入一個新的資料的方式喚醒目標執行緒的

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

訊息的處理

通過上一篇的分析可知, 當 MessageQueue.next 返回一個 Message 時, Looper 中的 loop 方法便會處理訊息的執行, 先回顧一下程式碼

public final class Looper {

public static void loop() {
final Looper me = myLooper();
......
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// 若取到的訊息為 null, 這個 Looper 就結束了
return;
}
......
try {
// 處理訊息
msg.target.dispatchMessage(msg);
} finally {
......
}
......
}
}

}

好的, 可以看到當 MessageQueue.next 返回一個 Message 時, 便會呼叫 msg.target.dispatchMessage(msg) 去處理這個 msg

msg.target 為一個 Handler 物件, 在上面的分析中可知, 在通過 Handler 傳送訊息的 enqueueMessage 方法中, 會將 msg.target 設定為當前的 Handler
可以看到, 這個 msg 正是由將它投遞到訊息佇列的 Handler 處理了, 它們是一一對應的

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

public class Handler {

public void dispatchMessage(Message msg) {
// 1. 若 msg 物件中存在 callback, 則呼叫 handleCallback
if (msg.callback != null) {
handleCallback(msg);
} else {
// 2. 若當前 Handler 設值了 Callback, 進入這個分支
if (mCallback != null) {
// 2.1 若這個 Callback 的 handleMessage 返回 true, 則不會將訊息繼續向下分發
if (mCallback.handleMessage(msg)) {
return;
}
}
// 3. 若訊息沒有被 mCallback 攔截, 則會呼叫 handleMessage 進行最後的處理
handleMessage(msg);
}
} 

/**
* 方式一: 優先順序最高
*/
private static void handleCallback(Message message) {
message.callback.run();
}

public interface Callback {
/**
* 方式二: 優先順序次高
* @return True if no further handling is desired
*/
public boolean handleMessage(Message msg);
}

public Handler(Callback callback, boolean async) {
......
// Callback 由建構函式傳入
mCallback = callback;
......
} 

/**
* 方式三: 這個處理訊息的方式, 由子類重寫, 優先順序最低
*/
public void handleMessage(Message msg) {

}

 }

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

若是 Message 物件內部設定了 callback, 則 呼叫 handleCallback 方法直接處理, 不會再往下分發
若 Handler 設定 Callback, 則會 呼叫 Callback.handleMessage 方法
- Callback.handleMessage 返回 false, 則會將訊息處理繼續分發給 Handler.handleMessage

好的, 訊息的傳送和處理到這裡就分析結束了, 最後再瞭解一下 MessageQueue 中空閒處理者的相關知識

空閒處理者的新增與處理

1. 什麼是空閒處理者

通過上一篇文章的分析可知 MessageQueue 通過 next 方法通過死迴圈獲取下一個要處理的 Message, 若當前時刻不存在要處理的訊息, 下次迴圈會進行睡眠操作

在沒有取到可執行訊息 ---> 下次 for 迴圈進行睡眠 之間的時間間隔, 稱之為 空閒時間
在空閒時間處理事務的物件, 稱之為空閒處理者

public final class MessageQueue {

Message next() {
for (;;) {
// 睡眠操作
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
Message prevMsg = null;
Message msg = mMessages;
......
if (msg != null) {
// ...... 
return msg;
}

// 空閒時間
....... 
}

// 空閒時間
......

}
}

}

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

}

通過上述程式碼可以得到以下的資訊

空閒處理者使用 IdleHandler 介面描述
空閒處理者通過 MessageQueue.addIdleHandler() 新增
空閒處理者使用 MessageQueue.mIdleHandlers 維護

好的, 結下來看看處理細節

3. 空閒訊息的處理

public final class MessageQueue {

// 空閒訊息集合
private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>();
// 空閒訊息處理者的陣列
private IdleHandler[] mPendingIdleHandlers;

Message next() {
...... 
for (;;) {
......
synchronized (this) {
// 省略獲取 msg 的程式碼
......
// 1. 從空閒訊息集合 mIdleHandlers 中獲取 空閒處理者 數量
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
// 2 若無空閒處理者, 則進行下一次 for 迴圈
if (pendingIdleHandlerCount <= 0) {
mBlocked = true;
continue;
}
......
// 3. 將空閒訊息處理者集合轉為陣列
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);
}
}
}
......
}
}

}

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

從空閒訊息集合 mIdleHandlers 中獲取空閒處理者數量
若無空閒處理者, 則進行下一次 for 迴圈
若存在空閒處理者, 則空閒訊息處理者集合轉為陣列 mPendingIdleHandlers
for 迴圈處理空閒訊息
- 呼叫 IdleHandler.queueIdle 處理空閒訊息
  - 返回 true, 下次再 MessageQueue.next 獲取不到 msg 的空閒時間會繼續處理
  - 返回 false 表示它是一次性的處理者, 從 mIdleHandlers 移除

總結

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