聊一聊Android的消息機制
聊一聊Android的消息機制 java
侯 亮 android
1概述
在Android平臺上，主要用到兩種通訊機制，即Binder機制和消息機制，前者用於跨進程通訊，後者用於進程內部通訊。 數組
從技術實現上來講，消息機制仍是比較簡單的。從大的方面講，不光是Android平臺，各類平臺的消息機制的原理基本上都是相近的，其中用到的主要概念大概有：
1）消息發送者；
2）消息隊列；
3）消息處理循環。
示意圖以下： less
圖中表達的基本意思是，消息發送者經過某種方式，將消息發送到某個消息隊列裏，同時還有一個消息處理循環，不斷從消息隊列裏摘取消息，並進一步解析處理。 異步
在Android平臺上，把上圖的右邊部分包裝成了一個Looper類，這個類的內部具備對應的消息隊列（MessageQueue mQueue）和loop函數。
可是Looper只是個簡單的類而已，它雖然提供了循環處理方面的成員函數loop()，卻不能本身憑空地運行起來，而只能寄身於某個真實的線程。並且，每一個線程最多隻能運做一個Looper對象，這一點應該很容易理解。 async
Android平臺上另外一個關鍵類是Handler。當消息循環在其寄身的線程里正式運做後，外界就是經過Handler向消息循環發出事件的。咱們再畫一張示意圖以下： ide
固然，系統也容許多個Handler向同一個消息隊列發送消息： 函數
整個消息機制的輪廓也就是這些啦，下面咱們來詳細闡述。 oop
2先說一下Looper部分
Looper類的定義截選以下：
【frameworks/base/core/java/android/os/Looper.java】 post
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.class
final MessageQueue mQueue;
final Thread mThread;
private Printer mLogging;
. . . . . .
. . . . . .
當一個線程運行到某處，準備運做一個Looper時，它必須先調用Looper類的靜態函數prepare()，作一些準備工做。說穿了就是建立一個Looper對象，並把它設置進線程的本地存儲區（TLS）裏。而後線程才能繼續調用Looper類的另外一個靜態函數loop()，從而創建起消息處理循環。示意圖以下：
prepare()函數的代碼以下：
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)); // 建立Looper對象，並設置進TLS
}
爲了便於你們理解，咱們多說兩句關於sThreadLocal的細節，這會牽扯一點兒本地存儲的技術。簡單地說，每一個線程對象內部會記錄一張邏輯上的key-value表，固然，這張表在具體實現時不必定會被實現成HashMap，以咱們目前的代碼來講，它被記錄成一個數組，其中每兩個數組項做爲一個key-value單元。反正你們從邏輯上理解概念便可，沒必要拘泥於具體實現。很明顯，一個線程內部是能夠記錄多個本地存儲單元的，咱們關心的sThreadLocal只是其中一個本地存儲單元的key而已。
當咱們在不一樣Thread裏調用Looper.prepare()時，實際上是向Thread對應的那張表裏添加一個key-value項，其中的key部分，指向的是同一個對象，即Looper.sThreadLocal靜態對象，而value部分，則彼此不一樣，咱們能夠畫出以下示意圖：
看到了吧，不一樣Thread會對應不一樣Object[]數組，該數組以每2個元素爲一個key-value對。請注意不一樣Thread雖然使用同一個靜態對象做爲key值，最終卻會對應不一樣的Looper對象，這一點系統是不會弄錯的。
爲了由淺入深地闡述問題，咱們暫時先不看Looper.loop()內部的代碼，這個後文還會再講。如今咱們接着說說Handler。
3接着說一下Handler部分
通常而言，運做Looper的線程會負責構造本身的Handler對象，固然，其餘線程也能夠針對某個Looper構造Handler對象。
Handler對象在構造時，不但會把Looper對象記錄在它內部的mLooper成員變量中，還會把Looper對象的消息隊列也一併記錄，代碼截選以下：
public Handler(Callback callback, boolean async)
{
. . . . . .
mLooper = Looper.myLooper(); // 記錄下Looper對象
. . . . . .
mQueue = mLooper.mQueue; // 也記錄下Looper對象的消息隊列
mCallback = callback;
mAsynchronous = async;
}
咱們也能夠直接傳入Looper對象，此時可使用另外一個構造函數：
public Handler(Looper looper, Callback callback, boolean async)
{
mLooper = looper; // 記錄下Looper對象
mQueue = looper.mQueue; // 也記錄下Looper對象的消息隊列
mCallback = callback;
mAsynchronous = async;
}
簡單說來，只要一個線程能夠獲取另外一個目標線程的某個Handler對象，它就具備了向目標線程發送消息的能力。不過，也只是發送消息而已，消息的真正處理倒是在目標線程的消息循環裏完成的。
前文已經說過，在Looper準備停當後，咱們的線程會調用Looper.loop()，從而進入真正的循環機制。loop()函數的代碼流程很是簡單，只不過是在一個for循環裏不停從消息隊列中摘取消息，然後調用msg.target.dispatchMessage()對消息進行派發處理而已。
這麼看來，msg.target域就顯得比較重要了，說穿了，這個域記錄的其實就是當初向消息隊列發送消息的那個handler啦。當咱們調用handler的send函數時，最終基本上都會走到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對象啦！往後msg.target.dispatchMessage()時會使用。
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
請你們注意msg.target = this;一句，記錄的就是handler對象。
當Looper的消息循環最終調用到msg.target.dispatchMessage()時，會間接調用到handler的handleMessage()函數，從而對消息進行實際處理。
在實際運用handler時，大致有兩種方式。一種方式是寫一個繼承於Handler的新類，並在新類裏實現本身的handleMessage()成員函數；另外一種方式是在建立匿名Handler對象時，直接修改handleMessage()成員函數。
4消息隊列MessageQueue
在剛剛介紹Handler的sendMessageAtTime()時，咱們已經看到最終會調用queue.enqueueMessage()來向消息隊列打入消息。queue對應的類是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 code
Message mMessages; // 消息隊列！
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);
. . . . . .
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) {
// 此時，新消息會插入到鏈表的表頭，這意味着隊列須要調整喚醒時間啦。
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// 此時，新消息會插入到鏈表的內部，通常狀況下，這不須要調整喚醒時間。
// 但還必須考慮到當表頭爲「同步分割欄」的狀況
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;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
. . . . . .
}
4.1.2說說「同步分割欄」
上面的代碼中還有一個「同步分割欄」的概念須要提一下。所謂「同步分割欄」，能夠被理解爲一個特殊Message，它的target域爲null。它不能經過sendMessageAtTime()等函數打入到消息隊列裏，而只能經過調用Looper的postSyncBarrier()來打入。
「同步分割欄」是起什麼做用的呢？它就像一個卡子，卡在消息鏈表中的某個位置，當消息循環不斷從消息鏈表中摘取消息並進行處理時，一旦遇到這種「同步分割欄」，那麼即便在分割欄以後還有若干已經到時的普通Message，也不會摘取這些消息了。請注意，此時只是不會摘取「普通Message」了，若是隊列中還設置有「異步Message」，那麼仍是會摘取已到時的「異步Message」的。
在Android的消息機制裏，「普通Message」和「異步Message」也就是這點兒區別啦，也就是說，若是消息列表中根本沒有設置「同步分割欄」的話，那麼「普通Message」和「異步Message」的處理就沒什麼大的不一樣了。
打入「同步分割欄」的postSyncBarrier()函數的代碼以下：
【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」，只需調用一下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，所以它在調用enqueueMessage()時，能夠走入：
if (mAsynchronous) {
msg.setAsynchronous(true);
}
如今咱們畫一張關於「同步分割欄」的示意圖：
圖中的消息隊列中有一個「同步分割欄」，所以它後面的「2」號Message即便到時了，也不會摘取下來。而「3」號Message由於是個異步Message，因此當它到時後，是能夠進行處理的。
「同步分割欄」這種卡子會一直卡在消息隊列中，除非咱們調用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);
}
}
}
4.1.3nativeWake()
nativeWake()對應的C++層函數以下：
【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);
}
}
}
4.2消息循環
接下來咱們來看看消息循環。咱們從Looper的Loop()函數開始講起。下面是loop()函數的簡略代碼，咱們只保留了其中最關鍵的部分：
【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); // 派發消息
. . . . . .
final long newIdent = Binder.clearCallingIdentity();
. . . . . .
msg.recycle();
}
}
對於Looper而言，它主要關心的是從消息隊列裏摘取消息，然後分派消息。然而對消息隊列而言，在摘取消息時還要考慮更多技術細節。它關心的細節有：
1）若是消息隊列裏目前沒有合適的消息能夠摘取，那麼不能讓它所屬的線程「傻轉」，而應該使之阻塞；
2）隊列裏的消息應該按其「到時」的順序進行排列，最早到時的消息會放在隊頭，也就是mMessages域所指向的消息，其後的消息依次排開；
3）阻塞的時間最好能精確一點兒，因此若是暫時沒有合適的消息節點可摘時，要考慮鏈表首個消息節點將在何時到時，因此這個消息節點距離當前時刻的時間差，就是咱們要阻塞的時長。
4）有時候外界但願隊列能在即將進入阻塞狀態以前作一些動做，這些動做能夠稱爲idle動做，咱們須要兼顧處理這些idle動做。一個典型的例子是外界但願隊列在進入阻塞以前作一次垃圾收集。
以上所述的細節，基本上都體如今MessageQueue的next()函數裏了，如今咱們就來看這個函數的主要流程。
4.2.1MessageQueue的next()成員函數
MessageQueue的next()函數的代碼截選以下：
Message next()
{
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
. . . . . .
nativePollOnce(mPtr, nextPollTimeoutMillis); // 阻塞於此
. . . . . .
// 獲取next消息，如能獲得就返回之。
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages; // 先嚐試拿消息隊列裏當前第一個消息
if (msg != null && msg.target == null) {
// 若是從隊列裏拿到的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);
msg.markInUse();
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;
}
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 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);
}
}
}
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
上面代碼中也處理了「同步分割欄」的狀況。若是從隊列裏獲取的消息是個「同步分割欄」的話，可千萬不能把「同步分割欄」給返回了，此時會嘗試找尋其後第一個「異步消息」。
next()裏另外一個要說的是那些Idle Handler，當消息隊列中沒有消息須要立刻處理時，會判斷用戶是否設置了Idle Handler，若是有的話，則會嘗試處理mIdleHandlers中所記錄的全部Idle Handler，此時會逐個調用這些Idle Handler的queueIdle()成員函數。咱們舉一個例子，在ActivityThread中，在某種狀況下會在消息隊列中設置GcIdler，進行垃圾收集，其定義以下：
final class GcIdler implements MessageQueue.IdleHandler {
@Override
public final boolean queueIdle() {
doGcIfNeeded();
return false;
}
}
4.2.1.1nativePollOnce()
前文咱們已經說過，next()中調用的nativePollOnce()起到了阻塞做用，保證消息循環不會在無消息處理時一直在那裏「傻轉」。那麼，nativePollOnce()函數到底是如何實現阻塞功能的呢？咱們來探索一下。首先，MessageQueue類裏聲明的幾個native函數，對應的JNI實現位於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 }
};
目前咱們只關心nativePollOnce對應的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);
}
NativeMessageQueue的pollOnce()以下：
【frameworks/base/core/jni/android_os_MessageQueue.cpp】
void NativeMessageQueue::pollOnce(JNIEnv* env, int timeoutMillis) {
mInCallback = true;
mLooper->pollOnce(timeoutMillis); // 用到C++層的Looper對象
mInCallback = false;
if (mExceptionObj) {
env->Throw(mExceptionObj);
env->DeleteLocalRef(mExceptionObj);
mExceptionObj = NULL;
}
}
這裏會用到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++層的Looper的構造函數以下：
Looper::Looper(bool allowNonCallbacks) :
mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
mResponseIndex(0), mNextMessageUptime(LLONG_MAX)
{
int wakeFds[2];
int result = pipe(wakeFds); // 建立一個管道
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;
// 建立一個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));
eventItem.events = EPOLLIN;
eventItem.data.fd = mWakeReadPipeFd;
// 監聽管道的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);
}
能夠看到在構造Looper對象時，其內部除了建立了一個管道之外，還建立了一個epoll來監聽管道的「讀取端」。也就是說，是利用epoll機制來完成阻塞動做的。每當咱們向消息隊列發送事件時，最終會間接向管道的「寫入端」寫入數據，這個前文已有敘述，因而epoll經過管道的「讀取端」當即就感知到了風吹草動，epoll_wait()在等到事件後，隨即進行相應的事件處理。這就是消息循環阻塞並處理的大致流程。固然，由於向管道寫數據只是爲了通知風吹草動，因此寫入的數據是很是簡單的「W」字符串。如今你們不妨再看看前文闡述「nativeWake()」的小節，應該能明白了吧。
咱們仍是繼續說消息循環。Looper的pollOnce()函數以下：
【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，因而調用awoken()
}
. . . . . .
}
else
{
// 若是是除管道之外的其餘fd發生了變更，那麼根據其對應的request，
// 將response先記錄進mResponses
ssize_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;
// 內部會調用 mResponses.push(response);
pushResponse(events, mRequests.valueAt(requestIndex));
}
. . . . . .
}
}
Done: ;
. . . . . .
// 調用還沒有處理的事件的回調
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;
}
}
. . . . . .
// 調用全部response記錄的回調
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;
}
如今咱們能夠畫一張調用示意圖，理一下loop()函數的調用關係，以下：
pollInner()調用epoll_wait()時傳入的timeoutMillis參數，其實來自於前文所說的MessageQueue的next()函數裏的nextPollTimeoutMillis，next()函數裏在如下3種狀況下，會給nextPollTimeoutMillis賦不一樣的值：
1）若是消息隊列中的下一條消息還要等一段時間纔到時的話，那麼nextPollTimeoutMillis賦值爲Math.min(msg.when - now, Integer.MAX_VALUE)，即時間差；
2）若是消息隊列已是空隊列了，那麼nextPollTimeoutMillis賦值爲-1；
3）無論前兩種狀況下是否已給nextPollTimeoutMillis賦過值了，只要隊列中有Idle Handler須要處理，那麼在處理完全部Idle Handler以後，會強制將nextPollTimeoutMillis賦值爲0。這主要是考慮到在處理Idle Handler時，不知道會耗時多少，而在此期間消息隊列的「到時狀況」有可能已發生改變。
無論epoll_wait()的超時閥值被設置成什麼，只要程序從epoll_wait()中返回，就會嘗試處理等到的epoll事件。目前咱們的主要關心點是事件機制，因此主要討論當fd 等於mWakeReadPipeFd時的狀況，此時會調用一下awoken()函數。該函數很簡單，只是在讀取mWakeReadPipeFd而已：
void Looper::awoken() {
#if DEBUG_POLL_AND_WAKE
ALOGD("%p ~ awoken", this);
#endif
char buffer[16];
ssize_t nRead;
do {
nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
} while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer));
}
除了感知mWakeReadPipeFd管道的狀況之外，epoll還會感知其餘一些fd對應的事件。在Looper中有一個mRequests鍵值向量表（KeyedVector<int, Request> mRequests），其鍵值就是感興趣的fd。若是收到的epoll事件所攜帶的fd能夠在這張表裏查到，那麼就將該fd對應的Request整理進Response對象，並將該Response對象記入mResponses表。在pollInner()的最後，會用一個for循環遍歷mResponses表，分析每一個Response表項對應的Request是否是須要callback，若是須要的話，執行對應的回調函數：
int callbackResult = response.request.callback->handleEvent(fd, events, data);
if (callbackResult == 0) {
removeFd(fd);
}
pollInner()內部還會集中處理所記錄的全部C++層的Message。在一個while循環中，不斷摘取mMessageEnvelopes向量表的第0個MessageEnvelope，若是消息已經到時，則回調handleMessage()。
sp<MessageHandler> handler = messageEnvelope.handler; Message message = messageEnvelope.message; mMessageEnvelopes.removeAt(0); . . . . . . handler->handleMessage(message);而若是消息未到時，說明while循環能夠break了。
C++層的Looper及這個層次的消息鏈表，再加上對應其餘fd的Request和Response，能夠造成下面這張示意圖：
從咱們的分析中能夠知道，在Android中，不光是Java層能夠發送Message，C++層也能夠發送，固然，不一樣層次的Message是放在不一樣層次的消息鏈中的。在Java層，每次嘗試從隊列中獲取一個Message，然後dispatch它。而C++層的消息則儘可能在一次pollOnce中集中處理完畢，這是它們的一點不一樣。
5尾聲
關於Android的消息機制，咱們就先說這麼多。整體上的而言仍是比較簡單的，無非是經過Handler向Looper的消息隊列中插入Message，然後再由Looper在消息循環裏具體處理。由於消息隊列自己不具備鏈表一變更就能立刻感知的功能，因此它須要藉助管道和epoll機制來監聽變更。當外界向消息隊列中打入新消息後，就向管道的「寫入端」寫入簡單數據，因而epoll能夠當即感知到管道的變更，從何激發從消息隊列中摘取消息的動做。這就是Android消息機制的大致狀況。
- 1. 聊聊Android的消息機制
- 2. 聊一聊順序消息
- 3. 聊一聊順序消息（RocketMQ順序消息的實現機制）
- 4. 簡單聊聊消息隊列的事務補償機制
- 5. 聊聊artemis消息的推拉模式
- 6. 聊聊jesque的event機制
- 7. 聊聊Java的GC機制
- 8. 聊聊MQ的消息必達和消息冪等與消息延時
- 9. 聊聊Javascript 垃圾回收機制-(一)
- 10. 聊一聊HTTP緩存機制
- 更多相關文章...
- • HTTP 消息結構 - HTTP 教程
- • ARP協議的工作機制詳解 - TCP/IP教程
- • 漫談MySQL的鎖機制
- • Docker容器實戰(六) - 容器的隔離與限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 聊聊Android的消息機制
- 2. 聊一聊順序消息
- 3. 聊一聊順序消息（RocketMQ順序消息的實現機制）
- 4. 簡單聊聊消息隊列的事務補償機制
- 5. 聊聊artemis消息的推拉模式
- 6. 聊聊jesque的event機制
- 7. 聊聊Java的GC機制
- 8. 聊聊MQ的消息必達和消息冪等與消息延時
- 9. 聊聊Javascript 垃圾回收機制-(一)
- 10. 聊一聊HTTP緩存機制