【Android自助餐】Handler訊息機制完全解析（二）MessageQueue的佇列管理
Android自助餐Handler訊息機制完全解析（二）MessageQueue的佇列管理
關於這個佇列先說明一點，該佇列的實現既非Collection的子類，亦非Map的子類，而是Message本身。因為Message本身就是連結串列節點（見Message中obtain()與recycle()的來龍去脈）。
佇列中的Message mMessages;成員即為佇列，同時該欄位直接指向佇列中下一個需要處理的訊息。
新增到訊息佇列enqueueMessage()
要將message新增到佇列除了提供message之外，還需提供訊息觸發時間when。
如果當前佇列為空則直接mMessage=message即可。否則就需要逐個對比佇列中每個message的when和新訊息的when來確定新訊息在佇列中的位置。
先給出核心原始碼（有刪減）
Message p = mMessages;
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
} else {
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
}
msg.next = p;
prev.next 先看下新訊息需要放到隊頭的情況：p == null || when == 0 || when < p.when。即佇列為空，或者新訊息需要立即處理，或者新訊息處理的事件比隊頭訊息更早被處理。這時只要讓新訊息的next指向當前隊頭，讓mMessages指向新訊息即可完成插入操作。
除了上述三種情況就需要遍歷佇列來確定新訊息位置了，下面結合示意圖來說明。
假設當前訊息佇列如下
開始遍歷：p向隊尾移，引入prev指向p上一個元素
假設此時p所指訊息的when比新訊息晚，則新訊息位置在prev與p中間
最後便是呼叫native方法來喚醒（Linux的epoll，有興趣的自行百度）。
從佇列取出訊息next()
這部分內容有點高能，請根據個人BPU(BrainProcessUnit)酌情理解。
首先這個方法需要返回Message，那麼我們現在來看看哪裡有return。（共三段，我們最後看第二段。）
第一段
final long ptr = mPtr;
if (ptr == 0) {
return null;
}如果mPtr為0則返回null。那麼mPtr是什麼？值為0又意味著什麼？在MessageQueue構造方法中呼叫了native方法並返回了mPtrmPtr = nativeInit();；在dispose()方法中將其值置0mPtr = 0;並且呼叫了nativeDestroy()。而dispose()方法又在finalize()中被呼叫。另外每次mPtr的使用都呼叫了native的方法，其本身又是long型別，因此推斷它對應的是C/C++的指標。因此可以確定，mPtr為一個記憶體地址，當其為0說明訊息佇列被釋放了。這樣就很容易理解為什麼mPtr==0的時候返回null了。
第三段
你沒有看錯，第二段在後面
if (mQuitting) {
dispose();
return null;
}這裡的意思也很明顯，當這個訊息佇列退出的時候，返回空。而且在返回前呼叫了dispose()方法，顯然這意味著該訊息佇列將被釋放。
第二段
這部分涉及到的程式碼基本上就是這個next()方法本身了，但可以肯定的是這裡的返回語句是return msg;。同時從enqueueMessage()方法可以看出來，在這個佇列中取到的message物件不可能為空，因此這裡的返回絕對不為空。
如此一來就可以得出一個結論：如果next()方法為空說明這個訊息佇列正在退出或將被釋放回收。
繼續來看這個next()，這個程式碼有點長，所以先做個減法。
第一個要減的就是pendingIdleHandlerCount，這個區域性變數初始為-1，後面被賦值mIdleHandlers.size();。這裡的mIdleHandlers初始為new ArrayList<IdleHandler>()，在addIdleHander()方法中增加元素，在removeIdleHander()方法中移除元素。而我們所用的Handeler並未實現IdleHandler介面，因此在next()方法中pendingIdleHandlerCount的值要麼為0，要麼為-1，因此可以看出與該變數相關的部分程式碼執行情況是確定的，好的，把不影響迴圈控制的程式碼減掉。
第二個要減的是Binder.flushPendingCommands()這個程式碼看原始碼說明：
Flush any Binder commands pending in the current thread to the kernel driver. This can be useful to call before performing an operation that may block for a long time, to ensure that any pending object references have been released in order to prevent the process from holding on to objects longer than it needs to.
這段話啥意不懂也沒關係，這裡只需要知道：Binder.flushPendingCommands()方法被呼叫說明後面的程式碼可能會引起執行緒阻塞。然後把這段減掉。
第三個要減的是一個log語句if (DEBUG) Log.v(TAG, "Returning message: " + msg);
第四個要減的是上面提到的“第一段”返回null的語句，但是“第三段”得留著。
最後再把註釋幹掉給上程式碼：
Message next() {
int nextPollTimeoutMillis = 0;
for (;;) {
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
msg.markInUse();
return msg;
}
} else {
nextPollTimeoutMillis = -1;
}
if (mQuitting) {
dispose();
return null;
}
if (pendingIdleHandlerCount <= 0) {//上面分析過該變數要麼為0要麼為-1
mBlocked = true;
continue;
}
}
nextPollTimeoutMillis = 0;
}
}雖然還是很長，但也不能再減了。大致思路如下：先獲取第一個同步的message。如果它的when不晚與當前時間，就返回這個message；否則計算當前時間到它的when還有多久並儲存到nextPollTimeMills中，然後呼叫nativePollOnce()來延時喚醒（Linux的epoll，有興趣的自行百度），喚醒之後再照上面那樣取message，如此迴圈。程式碼中對連結串列的指標操作佔了一定篇幅，其他的邏輯很清楚，就不一句句分析了。
從佇列移除訊息removeMessages()
該方法有2個過載，除此之外還有removeCallbacksAndMessages()等方法也可以移除訊息。但程式碼段都基本一樣，這裡以void removeMessages(Handler h, int what, Object object){}方法為例。
該方法完整原始碼如下
void removeMessages(Handler h, int what, Object object) {
if (h == null) {
return;
}
synchronized (this) {
Message p = mMessages;
// Remove all messages at front.
while (p != null && p.target == h && p.what == what
&& (object == null || p.obj == object)) {
Message n = p.next;
mMessages = n;
p.recycleUnchecked();
p = n;
}
// Remove all messages after front.
while (p != null) {
Message n = p.next;
if (n != null) {
if (n.target == h && n.what == what
&& (object == null || n.obj == object)) {
Message nn = n.next;
n.recycleUnchecked();
p.next = nn;
continue;
}
}
p = n;
}
}
}最開始判斷handler是否為空不必多說，然後便是同步程式碼段，只裡面有兩個while迴圈。為什麼有兩個呢？學過資料結構連結串列的都知道，連結串列分兩種：帶頭結點和不帶頭結點。而這兩種連結串列的遍歷方式有所不同：不帶頭結點的連結串列中，第一個元素需要單獨處理，然後才能將後續部分當做帶頭結點的連結串列來使用while迴圈遍歷。可以看出MessageQueue是不帶頭結點的連結串列，而且遍歷過程中有需要刪除節點，因此要特殊處理的不只是第一個元素，而是第一組符合刪除條件的元素。有點暈了是吧，不要緊，我們開始鬥圖。
第一個while
假設需要遍歷的訊息佇列如圖所示。
為了讓第一個while可以執行，我們假設前3個元素符合移除條件，即前三個Message的targe、what、obj分別與指定的handler、what、object相同。首先第一個元素滿足條件進行如下操作：
執行n=p.next;
後移mMessage；
回收p指向的元素，即第一個元素。
讓p指向新的隊頭。
此時又與初始佇列狀態一樣了。先前我們假設隊頭有三個元素符合移除條件，因此再迴圈執行上面4圖2邊後又得到初始狀態的佇列，此時隊頭元素不滿足移除條件因此while終止，同時新的佇列變成了“帶頭結點的連結串列”，因此mMessage指向的元素永遠不用被判斷是否滿足移除條件。
第二個while
此時訊息佇列狀態如下：
執行n=p.next;
假設n指向的元素不滿足移除條件，則只需要將p和n後移，如此也說明，p指向的元素總是已經被判斷過不滿足移除條件的。這部分邏輯很簡單到給圖就是看不起讀者的智商，現在我們假設n指向的元素滿足移除條件，即當前佇列如下：
執行nn=n.next;
回收n指向的元素
執行p.next=nn;
這時p之後的佇列又是一個帶頭結點的連結串列。可以繼續while了。