本文首先從整體架構分析了Android整個線程間消息傳遞機制，然後從源碼角度介紹了各個組件的作用和完成的任務。文中並未對基礎概念進行介紹，關於threadLacal和垃圾回收等等機制請自行研究。
基礎架構
首先，我們需要從整體架構上了解一下Android線程通信都做了哪些工作。我們都知道，進程是操作系統分配資源的最小單位，一個進程中可以啟動多個線程來執行任務，這些線程可以共享進程的資源但不分配資源，這裡講的資源主要是只內存資源。Android的線程間消息傳遞機制其實和我們現實生活人們通信中很相似，我們可以類比一下兩個人的通信過程：假設A要給B寫信，首先將信寫好裝入信封（Message），交給B的郵遞員（handler）投入B的信箱（messageQueue）中，B的管家（looper）發現有信件需要查收，就交給B來處理。下圖是其余線程向主線程發送消息的示意圖：
整個過程如下：
子線程通過主線程的handler發送一條消息給主線程；
這條線程被放入主線程的消息隊列中；
整個消息隊列是由looper來創建和管理的，通過輪詢一旦發現有新消息存在就取出交給主線程處理。
組件源碼分析
了解過整個架構之後，我們就從源碼的角度體會一下Android線程之間通信機制的精妙設計吧。
信封message
Message類作為發送給handler的消息，其中封裝了一份對於消息的描述以及需要傳遞的數據對象。關於消息回收機制我們放在後面的文章中介紹，這裡先只把它當作封裝了要傳遞數據的消息類。首先，兩個int成員變量和一個obj對象用於存儲被傳遞的數據：
what： 用戶自定義的消息碼，用於消息接收者識別該消息的類型。
arg1、arg2： 如果只傳遞int值，可以采用這兩個參數存儲。
obj ： 可以存放需要傳遞的數據對象。
還有一些成員變量也需要簡單了解一下：
通過obtain方法可以獲取一條message對象使用（工廠模式）：
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();
}
還有一些關於成員變量的存取方法，就不一一介紹了，我們使用的時候只需要獲取到message對象，將要傳遞的數據放入該對象中就OK了。然後我們需要調用sendToTarget方法把這個消息發送出去：
/**
* Sends this Message to the Handler specified by {@link #getTarget}.
* Throws a null pointer exception if this field has not been set.
*/
public void sendToTarget() {
target.sendMessage(this);
}
當然，你要指明要把該消息交給哪個handler來處理，不然會報空指針喲。方法中調用了handler的sendMessage方法，下面我們來研究一下handler。
郵遞員handler
handler其實並不僅僅像是傳統意義上的郵遞員而已，因為handler既負責在子線程中發送消息到主線程的messageQueue中，又負責在主線程中從looper中取出消息進行處理，你見過有這麼周到的郵遞員嗎？一個handler實例只為一個線程以及其消息隊列服務，當你在某個線程中創建一個handler實例對象，那麼該handler對象就與該線程和它的消息隊列綁定在一起，並開始為它們進行服務了。另外需要提到的一點是，這裡的消息並不僅僅是指數據，也可以是能被主線程執行的Runnable對象。
當應用程序的進程創建後，它的主線程維護了一個消息隊列用於管理那些頂層的應用組件（activity，broadcast receiver等）以及創建出來的窗口。而你自己開啟的線程可以通過handler與主線程通信，在合適的時候執行任務，或者處理消息等等。
首先，我們看看如何創建一個handler，構造方法如下：
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();// 獲取到當前線程的looper
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;// 獲取到looper管理的消息隊列
mCallback = callback;// 自定義的回調函數
mAsynchronous = async;
}
其中有關內存洩露問題我們稍後再談。先關注一下我們的handler在創建時做了哪些工作。在談論整個通信機制的時候我們說過，一個線程只能有一個looper用來輪詢唯一的一個消息隊列，即線程，looper，消息的隊列的關系是一一對應的。而handler和looper之間是一對多的關系，即一個looper可以由多個handler來為它服務。在handler的構造函數中，主要工作就是把handler和它要服務的looper，消息隊列關聯起來。
handler可以向隊列中發送消息或者添加一個可執行的runnable對象，消息隊列會安排在某一時刻進行消息處理或者執行runnable對象run方法：
•post(Runnable r)：將runnable對象加入消息隊列，該runnable對象將會被消息隊列所在線程執行。
•postAtTime(Runnable, long)： 將runnable對象加入消息隊列，在指定的時間執行該runnable對象。
•postDelayed(Runnable r, long delayMillis)：將runnable對象加入消息隊列，經過指定延遲時間後執行。
•sendEmptyMessage(int what)：將一條僅包含what值的消息發送給消息隊列
•sendMessage(Message msg)：將一條消息加入消息隊列
•sendMessageAtTime(Message msg, long uptimeMillis)：在指定時間將一條消息加入隊列尾部
•sendMessageDelayed(Message msg, long delayMillis)： 在經過指定時間延遲後，將一條消息加入隊列尾部
通過這些方法，handler將message對象交給了消息隊列messageQueue。looper從消息隊列中取出message後，會調用message所持有的handlerdispatch方法，分發給handler來處理該消息：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {// 如果message對象持有回調對象，則執行它
handleCallback(msg);
} else {
if (mCallback != null) {// 如果當前handler持有消息處理的回調函數，則執行它
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);// 如果都沒有，則執行用戶自定義的消息處理方法
}
}
管家Looper和信箱MessageQueue
從上面的分析我們可以了解，message對象是通過handler間接的加入到消息隊列中的，然後消息隊列將message對象組織成一個隊列提供給looper分發。如果只看名字，我們會猜想這個類中使用隊列這種數據結構來組織message，然而並不是這樣的。MessageQueue將message對象按時間順序組織成一個鏈表的形式來管理。
在創建handler對象的時候，我們通過looper.myLooper方法從threadLocal中獲取到與當前線程一一對應的looper對象。那麼當前線程是何時創建了整個looper對象並將其放入threadLocal呢？在Android的UI線程中，早已自動替我們創建好了looper；而如果是我們自己創建的線程，那麼就需要調用prepare方法來創建出looper對象：
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對象的時候也創建了它要輪詢的消息隊列，並獲取了當前線程的引用：
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
由於線程和looper對象是一一對應的關系，所以我們有時候判斷���前線程是否為UI線程的時候，會調用getMainLooper方法來判斷：
public static Looper getMainLooper() {
synchronized (Looper.class) {
return sMainLooper;
}
}
looper對象持有它所輪詢的消息隊列的對象，通過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;// 獲取到當前的消息隊列
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
// 開始輪詢消息隊列
for (;;) {
// 從消息隊列中獲取下一條message，有可能會阻塞
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
// 把從隊列中取到的message交給handler來處理
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}
// 標記該消息已經被處理過，可以被回收
msg.recycleUnchecked();
}
}
到此為止，在子線程中創建的message對象就被處理好了。下面我們需要談論一下handler的洩露問題以及解決方法。
Handler洩露問題
談論整個問題之前，我們需要了解JAVA的GC機制，這裡就不做詳細介紹了。當我們在activity中創建一個handler對象時，往往會繼承一個匿名內部類，裡面復寫了handler的handleMessage方法。這時，該匿名內部類就會持有當前activity的對象引用。同時，持有該handler的子線程對象往往會進行一些耗時的操作，創建message對象並把handler對象的引用賦給它。此時如果用戶關閉了activity，那麼此activity對象是應該被系統回收的。但是，由於子線程的耗時操作，並且它和未處理的message對象都持有handler的引用，而handler又持有activity的引用，這就會導致該activity無法回收，出現內存洩露。
目前主要有兩種解決方案：
•第一種，在activity關閉時，停掉該子線程，然後調用handler的removeCallbacks方法，把消息隊列中的message刪除掉。
•第二種，讓匿名內部類作為一個靜態內部類出現，這樣就不持有activity的對象引用了，activity就可以被回收掉了。但是，不持有activity的引用，怎麼操作其中的對象呢？只好自己聲明一個弱引用了：
static class myHandler extends Handler {
WeakReference<Activity > mActivityReference;
myHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
//消息處理......
}
}
弱引用在垃圾回收的時候會被忽略，所以可以被安全回收。個人比較傾向於第二種寫法，比較簡單。
總結
本文簡單介紹了Android系統線程之間異步通信的機制，從源碼的角度簡單談論了線程通信時的基本工作。其中未詳細深入到messageQueue的具體管理操作，只是簡單提及了message對象的回收，具體細節有空再補上。
更多Android相關信息見Android 專題頁面 http://www.linuxidc.com/topicnews.aspx?tid=11
