Android中的Handler, Looper, MessageQueue和Thread

前幾天，和同事探討了一下Android中的訊息機制，探究了訊息的傳送和接收過程以及與執行緒之間的關係。雖然我們經常使用這些基礎的東西，但對於其內部原理的瞭解，能使我們更加容易、合理地架構系統，並避免一些低階錯誤。

對於這部分的內容，將分成4小節來描述：

1.職責與關係

2.訊息迴圈

3.執行緒與更新

4.幾點小結

--------------------------------------------------------------------------------------------------

1）接下來，我們開始這部分的內容，首先了解一下各自的職責及相互之間的關係。

職責

Message：訊息，其中包含了訊息ID，訊息處理物件以及處理的資料等，由MessageQueue統一列隊，終由Handler處理。

Handler：處理者，負責Message的傳送及處理。使用Handler時，需要實現handleMessage(Message msg)方法來對特定的Message進行處理，例如更新UI等。

MessageQueue：訊息佇列，用來存放Handler傳送過來的訊息，並按照FIFO規則執行。當然，存放Message並非實際意義的儲存，而是將Message以連結串列的方式串聯起來的，等待Looper的抽取。

Looper：訊息泵，不斷地從MessageQueue中抽取Message執行。因此，一個MessageQueue需要一個Looper。

Thread：執行緒，負責排程整個訊息迴圈，即訊息迴圈的執行場所。

關係

Handler，Looper和MessageQueue就是簡單的三角關係。Looper和MessageQueue一一對應，建立一個Looper的同時，會建立一個MessageQueue。而Handler與它們的關係，只是簡單的聚集關係，即Handler裡會引用當前執行緒裡的特定Looper和MessageQueue。

這樣說來，多個Handler都可以共享同一Looper和MessageQueue了。當然，這些Handler也就執行在同一個執行緒裡。

2）接下來，我們簡單地看一下訊息的迴圈過程：

生成

Message msg = mHandler.obtainMessage();

msg.what = what;

msg.sendToTarget();

傳送

MessageQueue queue = mQueue;

if (queue != null) {

msg.target = this;

sent = queue.enqueueMessage(msg, uptimeMillis);

}

在Handler.java的sendMessageAtTime(Message msg, long uptimeMillis)方法中，我們看到，它找到它所引用的MessageQueue，然後將Message的target設定成自己（目的是為了在處理訊息環節，Message能找到正確的Handler），再將這個Message納入到訊息佇列中。

抽取

Looper me = myLooper();

MessageQueue queue = me.mQueue;

while (true) {

Message msg = queue.next(); // might block

if (msg != null) {

if (msg.target == null) {

// No target is a magic identifier for the quit message.

return;

}

msg.target.dispatchMessage(msg);

msg.recycle();

}

在Looper.java的loop()函式裡，我們看到，這裡有一個死迴圈，不斷地從MessageQueue中獲取下一個（next方法）Message，然後通過Message中攜帶的target資訊，交由正確的Handler處理（dispatchMessage方法）。

處理

if (msg.callback != null) {

handleCallback(msg);

} else {

if (mCallback != null) {

if (mCallback.handleMessage(msg)) {

return;

}

handleMessage(msg);

}

在Handler.java的dispatchMessage(Message msg)方法裡，其中的一個分支就是呼叫handleMessage方法來處理這條Message，而這也正是我們在職責處描述使用Handler時需要實現handleMessage(Message msg)的原因。

至於dispatchMessage方法中的另外一個分支，我將會在後面的內容中說明。

至此，我們看到，一個Message經由Handler的傳送，MessageQueue的入隊，Looper的抽取，又再一次地回到Handler的懷抱。而繞的這一圈，也正好幫助我們將同步操作變成了非同步操作。

3）剩下的部分，我們將討論一下Handler所處的執行緒及更新UI的方式。

在主執行緒（UI執行緒）裡，如果建立Handler時不傳入Looper物件，那麼將直接使用主執行緒（UI執行緒）的Looper物件（系統已經幫我們建立了）；在其它執行緒裡，如果建立Handler時不傳入Looper物件，那麼，這個Handler將不能接收處理訊息。在這種情況下，通用的作法是：

class LooperThread extends Thread {

public Handler mHandler;

public void run() {

Looper.prepare();

mHandler = new Handler() {

public void handleMessage(Message msg) {

// process incoming messages here

}

};

Looper.loop();

}

在建立Handler之前，為該執行緒準備好一個Looper（Looper.prepare），然後讓這個Looper跑起來（Looper.loop），抽取Message，這樣，Handler才能正常工作。

因此，Handler處理訊息總是在建立Handler的執行緒裡執行。而我們的訊息處理中，不乏更新UI的操作，不正確的執行緒直接更新UI將引發異常。因此，需要時刻關心Handler在哪個執行緒裡建立的。

如何更新UI才能不出異常呢？SDK告訴我們，有以下4種方式可以從其它執行緒訪問UI執行緒：

· Activity.runOnUiThread(Runnable)

· View.post(Runnable)

· View.postDelayed(Runnable, long)

· Handler

其中，重點說一下的是View.post(Runnable)方法。在post(Runnable action)方法裡，View獲得當前執行緒（即UI執行緒）的Handler，然後將action物件post到Handler裡。在Handler裡，它將傳遞過來的action物件包裝成一個Message（Message的callback為action），然後將其投入UI執行緒的訊息迴圈中。在Handler再次處理該Message時，有一條分支（未解釋的那條）就是為它所設，直接呼叫runnable的run方法。而此時，已經路由到UI執行緒裡，因此，我們可以毫無顧慮的來更新UI。

4）幾點小結

· Handler的處理過程執行在建立Handler的執行緒裡

· 一個Looper對應一個MessageQueue

· 一個執行緒對應一個Looper

· 一個Looper可以對應多個Handler

· 不確定當前執行緒時，更新UI時儘量呼叫post方法

http://www.cnblogs.com/xirihanlin/archive/2011/04/11/2012746.html

Android中的Handler, Looper, MessageQueue和Thread

相關文章