Android應用程序是通過消息來驅(qū)動的，系統(tǒng)為每一個應用程序維護一個消息隊例，應用程序的主線程不斷地從這個消息隊例中獲取消息(Looper)， 然后對這些消息進行處理(Handler)，這樣就實現(xiàn)了通過消息來驅(qū)動應用程序的執(zhí)行，本文將詳細分析Android應用程序的消息處理機制。

前面我們學習Android應用程序中的Activity啟動(Android應用程序啟動過程源代碼分析和Android應用程序內(nèi)部啟動 Activity過程(startActivity)的源代碼分析)、Service啟動(Android系統(tǒng)在新進程中啟動自定義服務過程 (startService)的原理分析和Android應用程序綁定服務(bindService)的過程源代碼分析)以及廣播發(fā)送(Android應 用程序發(fā)送廣播(sendBroadcast)的過程分析)時，它們都有一個共同的特點，當ActivityManagerService需要與應用程序 進行并互時，如加載Activity和Service、處理廣播待，會通過Binder進程間通信機制來知會應用程序，應用程序接收到這個請求時，它不是 馬上就處理這個請求，而是將這個請求封裝成一個消息，然后把這個消息放在應用程序的消息隊列中去，然后再通過消息循環(huán)來處理這個消息。這樣做的好處就是消 息的發(fā)送方只要把消息發(fā)送到應用程序的消息隊列中去就行了，它可以馬上返回去處理別的事情，而不需要等待消息的接收方去處理完這個消息才返回，這樣就可以 提高系統(tǒng)的并發(fā)性。

實質(zhì)上，這就是一種異步處理機制。

這樣說可能還是比較籠統(tǒng)，我們以Android應用程序啟動過程源代碼分析一文中所介紹的應用程序啟動過程的一個片斷來具體看看是如何這種消息處理機制的。

在這篇文章中，要啟動的應用程序稱為Activity，它的默認Activity是MainActivity，它是由Launcher來負責啟動 的，而Launcher又是通過ActivityManagerService來啟動的，當ActivityManagerService為這個即將要啟 的應用程序準備好新的進程后，便通過一個Binder進程間通信過程來通知這個新的進程來加載MainActivity，如下圖所示：

它對應Android應用程序啟動過程中的Step 30到Step 35，有興趣的讀者可以回過頭去參考Android應用程序啟動過程源代碼分析一文。這里的Step 30中的scheduleLaunchActivity是ActivityManagerService通過Binder進程間通信機制發(fā)送過來的請求， 它請求應用程序中的ActivityThread執(zhí)行Step 34中的performLaunchActivity操作，即啟動MainActivity的操作。這里我們就可以看到，Step 30的這個請求并沒有等待Step 34這個操作完成就返回了，它只是把這個請求封裝成一個消息，然后通過Step 31中的queueOrSendMessage操作把這個消息放到應用程序的消息隊列中，然后就返回了。應用程序發(fā)現(xiàn)消息隊列中有消息時，就會通過 Step 32中的handleMessage操作來處理這個消息，即調(diào)用Step 33中的handleLaunchActivity來執(zhí)行實際的加載MainAcitivy類的操作。

了解Android應用程序的消息處理過程之后，我們就開始分樣它的實現(xiàn)原理了。與Windows應用程序的消息處理過程一樣，Android應用程序的消息處理機制也是由消息循環(huán)、消息發(fā)送和消息處理這三個部分組成的，接下來，我們就詳細描述這三個過程。

1. 消息循環(huán)

在消息處理機制中，消息都是存放在一個消息隊列中去，而應用程序的主線程就是圍繞這個消息隊列進入一個無限循環(huán)的，直到應用程序退出。如果隊列中有消 息，應用程序的主線程就會把它取出來，并分發(fā)給相應的Handler進行處理;如果隊列中沒有消息，應用程序的主線程就會進入空閑等待狀態(tài)，等待下一個消 息的到來。在Android應用程序中，這個消息循環(huán)過程是由Looper類來實現(xiàn)的，它定義在frameworks/base/core/java /android/os/Looper.java文件中，在分析這個類之前，我們先看一下Android應用程序主線程是如何進入到這個消息循環(huán)中去的。