Handler的那些事
- 相關的類：Handler、Looper、Message、MessageQueue、AsyncTask、FetureTask、SerieExctor、IntentService
- Handler最大的作用就是線程間通訊，使得多個線程的數據（前提是同一個進程，這是默認條件，后續不再提及），匯集到一個統一的地方來處理，其機制是大體來說，在任意線程中產生的數據，通過某種方式加入到全局唯一的消息隊列（MessageQueue），而在處理中心的線程，有一個永動機Looper，不斷的輪詢MessageQueue，獲取隊列中的Message。
初始化
首先來關注Looper，Looper的初始化，是在android.app.ActivityThread的main方法中可以看到它初始化的過程：
public static void main(String[] args) {
...
Looper.prepareMainLooper();
...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
Looper.prepareMainLooper()就是初始化了全局唯一的sMainLooper：
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
監聽待處理的Message消息
隨后，執行到Looper.loop();而在其后，程序竟然也就終了，真可以說，Looper的執行時間，也就是程序執行的時間了，接下來看看這個神奇的方法：
public static void loop() {
...
for (;;) {
Message msg = queue.next(); // might block
...
msg.target.dispatchMessage(msg);
...
}
}
很明顯，這是一個阻塞式的無限循環，阻塞處就是queue.next();
拿到消息后的分發處理
而當拿到Message對象后，會調用其target的dispatchMessage方法，這個target其實就是Handler，也就是說這里會執行到Handler的dispatchMessage方法，再跟進：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
msg.callback.run();
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
這里可以發現，Message的callback，擁有最先的處理權；其次是Handler的mCallback；最后才是handleMessage方法，這也是我們定義Handler時常常復寫的方法，用來實現收到消息后的處理邏輯，該方法能執行取決于兩個條件：Message沒有自己的callback，并且Handler的mCallback為空或者mCallback的handleMessage方法返回false（這也是Handler的消息攔截機制，在這里我們可以做一些msg的過濾）。
看到這里大家可能有點奇怪，窩草，什么鬼，你Message好容易發過來，讓我Handler逮著了，結果你自己的callback又搶走了執行權，逗哥玩呢？
呵呵，可能還是源碼看少了啊，還記不記得Handler了一個常規用法，就是在子線程里面我們要更新ui的經典寫法：mHandler.post(new Runnable(){...})，跟下源碼我們會發現，這個Runnable會被包裝成一個Message對象，然后post到主線程，于是在上面dispatchMessage的邏輯中，執行我們定義在這個Ruannable的run方法里的邏輯，通過這么一圈繞，實現了在mHandler定義的線程執行run里的方法...嗯，確實繞，但就是這么個原理了。
public final boolean post(Runnable r){
return sendMessageDelayed(getPostMessage(r), 0);
}
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
接著聊，還有第二處理優先權的Handler中的mCallback，它只在Handler構造中被初始化，并且是final的，上面有說到這是Handler消息的一種過濾機制。于是創建Handler時有兩種等價的寫法：
Handler myHandler1 = new Handler(){
@Override
public void handleMessage(Message msg) {
...
super.handleMessage(msg);
}
};
Handler myHandler2 = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
...
return false;
}
});
好了，消息Message的處理流程大致上說完了，接下來聊聊Message的發送流程。
消息發送-Message對象獲取
Message可以直接通過new關鍵字來創建對象，但是更推薦使用Message.obtain()的方式，包括myHandler.obtainMessage()都是一樣的，這里使用了消息池(message pool)來管理消息，來看源碼：
Handler類中：
public final Message obtainMessage(){
return Message.obtain(this);
}
Message類中：
public static Message obtain(Handler h) {
Message m = obtain();
m.target = h;
return m;
}
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
}
}
return new Message();
}
消息發送-添加消息到消息列表
Handler的一堆post方法，無論是Runnable，還是EmptyMessage，最終都是得到一個Message對象，然后通過enqueueMessage方法，將其加入到MessageQueue中：
Handler類：
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
MessageQueue：
boolean enqueueMessage(Message msg, long when) {
...
synchronized (this) {
...
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
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.
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()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
這里的代碼比較高能，我們發現他并沒有用一個列表或者隊列的數據結構來維護，而是用mMessages來表示當前等待處理的Message，每一個Message的實例中指定了他的后繼節點Message，以此來環環相扣形成一個Message的鏈表，enqueueMessage方法的核心邏輯就是通過比對Message的when值，從小到大排序，把需要添加進隊列的Message安排到正確的位置。
消息發送撤回機制
我們知道Handler發送的延時消息是可以取消撤回的，他提供了removeXXX系列api來做這個事，最終都是調用MessageQueue的removeXXX方法：
public final void removeCallbacks(Runnable r){
mQueue.removeMessages(this, r, null);
}
public final void removeMessages(int what) {
mQueue.removeMessages(this, what, null);
}
...
MessageQueue類：
void removeCallbacksAndMessages(Handler h, Object object) {
...
synchronized (this) {
Message p = mMessages;
// Remove all messages at front.
while (p != null && p.target == h
&& (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 && (object == null || n.obj == object)) {
Message nn = n.next;
n.recycleUnchecked();
p.next = nn;
continue;
}
}
p = n;
}
}
}
可以看到，這是與添加進隊列類似的處理手法，都是遍歷待處理的Message鏈表，符合移除條件的Message對象，都會執行recycleUnchecked()清理，這些對象并不會被銷毀，而是清理完畢后進入消息池等待復用：
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
