Android平臺上，主要用到的通信機制有兩種：Handler和Binder，前者用于進(jìn)程內(nèi)部的通信，后者主要用于跨進(jìn)程通信。
1. 概述
今天我們主要來聊一聊進(jìn)程內(nèi)部的消息機制Handler。
從技術(shù)實現(xiàn)來說消息機制并不復(fù)雜，不只是Android平臺,各種平臺的消息機制原理基本上都是比較相似的，其中用到的主要概念有：
- 消息發(fā)送者
- 消息隊列
- 消息循環(huán)處理
簡單示意圖如下：
圖中表達(dá)的意思是，消息發(fā)送者通過某種方式將消息發(fā)送到消息隊列中，同時還有一個消息處理循環(huán)，不斷從消息隊列里取消息，并進(jìn)行處理。
Android的消息機制主要是指Handler的運行機制，Hander的運行需要相關(guān)的MessageQueue和Looper的支撐。圖中右側(cè)的部分可以理解為Android中的Looper類，這個類的內(nèi)部有對應(yīng)的消息隊列(MessageQueue mQueue)和loop方法(取消息的循環(huán))
從我們開發(fā)者的角度來說，Handler是Android消息機制的最上層接口，這使得我們在開發(fā)過程中絕大多數(shù)情況下只需要和Handler打交道就可以，Handler的使用方法也很簡單，我們常常在子線程中需要更新UI時使用，常見代碼如下：
private Handler handler = new Handler(){
@Override public void handleMessage(Message msg) {
super.handleMessage(msg);
switch (msg.what) {
case xxx:
...
updateUI();
break;
}
}
};
....
private void threadMethod() {
new Thread(){
@Override public void run() {
super.run();
...
handler.sendMessage(msg);
...
}
}.start();
}
在子線程中創(chuàng)建并使用Handler：
//在子線程中使用Handler
class LooperThread extends Thread {
public Handler mHandler;
public void run() {
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
// process incoming messages here
}
};
Looper.loop();
}
}
從上面兩個例子，我們可以看到通過handler的sendMessage方法來發(fā)送消息，通過Looper.loop方法來進(jìn)行消息循環(huán)；至于消息處理是隱藏在Loop和MessageQueue中，我們接下來會一點點來深入分析。
說到Handler我們先來看下它的構(gòu)造方法，開發(fā)過程中經(jīng)常用到的構(gòu)造方法是Handler()和Handler(Looper looper);
public class Handler{
final MessageQueue mQueue;
final Looper mLooper;
final Callback mCallback;
final boolean mAsynchronous;
.....
public Handler() {
this(null, false);
}
public Handler(Looper looper) {
this(looper, null, false);
}
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 Handler(Looper looper, Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
......
}
通過如上代碼我們可以看到構(gòu)造方法目的都是為了給mLooper、mQueue、mCallback和mAsyncronous賦值，callback和async這兩個我們用的較少，我們此次重點關(guān)注mLooper和mQueue。
Handler handler = new Handler(Looper.getMainLooper());
如上是我們常用的指定了Looper的構(gòu)造方法，內(nèi)部實現(xiàn)很簡單，直接就賦值：
/**
* Use the provided {@link Looper} instead of the default one.
*
* @param looper The looper, must not be null.
*/
public Handler(Looper looper) {
this(looper, null, false);
}
public Handler(Looper looper, Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
另一個更常用的構(gòu)造方法是如下這種：
Handler handler = new Handler();
public class Handler {
....
/**
* Default constructor associates this handler with the {@link Looper} for the
* current thread.
*
* If this thread does not have a looper, this handler won't be able to receive messages
* so an exception is thrown.
*/
public Handler() {
this(null, false);
}
public Handler(Callback callback, boolean async) {
.....
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;
}
....
}
因為默認(rèn)構(gòu)造方法沒有入?yún)ⅲ敲磎Looper通過Looper自身的myLooper方法來獲取，判斷mLooper是否為null，如果非空則給mQueue、callback等賦值，如果等于null則說明Handler是在線程中創(chuàng)建并且創(chuàng)建前沒有調(diào)用Looper的prepare()方法；那我們猜想肯定是在Looper.prepare()方法中初始化了Looper對象。
這里有兩個疑問
- 在Activity(UI線程)中new Handler()的時候也沒有去調(diào)用Looper.prepare()，為什么沒有拋異常？
- Looper.prepare()是如何初始化Looper對象并在通過myLooper方法向外部提供引用的？
我們先來看第二個問題，還是老方法直接看源碼實現(xiàn)：
public class Looper {
// sThreadLocal.get() will return null unless you've called prepare().
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
final MessageQueue mQueue;
final Thread mThread;
volatile boolean mRun;
.....
/** Initialize the current thread as a looper.
* This gives you a chance to create handlers that then reference
* this looper, before actually starting the loop. Be sure to call
* {@link #loop()} after calling this method, and end it by calling
* {@link #quit()}.
*/
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));
}
....
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mRun = true;
mThread = Thread.currentThread();
}
/**
* Return the Looper object associated with the current thread. Returns
* null if the calling thread is not associated with a Looper.
*/
public static Looper myLooper() {
return sThreadLocal.get();
}
}
代碼實現(xiàn)很簡單，就是new一個Looper對象set給sThreadLocal，然后獲取是通過sThreadLocal的get方法。這樣我們明白了為什么在thread中new Handler前要調(diào)用Looper.parepare()。
接下來我們回頭看問題1，為什么在UI線程中可以直接new Handler()來使用呢？UI線程直接初始化Handler沒有拋異常說明sThreadLocal.get()返回值不是空，也就是已經(jīng)set過Looper對象，那是哪里設(shè)置的呢？
了解應(yīng)用啟動流程的應(yīng)該知道，應(yīng)用的main方法在ActivityThread中，在main方法中完成了一些初始化工作，我們來看main方法中做了什么
public static void main(String[] args) {
...
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
thread.attach(false);
if(sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
這里我們看到了熟悉的Looper.prepare和Looper.loop，不過這里調(diào)用的是Looper的另一個方法prepareMainLooper，跟進(jìn)去看
public static void prepareMainLooper() {
prepare(false);
Class var0 = Looper.class;
synchronized(Looper.class) {
if(sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
} else {
sMainLooper = myLooper();
}
}
}
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");
} else {
sThreadLocal.set(new Looper(quitAllowed));
}
}
可以看到prepareMainLooper()和prepare()調(diào)用的是Looper的同一個方法prepard(boolean quitAllowed)，UI線程的Looper是不允許退出的(如果允許退出，調(diào)用了quit豈不UI就無法刷新啦)，其他線程的Looper是允許退出的。
所以，UI線程并非特殊，而是在更早的時候系統(tǒng)已經(jīng)做好了Looper的初始化操作。既然已經(jīng)發(fā)現(xiàn)了系統(tǒng)初始化Looper的地方，那UI線程是不是也有自己的Handler來處理消息呢？答案顯示是有的。
prepare方法調(diào)用后，創(chuàng)建Handler,這里是new ActivityThread對象，ActivityThread有實例變量mH就是Handler的對象
main() {
...
ActivityThread thread = new ActivityThread();
if(sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
...
}
final ActivityThread.H mH = new ActivityThread.H(null);
final Handler getHandler() {
return this.mH;
}
...
private class H extends Handler {
...
}
2. 消息循環(huán)
到這里Looper和Handler都準(zhǔn)備好，還有個必須要做的就是開啟消息循環(huán)Looper.loop()。
/**
* Run the message queue in this thread. Be sure to call
* {@link #quit()} to end the loop.
*/
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
...
for (;;) { //永久循環(huán)
Message msg = queue.next(); // might block
if (msg == null) { //死循環(huán)退出條件
// No message indicates that the message queue is quitting.
return;
}
...
msg.target.dispatchMessage(msg);//這里的target是Handler
...
}
}
說到消息的循環(huán)，就不得不提MessageQueue中next方法
Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
......
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
// 如果從隊列里拿到的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);
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;
}
......
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}
調(diào)用這個方法的時候，有可能讓線程進(jìn)入等待狀態(tài)。什么情況下線程會進(jìn)入等待狀態(tài)呢？有如下兩種情況
- 當(dāng)消息隊列中沒有消息是，它會使線程進(jìn)入等待狀態(tài)
- 消息隊列中有消息，但是消息指定了執(zhí)行的時間，而現(xiàn)在還沒有到這個時間，線程也會進(jìn)入等待狀態(tài)
消息隊列中的消息是按照時間先后來排序的，后面我們在分析消息發(fā)送的時候會看到。
大家可能注意到如下一條native的語句，它是查看當(dāng)前消息隊列中有沒有消息：
nativePollOnce(mPtr, nextPollTimeoutMillis);
這是一個JNI方法，我們等一下再分析，這里傳入的參數(shù)mPtr就是指向前面我們在JNI層創(chuàng)建的NativeMessageQueue對象了，而參數(shù)nextPollTimeoutMillis則表示如果當(dāng)前消息隊列中沒有消息，它要等待的時候，for循環(huán)開始時，傳入的值為0，表示不等待。
當(dāng)前nativePoolOnce返回后，就去看看消息隊列中有沒有消息：
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);
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
如果消息隊列中有消息，并且當(dāng)前時候大于等于消息中的執(zhí)行時間，那么就直接返回這個消息給Looper.loop消息處理，否則的話就要等待到消息的執(zhí)行時間：
nextPollTimeoutMillis = (int) Math.min(when - now, Integer.MAX_VALUE);
如果消息隊列中沒有消息，那就進(jìn)入到無窮等待狀態(tài)直到有新消息：
nextPollTimeoutMillis = -1;
-1表示下次調(diào)用nativePollOnce時，如果消息中沒有消息就進(jìn)入無限等待狀態(tài)中去。這里計算出來的等待時間是在下次調(diào)用nativePollOnce的時候使用。
這里說的等待，是空閑等待，而不是忙等待，因此，在進(jìn)入空閑等待狀態(tài)前，如果應(yīng)用程序注冊了IdleHandler接口來處理一些事情，那么就會先執(zhí)行這里IdleHandler，然后再進(jìn)入等待狀態(tài)。
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
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;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
如果沒有IdleHandler即pendingIdleHandlerCount等于0，那么下面的邏輯就不執(zhí)行了，通過continue語句直接進(jìn)入下一次循環(huán)，否則就把注冊的mPendingIdleHandlers中的IdleHandler取出來，放到mPendingIdleHandler數(shù)組中，并循環(huán)執(zhí)行這些注冊了的IdelHandler：
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
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);
}
}
}
執(zhí)行完這些IdleHandler之后，下次再次調(diào)用nativePollOnce函數(shù)的時候，就不設(shè)置超時時間了，因為很有可能在執(zhí)行IdleHandler的時候，已經(jīng)有新的消息加入到消息隊列中去了，因此，要重置nextPollTimeoutMillis的值：
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
分析完MessageQueue的next方法之后，我們來稍微深入的分析下JNI方法nativePollOnce了，看看它是如何進(jìn)入等待狀態(tài)的，這個函數(shù)在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中：
static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
jint ptr, jint timeoutMillis) {
NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
nativeMessageQueue->pollOnce(env, timeoutMillis);
}
static JNINativeMethod gMessageQueueMethods[] = {
/* name, signature, funcPtr */
{ "nativeInit", "()V", (void*)android_os_MessageQueue_nativeInit },
{ "nativeDestroy", "()V", (void*)android_os_MessageQueue_nativeDestroy },
{ "nativePollOnce", "(II)V", (void*)android_os_MessageQueue_nativePollOnce },
{ "nativeWake", "(I)V", (void*)android_os_MessageQueue_nativeWake }
};
這個函數(shù)首先是通過傳進(jìn)來的參數(shù)ptr取回在Java層創(chuàng)建的MessageQueue對象時在JNI層創(chuàng)建的NativeMessageQueue對象：
public final class MessageQueue {
private long mPtr; // used by native code
....
MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitAllowed;
mPtr = nativeInit();
}
.....
}
static void android_os_MessageQueue_nativeInit(JNIEnv* env, jobject obj) {
NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
if (!nativeMessageQueue) {
jniThrowRuntimeException(env, "Unable to allocate native queue");
return;
}
nativeMessageQueue->incStrong(env);
android_os_MessageQueue_setNativeMessageQueue(env, obj, nativeMessageQueue);
}
取到NativeMessageQueue對象，然后調(diào)用它的pollOnce函數(shù)
void NativeMessageQueue::pollOnce(JNIEnv* env, int timeoutMillis) {
mInCallback = true;
mLooper->pollOnce(timeoutMillis);
mInCallback = false;
if (mExceptionObj) {
env->Throw(mExceptionObj);
env->DeleteLocalRef(mExceptionObj);
mExceptionObj = NULL;
}
}
這里把操作轉(zhuǎn)給mLooper對象的pollOnce函數(shù)處理，這里的mLooer對象是C++層的對象，它也是在JNI層創(chuàng)建NativeMessageQueue對象時創(chuàng)建的：
NativeMessageQueue::NativeMessageQueue() : mInCallback(false), mExceptionObj(NULL) {
mLooper = Looper::getForThread();
if (mLooper == NULL) {
mLooper = new Looper(false);
Looper::setForThread(mLooper);
}
}
它的pollOnce函數(shù)在Looper.cpp(JellyBean、Lollipop)中:
int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
int result = 0;
for (;;) {
....
if (result != 0) {
.....
return result;
}
result = pollInner(timeoutMillis);
}
}
我們只看核心部分，這里主要是繼續(xù)調(diào)用pollInner函數(shù)來進(jìn)一步操作，如果pollInner返回不等于0，這個函數(shù)就可以返回了。
pollInner的定義如下：
int Looper::pollInner(int timeoutMillis) {
.....
// Poll.
int result = ALOOPER_POLL_WAKE;
mResponses.clear();
mResponseIndex = 0;
struct epoll_event eventItems[EPOLL_MAX_EVENTS];
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
// Acquire lock.
mLock.lock();
// Check for poll error.
if (eventCount < 0) {
if (errno == EINTR) {
goto Done;
}
ALOGW("Poll failed with an unexpected error, errno=%d", errno);
result = ALOOPER_POLL_ERROR;
goto Done;
}
// Check for poll timeout.
if (eventCount == 0) {
.....
result = ALOOPER_POLL_TIMEOUT;
goto Done;
}
.....
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();
} else {
ALOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
}
} else {
.....
}
}
Done: ;
// Invoke pending message callbacks.
mNextMessageUptime = LLONG_MAX;
while (mMessageEnvelopes.size() != 0) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
if (messageEnvelope.uptime <= now) {
// Remove the envelope from the list.
// We keep a strong reference to the handler until the call to handleMessage
// finishes. Then we drop it so that the handler can be deleted *before*
// we reacquire our lock.
{ // obtain handler
sp<MessageHandler> handler = messageEnvelope.handler;
Message message = messageEnvelope.message;
mMessageEnvelopes.removeAt(0);
mSendingMessage = true;
mLock.unlock();
....
handler->handleMessage(message);
} // release handler
mLock.lock();
mSendingMessage = false;
result = ALOOPER_POLL_CALLBACK;
} else {
// The last message left at the head of the queue determines the next wakeup time.
mNextMessageUptime = messageEnvelope.uptime;
break;
}
}
// Release lock.
mLock.unlock();
// Invoke all response callbacks.
......
return result;
}
這個函數(shù)比較長并且其中用到了goto，我們?nèi)匀恢魂P(guān)注核心代碼，我們看到函數(shù)開頭首先是調(diào)用epoll_wait函數(shù)來看看epoll專用文件描述符mEpollFd所監(jiān)控的文件描述符是否有IO事件發(fā)生，它設(shè)置監(jiān)控的超時時間為pollOnce函數(shù)傳遞過來的timeoutMillis：
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
當(dāng)mEpollFd所監(jiān)控的文件描述符發(fā)生了要監(jiān)控的IO事件后或者監(jiān)控時間超時后，線程就從epoll_wait返回了，否則線程就會在epoll_wait函數(shù)中進(jìn)入睡眠狀態(tài)了。返回后如果eventCount等于0，就說明是超時了：
if (eventCount == 0) {
......
result = ALOOPER_POLL_TIMEOUT;
goto Done;
}
如果eventCount不等于0，就說明發(fā)生要監(jiān)控的事件：
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();
} else {
ALOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
}
} else {
.....
}
}
這里我們只關(guān)注mWakeReadPipeFd文件描述符上的事件, 在Looper的構(gòu)造函數(shù)中設(shè)置了要監(jiān)控mWakeReadPipeFd文件描述符的EPOLLIN事件：
Looper::Looper(bool allowNonCallbacks) :
mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
int wakeFds[2];
int result = pipe(wakeFds); // 創(chuàng)建一個管道
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);
// Allocate the epoll instance and register the wake pipe.
// 創(chuàng)建一個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)); // zero out unused members of data field union
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);
}
如果在mWakeReadPipeFd文件描述符上發(fā)生了EPOLLIN就說明應(yīng)用程序中的消息隊列里面有新的消息需要處理了，接下來它就會先調(diào)用awoken函數(shù)清空管道中的內(nèi)容，以便下次再調(diào)用pollInner函數(shù)時，知道自從上次處理完消息隊列中的消息后，有沒有新的消息加進(jìn)來。
awoken函數(shù)的實現(xiàn)很簡單，它就是把管道中的內(nèi)容都讀取出來：
void Looper::awoken() {
.....
char buffer[16];
ssize_t nRead;
do {
nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
} while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer));
}
因為當(dāng)其它的線程向應(yīng)用程序的消息隊列加入新的消息時，會向這個管道寫入新的內(nèi)容來通知應(yīng)用程序主線程有新的消息需要處理了，下面我們分析消息的發(fā)送的時候?qū)吹健?/p>
這樣，消息的循環(huán)過程就分析完了，這部分邏輯還是比較復(fù)雜的，它利用Linux系統(tǒng)中的管道（pipe）進(jìn)程間通信機制來實現(xiàn)消息的等待和處理，不過，了解了這部分內(nèi)容之后，下面我們分析消息的發(fā)送和處理就簡單多了。
3. 消息發(fā)送
在線程(不管是UI線程還是子線程)中準(zhǔn)備好消息隊列并且進(jìn)入消息循環(huán)后，其他地方就可以往這個消息隊列中發(fā)送消息了。
在前面我們提到過Handler的構(gòu)造方法，主要就是初始化類成員mLooper和mQueue。
public class Handler {
......
public Handler() {
......
mLooper = Looper.myLooper();
......
mQueue = mLooper.mQueue;
......
}
final MessageQueue mQueue;
final Looper mLooper;
......
}
有了Looper對象后，就可以通過mLooper.mQueue來訪問消息隊列了。發(fā)送消息的方法大家都不陌生，就是常用的sendMessage方法。在發(fā)送消息時，是可以指定消息的處理時間的，但是通過sendMessage函數(shù)發(fā)送的消息的處理時間默認(rèn)就為當(dāng)前時間，即表示要馬上處理，因此，從sendMessage函數(shù)中調(diào)用sendMessageDelayed函數(shù)，傳入的時間參數(shù)為0，表示這個消息不要延時處理，而在sendMessageDelayed函數(shù)中，則會先獲得當(dāng)前時間，然后加上消息要延時處理的時間，即得到這個處理這個消息的絕對時間，然后調(diào)用sendMessageAtTime函數(shù)來把消息加入到應(yīng)用程序的消息隊列中去。
在sendMessageAtTime函數(shù)，首先得到應(yīng)用程序的消息隊列mQueue，這是在Handler對象構(gòu)造時初始化好的，前面已經(jīng)分析過了，接著設(shè)置這個消息的目標(biāo)對象target，即這個消息最終是由誰來處理的：
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) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
這里將它賦值為this，即表示這個消息最終由這個Handler對象來處理。
函數(shù)最后調(diào)用queue.enqueueMessage來把這個消息加入到消息隊列中，具體實現(xiàn)在MessageQueue.java文件中：
final boolean enqueueMessage(Message msg, long when) {
......
boolean needWake;
synchronized (this) {
.......
msg.when = when;
Message p = mMessages;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
// 此時，新消息會插入到鏈表的表頭，這意味著隊列需要調(diào)整喚醒時間啦。
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
// 此時，新消息會插入到鏈表的內(nèi)部，一般情況下，這不需要調(diào)整喚醒時間。
// 但還必須考慮到當(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是異步的，也不是鏈表中第一個異步消息，所以沒必要喚醒了
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
}
if (needWake) {
nativeWake(mPtr);
}
return true;
}
從這段代碼來看MessageQueue說是一個消息隊列，但它其實不是隊列，而是一個鏈表。
把消息加入到消息隊列時，分兩種情況，一種當(dāng)前消息隊列為空時，這時候線程一般就是處于空閑等待狀態(tài)了，這時候就要喚醒它，另一種情況是消息隊列不為空，這時候就不需要喚醒線程了，因為這時候它一定是在忙著處于消息隊列中的消息，因此不會處于空閑等待的狀態(tài)。
第一種情況比較簡單，只要把消息放在消息隊列頭就可以了：
msg.next = p;
mMessages = msg;
needWake = mBlocked;
第二種情況相對就比較復(fù)雜一些了，前面我們說過，當(dāng)往消息隊列中發(fā)送消息時，是可以指定消息的處理時間的，而消息隊列中的消息，就是按照這個時間從小到大來排序的，因此，當(dāng)把新的消息加入到消息隊列時，就要根據(jù)它的處理時間來找到合適的位置，然后再放進(jìn)消息隊列中去：
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
把消息加入到消息隊列去后，如果線程正處于空閑等待狀態(tài)，就需要調(diào)用natvieWake函數(shù)來喚醒它了，這是一個JNI方法，定義在android_os_MessageQueue.cpp文件中：
static void android_os_MessageQueue_nativeWake(JNIEnv* env, jclass clazz, jlong ptr) {
NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
return nativeMessageQueue->wake();
}
這個JNI層的NativeMessageQueue對象我們在前面分析消息循環(huán)的時候創(chuàng)建好的，保存在Java層的MessageQueue對象的mPtr成員變量中，這里把它取回來之后，就調(diào)用它的wake函數(shù)來喚醒關(guān)聯(lián)的線程，wake方法也在android_os_MessageQueue.cpp文件中：
void NativeMessageQueue::wake() {
mLooper->wake();
}
這里它又通過成員變量mLooper的wake函數(shù)來執(zhí)行操作，這里的mLooper成員變量是一個C++層實現(xiàn)的Looper對象，它定義在Looper.cpp文件中：
void Looper::wake() {
......
ssize_t nWrite;
do {
nWrite = write(mWakeWritePipeFd, "W", 1);
} while (nWrite == -1 && errno == EINTR);
......
}
這個wake函數(shù)很簡單，只是通過打開文件描述符mWakeWritePipeFd往管道的寫入一個"W"字符串。其實，往管道寫入什么內(nèi)容并不重要，往管道寫入內(nèi)容的目的是為了喚醒關(guān)聯(lián)的線程。前面我們在分析應(yīng)用程序的消息循環(huán)時說到，當(dāng)消息隊列中沒有消息處理時，關(guān)聯(lián)的線程就會進(jìn)入空閑等待狀態(tài)，而這個空閑等待狀態(tài)就是通過調(diào)用這個Looper類的pollInner函數(shù)來進(jìn)入的，具體就是在pollInner函數(shù)中調(diào)用epoll_wait函數(shù)來等待管道中有內(nèi)容可讀的。
這時候既然管道中有內(nèi)容可讀了，關(guān)聯(lián)的線程就會從這里的Looper類的pollInner函數(shù)返回到JNI層的nativePollOnce函數(shù)，最后返回到Java層中的MessageQueue.next方法中去，這里它就會發(fā)現(xiàn)消息隊列中有新的消息需要處理了，于就會處理這個消息。
4. 消息處理
前面第一部分分析消息循環(huán)時，在Looper類的looper方法中進(jìn)行消息循環(huán)的，這個方法中從消息隊列中獲取到消息對象msg后，就會調(diào)用它的target成員變量的dispatchMessage方法來處理這個消息。
public static void loop() {
final Looper me = myLooper();
......
final MessageQueue queue = me.mQueue;
......
for (;;) {
Message msg = queue.next(); // might block
.......
msg.target.dispatchMessage(msg);
......
msg.recycleUnchecked();
}
}
在前面分析消息的發(fā)送時說過，這個消息對象msg的成員變量target是在發(fā)送消息的時候設(shè)置好的，通過哪個Handler來發(fā)送消息，就通過哪個Handler來處理消息。
public class Handler {
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
}
這里的消息對象msg的callback成員變量和Handler類的mCallBack成員變量一般都為null，于是，就會調(diào)用Handler類的handleMessage方法來處理這個消息，這就到了我們平常使用Handler的時候重寫的Handler的方法handlerMessage。
5. 總結(jié)
至此，我們就從消息循環(huán)、消息發(fā)送和消息處理三個部分分析完Android應(yīng)用程序的消息處理機制了，為了更深理解，這里我們對其中的一些要點作一個總結(jié)：
- Android應(yīng)用程序的消息處理機制由消息循環(huán)、消息發(fā)送和消息處理三個部分組成的。
- Android應(yīng)用程序的主線程在進(jìn)入消息循環(huán)過程前，會在內(nèi)部創(chuàng)建一個Linux管道（Pipe），這個管道的作用是使得Android應(yīng)用程序主線程在消息隊列為空時可以進(jìn)入空閑等待狀態(tài)，并且使得當(dāng)應(yīng)用程序的消息隊列有消息需要處理時喚醒應(yīng)用程序的主線程。
- Android應(yīng)用程序的主線程進(jìn)入空閑等待狀態(tài)的方式實際上就是在管道的讀端等待管道中有新的內(nèi)容可讀，具體來說就是是通過Linux系統(tǒng)的Epoll機制中的epoll_wait函數(shù)進(jìn)行的。
- 當(dāng)往Android應(yīng)用程序的消息隊列中加入新的消息時，會同時往管道中的寫端寫入內(nèi)容，通過這種方式就可以喚醒正在等待消息到來的應(yīng)用程序主線程。
- 當(dāng)應(yīng)用程序主線程在進(jìn)入空閑等待前，會認(rèn)為當(dāng)前線程處理空閑狀態(tài)，于是就會調(diào)用那些已經(jīng)注冊了的IdleHandler接口，使得應(yīng)用程序有機會在空閑的時候處理一些事情。
?
6. 問題
最后，在前面的Looper部分相信很多人有個疑問
- sThreadLocal在Looper類中是靜態(tài)的，為什么線程A中已經(jīng)調(diào)用了Looper.prepare給sThreadLocal設(shè)置了值，在線程B中直接調(diào)用Looper.myLooper從sThreadLocal中g(shù)et值返回確是null？
- 一個線程可以有幾個Handler？
- 一個線程可以有幾個Looper？
7. 補充內(nèi)容
7.1 ThreadLocal
官方文檔中對ThreadLocal的說明：
/**
* Implements a thread-local storage, that is, a variable for which each thread
* has its own value. All threads share the same {@code ThreadLocal} object,
* but each sees a different value when accessing it, and changes made by one
* thread do not affect the other threads. The implementation supports
* {@code null} values.
*
* @see java.lang.Thread
*/
public class ThreadLocal<T> {
}
這段話的意思是實現(xiàn)了一個線程相關(guān)的存儲，即每個線程都有自己獨立的變量。所有的線程都共享者這一個ThreadLocal對象，并且當(dāng)一個線程的值發(fā)生改變之后，不會影響其他的線程的值。
ThreadLocal的類定義使用了泛型ThreadLocal<T>，其中T指代的是在線程中存取值的類型。（對應(yīng)Android中使用的ThreadLocal, T則存放的類型為Looper）
- set方法
/**
* Sets the value of this variable for the current thread. If set to
* {@code null}, the value will be set to null and the underlying entry will
* still be present.
*
* @param value the new value of the variable for the caller thread.
*/
public void set(T value) {
Thread currentThread = Thread.currentThread();
Values values = values(currentThread);
if (values == null) {
values = initializeValues(currentThread);
}
values.put(this, value);
}
/**
* Sets entry for given ThreadLocal to given value, creating an
* entry if necessary.
*/
void put(ThreadLocal<?> key, Object value) {
cleanUp();
// Keep track of first tombstone. That's where we want to go back
// and add an entry if necessary.
int firstTombstone = -1;
for (int index = key.hash & mask;; index = next(index)) {
Object k = table[index];
if (k == key.reference) {
// Replace existing entry.
table[index + 1] = value;
return;
}
if (k == null) {
if (firstTombstone == -1) {
// Fill in null slot.
table[index] = key.reference;
table[index + 1] = value;
size++;
return;
}
// Go back and replace first tombstone.
table[firstTombstone] = key.reference;
table[firstTombstone + 1] = value;
tombstones--;
size++;
return;
}
// Remember first tombstone.
if (firstTombstone == -1 && k == TOMBSTONE) {
firstTombstone = index;
}
}
}
簡單地說，每個線程對象內(nèi)部會記錄一張邏輯上的key-value表，當(dāng)我們在不同Thread里調(diào)用Looper.prepare()時，其實是向Thread對應(yīng)的那張表里添加一個key-value項，其中的key部分，指向的是同一個對象，即Looper.sThreadLocal靜態(tài)對象，而value部分，則彼此不同，我們可以畫出如下示意圖：
看到了吧，不同Thread會對應(yīng)不同Object[]數(shù)組，該數(shù)組以每2個元素為一個key-value對。請注意不同Thread雖然使用同一個靜態(tài)對象作為key值，最終卻會對應(yīng)不同的Looper對象。
7.2 同步分隔欄
上面的代碼中還有一個“同步分割欄”的概念需要提一下。所謂“同步分割欄”，可以被理解為一個特殊Message，它的target域為null。它不能通過sendMessageAtTime()等函數(shù)加入消息隊列里，而只能通過調(diào)用Looper的postSyncBarrier()來加入消息隊列。
“同步分割欄”是起什么作用的呢？它就像一個卡子，卡在消息鏈表中的某個位置，當(dāng)消息循環(huán)不斷從消息鏈表中摘取消息并進(jìn)行處理時，一旦遇到這種“同步分割欄”，那么即使在分割欄之后還有若干已經(jīng)到時的普通Message，也不會摘取這些消息了。請注意，此時只是不會摘取“普通Message”了，如果隊列中還設(shè)置有“異步Message”，那么還是會摘取已到時的“異步Message”的。
在Android的消息機制里，“普通Message”和“異步Message”也就是這點兒區(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”向消息隊列打入“異步Message”的。異步Handler的mAsynchronous域為true，因此它在調(diào)用enqueueMessage()時，可以走入：
if (mAsynchronous) {
msg.setAsynchronous(true);
}
現(xiàn)在我們畫一張關(guān)于“同步分割欄”的示意圖：
圖中的消息隊列中有一個“同步分割欄”，因此它后面的“2”號Message即使到時了，也不會摘取下來。而“3”號Message因為是個異步Message，所以當(dāng)它到時后，是可以進(jìn)行處理的。
“同步分割欄”這種卡子會一直卡在消息隊列中，除非我們調(diào)用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);
}
}
}
和插入消息類似，如果刪除動作改變了鏈表的頭部，也意味著隊列的最近喚醒時間應(yīng)該被調(diào)整了，因此needWake會被設(shè)為true，以便代碼下方可以走進(jìn)nativeWake()。
參考文獻(xiàn)
Android應(yīng)用程序消息處理機制（Looper、Handler）分析
