本文首先從整體架構分析了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