Android多線程源碼詳解一：handler、looper、message、messageQueue
之前面試，面試官問到多線程通訊，巴拉巴拉說了些基礎實現後面試官問handlerThread的底層實現，就卡住了。所以把Android多線程的知識點複習整理一下，寫出來加深印象。
Android多線程通訊的核心是handler、looper、message、messageQueue，這篇文章就先記錄下這套系統的源碼要點，具體的實現方法下一篇文章再寫。
內容爲自己看源碼的理解，如有問題，歡迎留言探討，共同進步。
Thread
用法一：
handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
switch (msg.what) {
case 1:
mThread.setText(msg.obj.toString());
}
}
};
...new Thread(new Runnable() {
@Override
public void run() {
Log.d("coco", "thread:" + Thread.currentThread().getName());
Message message = handler.obtainMessage();
message.obj = "thread_msg";
message.what = 1;
handler.sendMessage(message);
}
}).start();主線程中初始化handler，實現handleMessage，子線程中sendMessage，實現通訊。（ps：handler內存泄漏後面寫）
方法二：
handler.post(new Runnable() {
@Override
public void run() {
Message message = Message.obtain(handler);
message.obj = "thread_msg1";
message.what = 1;
handler.sendMessage(message);
}
});這種方法跟第一種實現原理是一樣的，直接返回sendMessageDelayed(getPostMessage(r), 0)，通過getPostMessage從Runnable中獲取message，然後放到messageQueue中。
handler
handler是多線程通訊的控制器，負責消息的發送與處理，handler的初始化代碼如下：
//FIND_POTENTIAL_LEAKS爲常量，值爲false，即第一個if語句不會執行。內部的代碼邏輯是判斷handler的創建方式，決定是否需要打
//印內存泄漏的log，如果是該handler對象是通過匿名類、成員類、內部類、非靜態類的話，有可能造成內存泄漏，需要打印log
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());
}
}//首先對looper進行判空，如果爲空就拋出異常，所以如果在子線程中初始化handler，一定要先初始化looper，主線程在系統創建時就初
//始化了looper，所以可以直接創建handler。
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;mQueue是獲取的mLooper的mQueue，所以mQueue也是當前線程相關的，具體原因在looper的源碼分析中會講。mAsynchronous是判斷是否有異步消息，Android會優先處理異步消息，具體的實現在messageQueue中會講到。
public final Message obtainMessage()
{
return Message.obtain(this);
}obtainMessage方法是從message的公共池中取出一個message，相對於直接new出來，效率更高。
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}dispatchMessage方法是handler在接收到message後進行分發時調用的，msg.callback是一個Runnable對象，在message創建時傳入，或者通過setCallback方法設置，默認爲空；mCallback是Callback對象，在handler初始化的時候傳入，默認也爲空。所以沒有特定設置的情況下，會直接走到handlerMessage中，即我們創建handler時複寫的回調方法。
looper
looper的主要成員變量如下：
MessageQueue mQueue跟looper綁定的消息隊列。
Thread mThreadlooper所在線程對象。
looper的初始化代碼如下：
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));
}sThreadLocal的數據結構爲ThreadLocal，在prepare中首先判斷sThreadLocal是否爲空，表明一個線程只能有一個looper對象，符合單例模式的設計思想。
sThreadLocal.set(new Looper(quitAllowed))該方法是new一個Looper，並將該Looper與當前線程的threadLocalMap關聯起來，所以該looper屬於調用prepare方法的線程。
接下來是最重要的loop方法，loop與prepare方法都是靜態方法，通過Looper.prepare跟Looper.loop調用即可，所以在loop開始的時候要先獲取當前thread的looper與messageQueue。
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;
Binder.clearCallingIdentity();
...
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
return;
}
...
try {
msg.target.dispatchMessage(msg);
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
...
msg.recycleUnchecked();
}
}Binder.clearCallingIdentity() 方法是爲了清除當前線程傳入的IPC標識，如果在其他線程傳入IPC請求，當前線程又要調用當前線程的本地接口，先清除傳入的IPC標識，那麼調用本地接口時就不需要進行權限驗證。
然後通過 for(;;) 進行無限循環，直到queue.next不爲空，接着調用target(即當前looper綁定的handler，在handler初始化的時候綁定)的 dispatchMessage(msg) 方法，之後走到初始化handler時複寫的 handleMessage 中。
最後通過 recycleUnchecked() 將當前的msg放入到消息池中。
threadLocal、threadLocalMap
threadLocal是一個數據對象類，由該類實例化的對象是線程相關的，即不同線程通過同一個threadLocal對象操作的也是各自的線程的備份數據，該功能是由threadLocalMap實現。
threadLocalMap是一個自定義hashmap，內部持有一個tables變量，類型爲Entry[]。Entry爲threadLocalMap內部類，繼承了ThreadLocal的虛引用，以便實例化的ThreadLocal對象在不用時可以回收；內部只有一個成員變量value，這裏的結構爲Looper。
static class Entry extends WeakReference> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}threadLocalMap是Thread的一個變量，所以每一個線程只有一個threadLocalMap。
threadLocal的操作都是以threadLocalMap來實現的，如get()方法，首先獲取當前Thread，然後通過獲取Thread的threadLocalMap，然後map.getEntry(this)(傳入this是因爲自定義hashmap的hash算法需要用到threadLocal中的threadLocalHashCode變量)獲取當前線程對應的value(looper)，以保證在子線程中處理的looper、message都是主線程的looper、message，避免了不同線程數據的同步問題。
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}其他的set、setInitialValue等方法也是跟get類似，通過threadLocalMap實現。
由上面的代碼可以看出，整個多線程通訊的核心就是threadLocal與threadLocalMap。以普通的子線程發送消息，主線程接收消息的demo爲例：handler在主線程創建，所以在初始化時綁定的looper是主線程的looper；主線程的looper在初始化的時候調用prepare，跳轉到構造函數創建實例的時候會創建messageQueue並綁定，所以messageQueue也是對應的主線程的looper的內部隊列；message無論是obtain還是new出來的，在通過sentMessage發出後，會綁定到當前handler上。綜上所述，雖然消息的創建與發送都是在子線程中完成，但由於threadLocal機制，這一系列的實例都是在主線程中完成的，所以不會有不同線程通訊的同步問題。
message
message是handler機制中的信息載體，實現了Parcelable接口，主要通過一下變量保存數據：
int what整形變量，讓接受者區分message的標識。
int arg1, arg2整形變量，可存儲簡單的int數據。
Object obj發送任意Object對象給接受者。
target message所關聯的handler
message的初始化推薦通過Handler.obtainMessage()或者Message.obtain(Handler h)，會返回消息池中的message，避免了message的創建與銷燬，效率更高。
首先看一下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();
}sPool是消息池，實際結構爲Message，通過next對象指向下一個message，然後一串message構成消息池。消息池的上限是50，沒有初始化，所以第一次調用obtain的時候，也是通過new Message創建的對象，在每次looper.loop()中獲取到消息後，將處理完的message通過recycleUnchecked方法添加到消息池中，直到達到上限 50，在達到上限50前，消息都不銷燬，只會將成員變量初始化。
無論是通過Handler.obtainMessage()還是直接通過Message.obtain(Handler h)，都會調用Message.obtain()，然後將target設爲綁定的handler對象，該方法會先判斷sPool是否爲空，如果不爲空，就將sPool返回，然後將sPool指向下一個Message。
message queue
消息隊列，實際數據結構爲鏈表，模擬的隊列特性，初始化、銷燬等操作的實現都在native層。
mQuitAllowed Boolean變量，標識messageQueue是否可以中止。
messageQueue中的 enqueueMessage 方法是消息隊列的入隊方法，在handler調用sendMessage後，會調用該方法將msg放入到消息隊列中。
boolean enqueueMessage(Message msg, long when) {
//判斷入隊的消息的tartget是否爲空，類型爲handler，即判斷message是否綁定了handler
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
//判斷msg是否被使用，由msg的flag變量與常量的位運算結果控制
//初始化的message的flag默認爲0，計算結果爲未使用；
//使用後flag變爲1，計算結果爲已使用；
//如果該msg爲異步消息，flag爲2.
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
msg.markInUse(); //將msg標記爲已使用
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// 如果消息隊列爲空，將mMessages指向msg，msg的next指向空節點，入隊完成
msg.next = p;
mMessages = msg;
//needWeke標識隊列是否需要喚醒，默認的mBlocked爲false，looper調用loop開始輪訓後設爲true
needWake = mBlocked;
} else {
// 根據mBlocked、是否是同步屏障message、該消息是否是異步的判斷是否需要喚醒隊列
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
//如果消息隊列不爲空，採用尾插法將新的msg插入到隊尾，但mMessages仍指向第一個message
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;
}
// 如果需要，則喚醒隊列，具體喚醒操作在native層實現
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}看完了消息的入隊，再看一下消息的出隊，消息的出隊是通過next()方法實現的,裏面的東西比較多，只看下主要邏輯。
Message next() {
...
// 開始循環，判斷需要返回哪一個message
for (;;) {
...
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
//msg.target爲空，說明碰到了同步屏障，出循環後，prevMsg指向同步屏障，msg指向最近的一個異步消息
//同步屏障由postSyncBarrier方法添加，再使用完後需要刪除屏障，否則會一直循環查找異步消息，無法拋出同步消息
if (msg != null && msg.target == null) {
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 {
mBlocked = false;
if (prevMsg != null) {
//prevMsg不爲空，說明prevMsg指向同步屏障，說明msg指向異步消息，需要優先拋出異步消息
prevMsg.next = msg.next;
} else {
//prevMsg爲空，說明沒有異步消息，拋出msg，將mMessages指向下一個message
mMessages = msg.next;
}
//清空msg的next節點，並設爲使用中，然後返回
msg.next = null;
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;
}
...
}
}上述next方法中，返回需要處理的message，優先處理異步消息，消息處理按照先進先出的順序執行。
異步消息的處理時間更快，需要將消息設爲異步(message.setAsynchronous(true))，並配合postSyncBarrier、removeSyncBarrier實現。postSyncBarrier是往隊列中添加同步屏障，removeSyncBarrier是刪除隊列中的同步屏障，如果只添加沒有刪除，那麼next無法拋出同步消息。
private int postSyncBarrier(long when) {
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，只不過target爲null，不同於普通message的尾插法，同步屏障是通過頭插法實現的，所以next拋出message的時候回直接處理異步消息。
同步屏障的刪除源碼比較簡單，這裏就不貼出來了。只說明一下，同步屏蔽刪除後也會優先加入消息緩衝池中，消息池滿了後才銷燬。
messageQueue雖然叫消息隊列，但實際的邏輯結構是message組成的鏈表，普通情況下模擬的隊列的先進先出的特性，但遇到異步消息時，也不會完全遵守隊列特性，實現頭部插入功能。
原文地址https://www.cnblogs.com/zhangzhonghao/p/10678786.html