由Handler、MessageQueue、Looper構成的線程消息通信機制在Android開發中非常常用，不過大部分人都只粗淺地看了Java層的實現，對其中的細節不甚了了，這篇博文將研究Android消息機制從Java層到Native層的實現。
消息機制由于更貼近抽象設計，所以整個結構更簡單，只包含了消息的產生、分發，不像Input子系統那樣還有歸類、過濾等環節。整體的結構如下圖：
Android Java層消息機制
消息的產生
在Java層中消息的產生都來源于用戶創建的Message對象，經過封裝的Runnable對象，或調用obtainMessage從Message Pool中獲得，Message Pool指的是Message類內的Message循環隊列，隊頭是靜態的Message對象sPool，該隊列最大容納MAX_POOL_SIZE（50）個Message：
MessagePool對Message的復用節省了不斷創建Message帶來的開銷，如果當前50個Message都已經被用過，由于MessagePool是循環隊列，則會回到隊頭并請空該Message，向下復用。
BlockingRunnable
看Java層Handler的源碼的時候發現了一個奇怪的東西：BlockingRunnable，基本上沒有用過的東西，也沒看別人講過，于是我就來鉆研一下吧：
private static final class BlockingRunnable implements Runnable {
private final Runnable mTask;
private boolean mDone;
public BlockingRunnable(Runnable task) {
mTask = task;
}
@Override
public void run() {
try {
mTask.run();
} finally {
synchronized (this) {
mDone = true;
notifyAll();
}
}
}
public boolean postAndWait(Handler handler, long timeout) {
if (!handler.post(this)) {
return false;
}
synchronized (this) {
if (timeout > 0) {
final long expirationTime = SystemClock.uptimeMillis() + timeout;
while (!mDone) {
long delay = expirationTime - SystemClock.uptimeMillis();
if (delay <= 0) {
return false; // timeout
}
try {
wait(delay);
} catch (InterruptedException ex) {
}
}
} else {
while (!mDone) {
try {
wait();
} catch (InterruptedException ex) {
}
}
}
}
return true;
}
}
我們可以看到，BlockingRunnable是一個“包裹”構造方法中傳入的Runnable的Runnable，調用BlockingRunnable的postAndWait會做以下事情：
- 如果投遞BlockingRunnable失敗，返回false
- 鎖住投遞BlockingRunnable的線程
- 如果timeout大于0，計算參數Runnable的到期時間，只要參數Runnable還沒處理完，則一直輪詢還剩多少時間，并調用wait(delay)讓投遞BlockingRunnable的線程繼續等待，直參數Runnable處理完（mDone為true）這個過程才結束
- 如果timeout小于等于0，而且參數Runnable還沒處理完，則一直等待直到參數Runnable處理完（mDone為true）
這個東西的說明書和使用風險可以在runWithScissors方法的注釋里看到，我在這里就不當翻譯工了。
消息的投遞和處理
得到Message后，就會通過Handler的sendMessageAtTime調用MessageQueue的enqueueMessage將Message投遞到MessageQueue中，在往下學習之前必須先了解Handler的創建，因為后面的知識和它有關聯。
Handler的創建和初始化
其實Handler的初始化沒什么好看的，就是保存Callback、mLooper的MessageQueue的引用，以及聲明Handler是否異步投遞所有Message。但是里面有一個內存泄露的檢查，可以學習一下，就是如果打開了FIND_POTENTIAL_LEAKS，就會進行內存泄露的檢查，它會做以下事情：
- 獲取當前Handler類
- 如果Handler是匿名內部類，或成員類，或局部類，且Handler的修飾符不是static
- 那么就會打出log提示可能會發生內存泄露
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
}
}
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
既然Handler的創建這么簡單，為什么說后面要學習的內容和它相關呢？原因就出在Looper中，我們可以看到Looper是通過sThreadLocal返回的，這個ThreadLocal是什么呢？
ThreadLocal - 維持線程內對象的唯一性
ThreadLocal是一個關于創建線程局部變量的類。
通常情況下，我們創建的變量是可以被任何一個線程訪問并修改的。而使用ThreadLocal創建的變量只能被當前線程訪問，其他線程則無法訪問和修改。它的實現原理如下：
如圖所示，ThreadLocalRef其實是同一個ThreadLocal對象的引用，為了不讓線看起來很亂我分別用了兩個方塊表示ThreadLocal對象，但其實是同一個對象。ThreadLocal同時是ThreadA、ThreadB甚至ThreadN內ThreadLocalMap的Key，但取出來的對象時不一樣的，因為Map不一樣對應的鍵值對也不一樣嘛。
ThreadLocalMap
ThreadLocalMap是僅用于維護ThreadLocal值的自定義HashMap，只在Thread類內使用。為了避免ThreadLocalMap的Key->ThreadLocal在GC時無法被回收，里邊的元素都是用WeakReference封裝的。ThreadLocalMap除了這點以外，沒有什么特別的，就不細講了。
需要注意的一點是：ThreadLocalMap是可能帶來內存泄露的，但root cause不是ThreadLocalMap本身，而是代碼質量不夠高。首先，由于作為Map的Key的ThreadLocal是弱引用，那么GC時ThreadLocal會被回收，此時Map內存在一對Key為null的鍵值對，而Value仍然被線程強引用著，那么如果用完ThreadLocal后不主動移除，就會內存泄露了。但事實上，ThreadLocal用完后主動調remove就能規避這個問題，本來也該這樣做。
Entry
Entry作為ThreadLocalMap的元素，表示的是一對鍵值對：ThreadLocal的弱引用為鍵，將要用ThreadLocal存儲的對象為值。
static class Entry extends WeakReference<ThreadLocal> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
ThreadLocal總結
換句話說，所謂的不可被其他線程修改的局部變量，表示的是：每個線程中都會維護一個ThreadLocalMap，里邊以ThreadLocal為鍵，對應的局部變量為值，通過鍵值對來控制訪問和數據的一致性，而不是通過鎖來控制。
Looper
既然一個線程只有一個Looper，那么Looper里面有什么呢？從源碼可以看到，Looper的構造方法是私有的，也就意味著獲得Looper對象基本都是單例，這一點和線程<->Looper的一對一映射關系切合。
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
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的成員變量我們可以知道Looper包含了以下東西：
- sMainLooper：應用主線程的Looper，創建其他線程的Looper時為null
- mQueue：Looper關聯的MessageQueue
- mThread：Looper關聯的線程
- sThreadLocal：線程局部變量的Key
從這可以知道，一個線程對應一個Looper，一個Looper對應一個MessageQueue
----------------分割線，接下來回到消息的投遞結束的地方----------------
得到Message后，就會通過Handler的sendMessageAtTime調用MessageQueue的enqueueMessage將Message投遞到MessageQueue中，在往下學習之前必須先了解Handler的創建，因為后面的知識和它有關聯。
現在我們知道Message將要投遞到哪里的MessageQueue里了，那么投遞過去之后，消息是怎么被處理的呢？這代碼很長，而且就是個進入隊列的過程，我就不貼了，做了以下事情：
- 合法性檢查
- 標記Message正在使用
- 入列
- 喚醒native的MessageQueue
在這里有個有意思的概念必須提一下，就是Barrier Message，它表示的是一種柵欄的概念，將它加入MessageQueue可以攔住所有執行時間在它之后的同步Message，異步Message則不受影響，遍歷到就會處理，這種狀況會持續到把Barrier Message移除。
提示：圖里綠色代表Message可以被取出執行，紅色表示無法被取出執行
它和Message的根本差別是，他沒有target，即:沒有處理該Message的Handler，但我們自己將Message的Handler設為null是沒法加入MessageQueue的，必須調用postSyncBarrier方法：
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
……
}
private int postSyncBarrier(long when) {
// Enqueue a new sync barrier token.
// We don't need to wake the queue because the purpose of a barrier is to stall it.
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.markInUse();
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) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
return token;
}
}
消息的分發
前面已經知道Message投遞后就會到達MessageQueue，接下來就看消息是怎么被遍歷處理的。首先要知道的一點是，Looper在調用prepare創建后，是必須調loop()方法的，很多人會問，我平常用的時候沒用loop()方法也沒問題啊。那是因為你是在主線程用的，主線程在創建Looper的時候已經調用過loop()方法了。
我們創建了其他線程的Looper后，調loop()方法會做以下事情：
- 循環獲取MessageQueue中的Message
- 將Message通過Handler的dispatchMessage方法分發到對應的Handler中
- 將Message的信息清空，回收到Message Pool中等待下一次使用
public static void loop() {
……
for (;;) {
Message msg = queue.next(); // might block
……
try {
msg.target.dispatchMessage(msg);
} finally {
……
}
……
msg.recycleUnchecked();
}
}
在Handler的dispatchMessage中，對Message的處理其實是有優先順序這個說法的：
- 如果Message設置了callback，則將Message交給Message的callback處理
- 如果Handler設置了callback，則將Message先交給Handler的callback處理
- 否則的話，將Message交給Handler的handleMessage處理
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
對于MessageQueue，它實際表示了Java層和Native層的MessageQueue，Java層的MessageQueue就是mMessages表示的循環隊列，Native層的MessageQueue就是mPtr。它的next()方法里做的事情如下：
- 調用nativePollOnce讓native層的MessageQueue先處理Native層的Message，再處理Java層的Message，這個過程可能阻塞
- 如果在按時序遍歷MessageQueue的過程中發現了Barrier Message，即handler為空的Message，則跳過它后面的所有同步Message，只處理異步Message
- 如果消息是延時消息，計算當前時間和目標時間的差值，休眠這個時間差后再去取這個Message
- 如果消息不是延時消息，在Message Pool里標記該Message正在使用，并返回它
Java層Android消息機制的整個過程可以用下圖概括：
有鉆研過Java層代碼的朋友肯定知道，Handler里面還有個用于跨進程Message通信的MessengerImpl，這個東西我就不在這里說了，因為它就是個簡單的跨進程通信，和整個Handler、Looper、MessageQueue其實關系不大。
Android Native層消息機制
Android消息機制在Native層其實和Java層很相似，保留了Handler、Looper、MessageQueue的結構。但是Native層Message、Handler、MessageQueue的概念被弱化得很厲害，基本上只是個“空殼”，核心邏輯都在Looper里邊了。
其他區別都不大了，只是在實現上有一點不一樣，具體的差別就在源碼中找答案吧。整體結構圖如下：
消息的產生
在Native層中，消息由MessageEnvelope和封裝fd（Java層Handler可以添加fd的監聽、Native當然也可以）相關信息后得到的epoll_event組成。
fd
對于要被監聽的fd的消息，Looper做了以下事情：
- 合法性檢查
- 將相關信息封裝到Request中，并初始化為epoll_event
- 將該fd以及要監聽的epoll_event事件（步驟2轉換Request得到）注冊到當前Looper的epollFd中
- 如果出錯，進行出錯處理
- 更新mRequests
int Looper::addFd(int fd, int ident, int events, const sp<LooperCallback>& callback, void* data) {
……
{ // acquire lock
AutoMutex _l(mLock);
……
struct epoll_event eventItem;
request.initEventItem(&eventItem);
ssize_t requestIndex = mRequests.indexOfKey(fd);
if (requestIndex < 0) {
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, & eventItem);
……
mRequests.add(fd, request);
} else {
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_MOD, fd, & eventItem);
……
mRequests.replaceValueAt(requestIndex, request);
}
} // release lock
return 1;
}
MessageEnvelope
MessageEnvelope相對于fd就簡單多了，在調用Native層Looper的sendMessage相關函數時會將uptime、MessageHandler、Native層Message封裝到MessageEnvelope中，然后插入mMessageEnvelopes中。
void Looper::sendMessageAtTime(nsecs_t uptime, const sp<MessageHandler>& handler, const Message& message) {
……
size_t i = 0;
{ // acquire lock
AutoMutex _l(mLock);
size_t messageCount = mMessageEnvelopes.size();
while (i < messageCount && uptime >= mMessageEnvelopes.itemAt(i).uptime) {
i += 1;
}
MessageEnvelope messageEnvelope(uptime, handler, message);
mMessageEnvelopes.insertAt(messageEnvelope, i, 1);
……
}
……
}
消息的投遞和處理
前面已經提到了，Java層的MessageQueue處理消息時，會先調用Native層MessageQueue的nativePollOnce()，它實際調用的是native層MessageQueue的pollOnce()，而native的pollOnce調用的是Native層的Looper的pollOnce：
static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
jlong ptr, jint timeoutMillis) {
……
nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}
void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
……
mLooper->pollOnce(timeoutMillis);
……
}
在看Native層Looper的pollOnce方法之前，先看看Native層的Looper和Java層的Looper會不會有一些不一樣吧。
Looper Native
和Java層Looper的使用一樣，Native層Looper也需要prepare，也是一個通過線程局部變量存儲的對象，一個線程只有一個。那么在Native層是怎么實現線程局部變量的呢？
Linux TSD(Thread-specific Data)池
Native層線程局部變量的思想和Java層很類似，Native層會維護一個全局的pthread_keys數組，用于存放線程局部變量的鍵。其中seq用于標記是否"in_use"，destr則是一個函數指針，可用作析構函數，在線程退出時釋放該鍵對應于線程中的線程局部變量。
static struct pthread_key_struct pthread_keys[PTHREAD_KEYS_MAX] ={{0,NULL}};
int pthread_key_create(pthread_key_t *key, void (*destr_function) (void*));
struct pthread_key_struct
{
/* Sequence numbers. Even numbers indicated vacant entries. Note
that zero is even. We use uintptr_t to not require padding on
32- and 64-bit machines. On 64-bit machines it helps to avoid
wrapping, too. */
uintptr_t seq;
/* Destructor for the data. */
void (*destr) (void *);
};
pthread在創建線程時會維護一個指針數組，數組元素指向線程局部變量的數據塊。整體解構如下圖：
創建Looper
創建Looper時，會做以下事情：
- 通過eventfd創建mWakeEventFd用于線程間通信去喚醒Looper的，當需要喚醒Looper時，就往里面寫1
- 創建用于監聽epoll_event的mEpollFd，并初始化mEpollFd要監聽的epoll_event類型
- 通過epoll_ctl將mWakeEventFd注冊到mEpollFd中，當mWakeEventFd有事件可讀則喚醒Looper
- 如果mRequests不為空的話，說明前面注冊了有要監聽的fd，則遍歷mRequests中的Request，將它初始化為epoll_event并通過epoll_ctl注冊到mEpollFd中，當有可讀事件同樣喚醒Looper
Looper::Looper(bool allowNonCallbacks) :
mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
mPolling(false), mEpollFd(-1), mEpollRebuildRequired(false),
mNextRequestSeq(0), mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
mWakeEventFd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
……
rebuildEpollLocked();
}
void Looper::rebuildEpollLocked() {
……
// Allocate the new epoll instance and register the wake pipe.
mEpollFd = epoll_create(EPOLL_SIZE_HINT);
……
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);
……
for (size_t i = 0; i < mRequests.size(); i++) {
const Request& request = mRequests.valueAt(i);
struct epoll_event eventItem;
request.initEventItem(&eventItem);
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, request.fd, & eventItem);
……
}
}
pollOnce
對于Native層Looper的pollOnce，找它函數定義稍微有點隱秘，它在Looper.h中聲明，inline到pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData)函數里了，它做了以下事情：
- 優先處理mResponses里的Response，即來自fd的事件
- 如果沒有需處理的Response，再調用pollInner
inline int pollOnce(int timeoutMillis) {
return pollOnce(timeoutMillis, NULL, NULL, NULL);
}
int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
int result = 0;
for (;;) {
while (mResponseIndex < mResponses.size()) {
const Response& response = mResponses.itemAt(mResponseIndex++);
int ident = response.request.ident;
if (ident >= 0) {
……
return ident;
}
}
if (result != 0) {
#if DEBUG_POLL_AND_WAKE
ALOGD("%p ~ pollOnce - returning result %d", this, result);
#endif
……
return result;
}
result = pollInner(timeoutMillis);
}
}
pollInner這個函數比較長，它做了以下事情：
- 基于下一個Message調整獲取Message的時間間隔timeoutMillis
- 清空mResponses
- 獲取epoll事件，即將要處理的Message
- 更新mPolling，防止進入idle
- 執行合法性檢查
- 如果epoll_event的fd為mWakeFd，說明是Looper的喚醒事件，則喚醒Looper
- 否則先將epoll_event封裝為Request，更新epoll_event的事件類型，再封裝為Response裝入mResponses
- 循環取出mMessageEnvelopes隊頭的MessageEnvelope，并將MessageEnvelope中的Message交給對應的Native層的Handler處理
- 循環調用mResponses中所有Response的callback
至此對Android消息機制的學習就結束啦。
