Android应用程序消息处理机制（Looper、Handler）分析
文章轉(zhuǎn)載至CSDN社區(qū)羅升陽(yáng)的安卓之旅，原文地址：http://blog.csdn.net/luoshengyang/article/details/6817933
Android應(yīng)用程序是通過(guò)消息來(lái)驅(qū)動(dòng)的，系統(tǒng)為每一個(gè)應(yīng)用程序維護(hù)一個(gè)消息隊(duì)例，應(yīng)用程序的主線程不斷地從這個(gè)消息 隊(duì)例中獲取消息（Looper），然后對(duì)這些消息進(jìn)行處理（Handler），這樣就實(shí)現(xiàn)了通過(guò)消息來(lái)驅(qū)動(dòng)應(yīng)用程序的執(zhí)行，本文將詳細(xì)分析Android 應(yīng)用程序的消息處理機(jī)制。
?? ? ? ?前面我們學(xué)習(xí)Android應(yīng)用程序中的Activity啟動(dòng)（Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析和Android應(yīng)用程序內(nèi)部啟動(dòng)Activity過(guò)程（startActivity）的源代碼分析）、Service啟動(dòng)（Android系統(tǒng)在新進(jìn)程中啟動(dòng)自定義服務(wù)過(guò)程（startService）的原理分析和Android應(yīng)用程序綁定服務(wù)（bindService）的過(guò)程源代碼分析）以及廣播發(fā)送（Android應(yīng)用程序發(fā)送廣播（sendBroadcast）的過(guò)程分析）時(shí)，它們都有一個(gè)共同的特點(diǎn)，當(dāng)ActivityManagerService需要與應(yīng)用程序進(jìn)行并互時(shí)，如加載Activity和Service、處理廣播待，會(huì)通過(guò)Binder進(jìn)程間通信機(jī)制來(lái) 知會(huì)應(yīng)用程序，應(yīng)用程序接收到這個(gè)請(qǐng)求時(shí)，它不是馬上就處理這個(gè)請(qǐng)求，而是將這個(gè)請(qǐng)求封裝成一個(gè)消息，然后把這個(gè)消息放在應(yīng)用程序的消息隊(duì)列中去，然后再 通過(guò)消息循環(huán)來(lái)處理這個(gè)消息。這樣做的好處就是消息的發(fā)送方只要把消息發(fā)送到應(yīng)用程序的消息隊(duì)列中去就行了，它可以馬上返回去處理別的事情，而不需要等待 消息的接收方去處理完這個(gè)消息才返回，這樣就可以提高系統(tǒng)的并發(fā)性。實(shí)質(zhì)上，這就是一種異步處理機(jī)制。
?? ? ? ?這樣說(shuō)可能還是比較籠統(tǒng)，我們以Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析一文中所介紹的應(yīng)用程序啟動(dòng)過(guò)程的一個(gè)片斷來(lái)具體看看是如何這種消息處理機(jī)制的。在這篇文章中，要啟動(dòng)的應(yīng)用程序稱為Activity，它的默認(rèn)Activity是MainActivity，它是由Launcher來(lái)負(fù)責(zé)啟動(dòng)的，而Launcher又是通過(guò)ActivityManagerService來(lái)啟動(dòng)的，當(dāng)ActivityManagerService為這個(gè)即將要啟的應(yīng)用程序準(zhǔn)備好新的進(jìn)程后，便通過(guò)一個(gè)Binder進(jìn)程間通信過(guò)程來(lái)通知這個(gè)新的進(jìn)程來(lái)加載MainActivity，如下圖所示：
?? ? ? ?它對(duì)應(yīng)Android應(yīng)用程序啟動(dòng)過(guò)程中的Step 30到Step 35，有興趣的讀者可以回過(guò)頭去參考Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析一文。這里的Step 30中的scheduleLaunchActivity是ActivityManagerService通過(guò)Binder進(jìn)程間通信機(jī)制發(fā) 送過(guò)來(lái)的請(qǐng)求，它請(qǐng)求應(yīng)用程序中的ActivityThread執(zhí)行Step 34中的performLaunchActivity操作，即啟動(dòng)MainActivity的操作。這里我們就可以看到，Step 30的這個(gè)請(qǐng)求并沒(méi)有等待Step 34這個(gè)操作完成就返回了，它只是把這個(gè)請(qǐng)求封裝成一個(gè)消息，然后通過(guò)Step 31中的queueOrSendMessage操作把這個(gè)消息放到應(yīng)用程序的消息隊(duì)列中，然后就返回了。應(yīng)用程序發(fā)現(xiàn)消息隊(duì)列中有消息時(shí)，就會(huì)通過(guò) Step 32中的handleMessage操作來(lái)處理這個(gè)消息，即調(diào)用Step 33中的handleLaunchActivity來(lái)執(zhí)行實(shí)際的加載MainAcitivy類的操作。
?? ? ? ?了解Android應(yīng)用程序的消息處理過(guò)程之后，我們就開(kāi)始分樣它的實(shí)現(xiàn)原理了。與Windows應(yīng)用程序的消息處理過(guò)程一樣，Android應(yīng)用程序 的消息處理機(jī)制也是由消息循環(huán)、消息發(fā)送和消息處理這三個(gè)部分組成的，接下來(lái)，我們就詳細(xì)描述這三個(gè)過(guò)程。
?? ? ? ?1. 消息循環(huán)
?? ? ? ?在消息處理機(jī)制中，消息都是存放在一個(gè)消息隊(duì)列中去，而應(yīng)用程序的主線程就是圍繞這個(gè)消息隊(duì)列進(jìn)入一個(gè)無(wú)限循環(huán)的，直到應(yīng)用程序退出。如果隊(duì)列中有消 息，應(yīng)用程序的主線程就會(huì)把它取出來(lái)，并分發(fā)給相應(yīng)的Handler進(jìn)行處理；如果隊(duì)列中沒(méi)有消息，應(yīng)用程序的主線程就會(huì)進(jìn)入空閑等待狀態(tài)，等待下一個(gè)消 息的到來(lái)。在Android應(yīng)用程序中，這個(gè)消息循環(huán)過(guò)程是由Looper類來(lái)實(shí)現(xiàn)的，它定義在frameworks/base/core/java /android/os/Looper.java文件中，在分析這個(gè)類之前，我們先看一下Android應(yīng)用程序主線程是如何進(jìn)入到這個(gè)消息循環(huán)中去的。
?? ? ? ?在Android應(yīng)用程序進(jìn)程啟動(dòng)過(guò)程的源代碼分析一 文中，我們分析了Android應(yīng)用程序進(jìn)程的啟動(dòng)過(guò)程，Android應(yīng)用程序進(jìn)程在啟動(dòng)的時(shí)候，會(huì)在進(jìn)程中加載ActivityThread類，并且 執(zhí)行這個(gè)類的main函數(shù)，應(yīng)用程序的消息循環(huán)過(guò)程就是在這個(gè)main函數(shù)里面實(shí)現(xiàn)的，我們來(lái)看看這個(gè)函數(shù)的實(shí)現(xiàn)，它定義在 frameworks/base/core/java/android/app/ActivityThread.java文件中：
[java] view plaincopy?? ? ? ?這個(gè)函數(shù)做了兩件事情，一是在主線程中創(chuàng)建了一個(gè)ActivityThread實(shí)例，二是通過(guò)Looper類使主線程進(jìn)入消息循環(huán)中，這里我們只關(guān)注后者。
?? ? ? ?首先看Looper.prepareMainLooper函數(shù)的實(shí)現(xiàn)，這是一個(gè)靜態(tài)成員函數(shù)，定義在frameworks/base/core/java/android/os/Looper.java文件中：
[java] view plaincopy?? ? ? ?函數(shù)prepareMainLooper做的事情其實(shí)就是在線程中創(chuàng)建一個(gè)Looper對(duì)象，這個(gè)Looper對(duì)象是存放在sThreadLocal成 員變量里面的，成員變量sThreadLocal的類型為ThreadLocal，表示這是一個(gè)線程局部變量，即保證每一個(gè)調(diào)用了 prepareMainLooper函數(shù)的線程里面都有一個(gè)獨(dú)立的Looper對(duì)象。在線程是創(chuàng)建Looper對(duì)象的工作是由prepare函數(shù)來(lái)完成 的，而在創(chuàng)建Looper對(duì)象的時(shí)候，會(huì)同時(shí)創(chuàng)建一個(gè)消息隊(duì)列MessageQueue，保存在Looper的成員變量mQueue中，后續(xù)消息就是存放 在這個(gè)隊(duì)列中去。消息隊(duì)列在Android應(yīng)用程序消息處理機(jī)制中最重要的組件，因此，我們看看它的創(chuàng)建過(guò)程，即它的構(gòu)造函數(shù)的實(shí)現(xiàn)，實(shí)現(xiàn) frameworks/base/core/java/android/os/MessageQueue.java文件中：
[java] view plaincopy?? ? ? ?它的初始化工作都交給JNI方法nativeInit來(lái)實(shí)現(xiàn)了，這個(gè)JNI方法定義在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中：
[cpp] view plaincopy?? ? ? ?在JNI中，也相應(yīng)地創(chuàng)建了一個(gè)消息隊(duì)列NativeMessageQueue，NativeMessageQueue類也是定義在 frameworks/base/core/jni/android_os_MessageQueue.cpp文件中，它的創(chuàng)建過(guò)程如下所示：
[cpp] view plaincopy?? ? ? ?它主要就是在內(nèi)部創(chuàng)建了一個(gè)Looper對(duì)象，注意，這個(gè)Looper對(duì)象是實(shí)現(xiàn)在JNI層的，它與上面Java層中的Looper是不一樣的，不過(guò)它們是對(duì)應(yīng)的，下面我們進(jìn)一步分析消息循環(huán)的過(guò)程的時(shí)候，讀者就會(huì)清楚地了解到它們之間的關(guān)系。
?? ? ? ?這個(gè)Looper的創(chuàng)建過(guò)程也很重要，不過(guò)我們暫時(shí)放一放，先分析完android_os_MessageQueue_nativeInit函數(shù)的執(zhí) 行，它創(chuàng)建了本地消息隊(duì)列NativeMessageQueue對(duì)象之后，接著調(diào)用 android_os_MessageQueue_setNativeMessageQueue函數(shù)來(lái)把這個(gè)消息隊(duì)列對(duì)象保存在前面我們?cè)贘ava層中創(chuàng) 建的MessageQueue對(duì)象的mPtr成員變量里面：
[cpp] view plaincopy?? ? ? ?這里傳進(jìn)來(lái)的參數(shù)messageQueueObj即為我們前面在Java層創(chuàng)建的消息隊(duì)列對(duì)象，而 gMessageQueueClassInfo.mPtr即表示在Java類MessageQueue中，其成員變量mPtr的偏移量，通過(guò)這個(gè)偏移量， 就可以把這個(gè)本地消息隊(duì)列對(duì)象natvieMessageQueue保存在Java層創(chuàng)建的消息隊(duì)列對(duì)象的mPtr成員變量中，這是為了后續(xù)我們調(diào)用 Java層的消息隊(duì)列對(duì)象的其它成員函數(shù)進(jìn)入到JNI層時(shí)，能夠方便地找回它在JNI層所對(duì)應(yīng)的消息隊(duì)列對(duì)象。
?? ? ? ?我們?cè)倩氐絅ativeMessageQueue的構(gòu)造函數(shù)中，看看JNI層的Looper對(duì)象的創(chuàng)建過(guò)程，即看看它的構(gòu)造函數(shù)是如何實(shí)現(xiàn)的，這個(gè)Looper類實(shí)現(xiàn)在frameworks/base/libs/utils/Looper.cpp文件中：
[cpp] view plaincopy?? ? ? ?這個(gè)構(gòu)造函數(shù)做的事情非常重要，它跟我們后面要介紹的應(yīng)用程序主線程在消息隊(duì)列中沒(méi)有消息時(shí)要進(jìn)入等待狀態(tài)以及當(dāng)消息隊(duì)列有消息時(shí)要把應(yīng)用程序主線程喚醒的這兩個(gè)知識(shí)點(diǎn)息息相關(guān)。它主要就是通過(guò)pipe系統(tǒng)調(diào)用來(lái)創(chuàng)建了一個(gè)管道了：
[cpp] view plaincopy?? ? ? ?管道是Linux系統(tǒng)中的一種進(jìn)程間通信機(jī)制，具體可以參考前面一篇文章Android學(xué)習(xí)啟動(dòng)篇推 薦的一本書《Linux內(nèi)核源代碼情景分析》中的第6章--傳統(tǒng)的Uinx進(jìn)程間通信。簡(jiǎn)單來(lái)說(shuō)，管道就是一個(gè)文件，在管道的兩端，分別是兩個(gè)打開(kāi)文件文 件描述符，這兩個(gè)打開(kāi)文件描述符都是對(duì)應(yīng)同一個(gè)文件，其中一個(gè)是用來(lái)讀的，別一個(gè)是用來(lái)寫的，一般的使用方式就是，一個(gè)線程通過(guò)讀文件描述符中來(lái)讀管道的 內(nèi)容，當(dāng)管道沒(méi)有內(nèi)容時(shí)，這個(gè)線程就會(huì)進(jìn)入等待狀態(tài)，而另外一個(gè)線程通過(guò)寫文件描述符來(lái)向管道中寫入內(nèi)容，寫入內(nèi)容的時(shí)候，如果另一端正有線程正在等待管 道中的內(nèi)容，那么這個(gè)線程就會(huì)被喚醒。這個(gè)等待和喚醒的操作是如何進(jìn)行的呢，這就要借助Linux系統(tǒng)中的epoll機(jī)制了。?Linux系統(tǒng)中的 epoll機(jī)制為處理大批量句柄而作了改進(jìn)的poll，是Linux下多路復(fù)用IO接口select/poll的增強(qiáng)版本，它能顯著減少程序在大量并發(fā)連 接中只有少量活躍的情況下的系統(tǒng)CPU利用率。但是這里我們其實(shí)只需要監(jiān)控的IO接口只有mWakeReadPipeFd一個(gè)，即前面我們所創(chuàng)建的管道的 讀端，為什么還需要用到epoll呢？有點(diǎn)用牛刀來(lái)殺雞的味道。其實(shí)不然，這個(gè)Looper類是非常強(qiáng)大的，它除了監(jiān)控內(nèi)部所創(chuàng)建的管道接口之外，還提供 了addFd接口供外界面調(diào)用，外界可以通過(guò)這個(gè)接口把自己想要監(jiān)控的IO事件一并加入到這個(gè)Looper對(duì)象中去，當(dāng)所有這些被監(jiān)控的IO接口上面有事 件發(fā)生時(shí)，就會(huì)喚醒相應(yīng)的線程來(lái)處理，不過(guò)這里我們只關(guān)心剛才所創(chuàng)建的管道的IO事件的發(fā)生。
?? ? ? ?要使用Linux系統(tǒng)的epoll機(jī)制，首先要通過(guò)epoll_create來(lái)創(chuàng)建一個(gè)epoll專用的文件描述符：
[cpp] view plaincopy?? ? ? 傳入的參數(shù)EPOLL_SIZE_HINT是在這個(gè)mEpollFd上能監(jiān)控的最大文件描述符數(shù)。
?? ? ? 接著還要通過(guò)epoll_ctl函數(shù)來(lái)告訴epoll要監(jiān)控相應(yīng)的文件描述符的什么事件：
[cpp] view plaincopy?? ? ? 這里就是告訴mEpollFd，它要監(jiān)控mWakeReadPipeFd文件描述符的EPOLLIN事件，即當(dāng)管道中有內(nèi)容可讀時(shí)，就喚醒當(dāng)前正在等待管道中的內(nèi)容的線程。
?? ? ? C++層的這個(gè)Looper對(duì)象創(chuàng)建好了之后，就返回到JNI層的NativeMessageQueue的構(gòu)造函數(shù)，最后就返回到Java層的消息隊(duì)列 MessageQueue的創(chuàng)建過(guò)程，這樣，Java層的Looper對(duì)象就準(zhǔn)備好了。有點(diǎn)復(fù)雜，我們先小結(jié)一下這一步都做了些什么事情：
?? ? ? A. 在Java層，創(chuàng)建了一個(gè)Looper對(duì)象，這個(gè)Looper對(duì)象是用來(lái)進(jìn)入消息循環(huán)的，它的內(nèi)部有一個(gè)消息隊(duì)列MessageQueue對(duì)象mQueue；
?? ? ? B. 在JNI層，創(chuàng)建了一個(gè)NativeMessageQueue對(duì)象，這個(gè)NativeMessageQueue對(duì)象保存在Java層的消息隊(duì)列對(duì)象mQueue的成員變量mPtr中；
?? ? ? C. 在C++層，創(chuàng)建了一個(gè)Looper對(duì)象，保存在JNI層的NativeMessageQueue對(duì)象的成員變量mLooper中，這個(gè)對(duì)象的作用是，當(dāng) Java層的消息隊(duì)列中沒(méi)有消息時(shí)，就使Android應(yīng)用程序主線程進(jìn)入等待狀態(tài)，而當(dāng)Java層的消息隊(duì)列中來(lái)了新的消息后，就喚醒Android應(yīng) 用程序的主線程來(lái)處理這個(gè)消息。
?? ? ? 回到ActivityThread類的main函數(shù)中，在上面這些工作都準(zhǔn)備好之后，就調(diào)用Looper類的loop函數(shù)進(jìn)入到消息循環(huán)中去了：
[cpp] view plaincopy?? ? ? ?這里就是進(jìn)入到消息循環(huán)中去了，它不斷地從消息隊(duì)列mQueue中去獲取下一個(gè)要處理的消息msg，如果消息的target成員變量為null，就表示 要退出消息循環(huán)了，否則的話就要調(diào)用這個(gè)target對(duì)象的dispatchMessage成員函數(shù)來(lái)處理這個(gè)消息，這個(gè)target對(duì)象的類型為 Handler，下面我們分析消息的發(fā)送時(shí)會(huì)看到這個(gè)消息對(duì)象msg是如設(shè)置的。
?? ? ? ?這個(gè)函數(shù)最關(guān)鍵的地方便是從消息隊(duì)列中獲取下一個(gè)要處理的消息了，即MessageQueue.next函數(shù)，它實(shí)現(xiàn)frameworks/base/core/java/android/os/MessageQueue.java文件中：
[java] view plaincopy?? ? ? ?調(diào)用這個(gè)函數(shù)的時(shí)候，有可能會(huì)讓線程進(jìn)入等待狀態(tài)。什么情況下，線程會(huì)進(jìn)入等待狀態(tài)呢？兩種情況，一是當(dāng)消息隊(duì)列中沒(méi)有消息時(shí)，它會(huì)使線程進(jìn)入等待狀 態(tài)；二是消息隊(duì)列中有消息，但是消息指定了執(zhí)行的時(shí)間，而現(xiàn)在還沒(méi)有到這個(gè)時(shí)間，線程也會(huì)進(jìn)入等待狀態(tài)。消息隊(duì)列中的消息是按時(shí)間先后來(lái)排序的，后面我們 在分析消息的發(fā)送時(shí)會(huì)看到。
?? ? ? ?執(zhí)行下面語(yǔ)句是看看當(dāng)前消息隊(duì)列中有沒(méi)有消息：
[java] view plaincopy?? ? ? ?這是一個(gè)JNI方法，我們等一下再分析，這里傳入的參數(shù)mPtr就是指向前面我們?cè)贘NI層創(chuàng)建的NativeMessageQueue對(duì)象了，而參數(shù) nextPollTimeoutMillis則表示如果當(dāng)前消息隊(duì)列中沒(méi)有消息，它要等待的時(shí)候，for循環(huán)開(kāi)始時(shí)，傳入的值為0，表示不等待。
?? ? ? ?當(dāng)前nativePollOnce返回后，就去看看消息隊(duì)列中有沒(méi)有消息：
[java] view plaincopy?? ? ? ?如果消息隊(duì)列中有消息，并且當(dāng)前時(shí)候大于等于消息中的執(zhí)行時(shí)間，那么就直接返回這個(gè)消息給Looper.loop消息處理，否則的話就要等待到消息的執(zhí)行時(shí)間：
[java] view plaincopy?? ? ? ?如果消息隊(duì)列中沒(méi)有消息，那就要進(jìn)入無(wú)窮等待狀態(tài)直到有新消息了：
[java] view plaincopy?? ? ? ?-1表示下次調(diào)用nativePollOnce時(shí)，如果消息中沒(méi)有消息，就進(jìn)入無(wú)限等待狀態(tài)中去。
?? ? ? ?這里計(jì)算出來(lái)的等待時(shí)間都是在下次調(diào)用nativePollOnce時(shí)使用的。
?? ? ? ?這里說(shuō)的等待，是空閑等待，而不是忙等待，因此，在進(jìn)入空閑等待狀態(tài)前，如果應(yīng)用程序注冊(cè)了IdleHandler接口來(lái)處理一些事情，那么就會(huì)先執(zhí)行 這里IdleHandler，然后再進(jìn)入等待狀態(tài)。IdlerHandler是定義在MessageQueue的一個(gè)內(nèi)部類：
[java] view plaincopy?? ? ? ?它只有一個(gè)成員函數(shù)queueIdle，執(zhí)行這個(gè)函數(shù)時(shí)，如果返回值為false，那么就會(huì)從應(yīng)用程序中移除這個(gè)IdleHandler，否則的話就會(huì) 在應(yīng)用程序中繼續(xù)維護(hù)著這個(gè)IdleHandler，下次空閑時(shí)仍會(huì)再執(zhí)會(huì)這個(gè)IdleHandler。MessageQueue提供了 addIdleHandler和removeIdleHandler兩注冊(cè)和刪除IdleHandler。
?? ? ? ?回到MessageQueue函數(shù)中，它接下來(lái)就是在進(jìn)入等待狀態(tài)前，看看有沒(méi)有IdleHandler是需要執(zhí)行的：
[java] view plaincopy?? ? ? ?如果沒(méi)有，即pendingIdleHandlerCount等于0，那下面的邏輯就不執(zhí)行了，通過(guò)continue語(yǔ)句直接進(jìn)入下一次循環(huán)，否則就要 把注冊(cè)在mIdleHandlers中的IdleHandler取出來(lái)，放在mPendingIdleHandlers數(shù)組中去。
?? ? ? ?接下來(lái)就是執(zhí)行這些注冊(cè)了的IdleHanlder了：
[java] view plaincopy?? ? ? ? 執(zhí)行完這些IdleHandler之后，線程下次調(diào)用nativePollOnce函數(shù)時(shí)，就不設(shè)置超時(shí)時(shí)間了，因?yàn)?#xff0c;很有可能在執(zhí)行 IdleHandler的時(shí)候，已經(jīng)有新的消息加入到消息隊(duì)列中去了，因此，要重置nextPollTimeoutMillis的值：
[java] view plaincopy?? ? ? ?分析完MessageQueue的這個(gè)next函數(shù)之后，我們就要深入分析一下JNI方法nativePollOnce了，看看它是如何進(jìn)入等待狀態(tài) 的，這個(gè)函數(shù)定義在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中：
[cpp] view plaincopy?? ? ? ?這個(gè)函數(shù)首先是通過(guò)傳進(jìn)入的參數(shù)ptr取回前面在Java層創(chuàng)建MessageQueue對(duì)象時(shí)在JNI層創(chuàng)建的NatvieMessageQueue對(duì)象，然后調(diào)用它的pollOnce函數(shù)：
[cpp] view plaincopy?? ? ? ?這里將操作轉(zhuǎn)發(fā)給mLooper對(duì)象的pollOnce函數(shù)處理，這里的mLooper對(duì)象是在C++層的對(duì)象，它也是在前面在JNI層創(chuàng)建的 NatvieMessageQueue對(duì)象時(shí)創(chuàng)建的，它的pollOnce函數(shù)定義在frameworks/base/libs/utils /Looper.cpp文件中：
[cpp] view plaincopy?? ? ? ?為了方便討論，我們把這個(gè)函數(shù)的無(wú)關(guān)部分都去掉，它主要就是調(diào)用pollInner函數(shù)來(lái)進(jìn)一步操作，如果pollInner返回值不等于0，這個(gè)函數(shù)就可以返回了。
?? ? ? ?函數(shù)pollInner的定義如下：
[cpp] view plaincopy?? ? ? ?這里，首先是調(diào)用epoll_wait函數(shù)來(lái)看看epoll專用文件描述符mEpollFd所監(jiān)控的文件描述符是否有IO事件發(fā)生，它設(shè)置監(jiān)控的超時(shí)時(shí)間為timeoutMillis：
[cpp] view plaincopy?? ? ? ?回憶一下前面的Looper的構(gòu)造函數(shù)，我們?cè)诶锩嬖O(shè)置了要監(jiān)控mWakeReadPipeFd文件描述符的EPOLLIN事件。
?? ? ? ?當(dāng)mEpollFd所監(jiān)控的文件描述符發(fā)生了要監(jiān)控的IO事件后或者監(jiān)控時(shí)間超時(shí)后，線程就從epoll_wait返回了，否則線程就會(huì)在epoll_wait函數(shù)中進(jìn)入睡眠狀態(tài)了。返回后如果eventCount等于0，就說(shuō)明是超時(shí)了：
[cpp] view plaincopy?? ? ? 如果eventCount不等于0，就說(shuō)明發(fā)生要監(jiān)控的事件：
[cpp] view plaincopy?? ? ? ?這里我們只關(guān)注mWakeReadPipeFd文件描述符上的事件，如果在mWakeReadPipeFd文件描述符上發(fā)生了EPOLLIN就說(shuō)明應(yīng)用 程序中的消息隊(duì)列里面有新的消息需要處理了，接下來(lái)它就會(huì)先調(diào)用awoken函數(shù)清空管道中把內(nèi)容，以便下次再調(diào)用pollInner函數(shù)時(shí)，知道自從上 次處理完消息隊(duì)列中的消息后，有沒(méi)有新的消息加進(jìn)來(lái)。
?? ? ? ?函數(shù)awoken的實(shí)現(xiàn)很簡(jiǎn)單，它只是把管道中的內(nèi)容都讀取出來(lái)：
[cpp] view plaincopy?? ? ? ?因?yàn)楫?dāng)其它的線程向應(yīng)用程序的消息隊(duì)列加入新的消息時(shí)，會(huì)向這個(gè)管道寫入新的內(nèi)容來(lái)通知應(yīng)用程序主線程有新的消息需要處理了，下面我們分析消息的發(fā)送的時(shí)候?qū)?huì)看到。
?? ? ? ?這樣，消息的循環(huán)過(guò)程就分析完了，這部分邏輯還是比較復(fù)雜的，它利用Linux系統(tǒng)中的管道（pipe）進(jìn)程間通信機(jī)制來(lái)實(shí)現(xiàn)消息的等待和處理，不過(guò)，了解了這部分內(nèi)容之后，下面我們分析消息的發(fā)送和處理就簡(jiǎn)單多了。
?? ? ? ?2. 消息的發(fā)送
?? ? ? ?應(yīng)用程序的主線程準(zhǔn)備就好消息隊(duì)列并且進(jìn)入到消息循環(huán)后，其它地方就可以往這個(gè)消息隊(duì)列中發(fā)送消息了。我們繼續(xù)以文章開(kāi)始介紹的Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析一文中的應(yīng)用程序啟動(dòng)過(guò)為例，說(shuō)明應(yīng)用程序是如何把消息加入到應(yīng)用程序的消息隊(duì)列中去的。
?? ? ? ?在Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析這 篇文章的Step 30中，ActivityManagerService通過(guò)調(diào)用ApplicationThread類的scheduleLaunchActivity函 數(shù)通知應(yīng)用程序，它可以加載應(yīng)用程序的默認(rèn)Activity了，這個(gè)函數(shù)定義在frameworks/base/core/java/android /app/ActivityThread.java文件中：
[java] view plaincopy?? ? ? ?這里把相關(guān)的參數(shù)都封裝成一個(gè)ActivityClientRecord對(duì)象r，然后調(diào)用queueOrSendMessage函數(shù)來(lái)往應(yīng)用程序的消息 隊(duì)列中加入一個(gè)新的消息（H.LAUNCH_ACTIVITY），這個(gè)函數(shù)定義在frameworks/base/core/java/android /app/ActivityThread.java文件中：
[java] view plaincopy?? ? ? ?在queueOrSendMessage函數(shù)中，又進(jìn)一步把上面?zhèn)鬟M(jìn)來(lái)的參數(shù)封裝成一個(gè)Message對(duì)象msg，然后通過(guò) mH.sendMessage函數(shù)把這個(gè)消息對(duì)象msg加入到應(yīng)用程序的消息隊(duì)列中去。這里的mH是ActivityThread類的成員變量，它的類型 為H，繼承于Handler類，它定義在frameworks/base/core/java/android/app /ActivityThread.java文件中：
[java] view plaincopy?? ? ? ?這個(gè)H類就是通過(guò)其成員函數(shù)handleMessage函數(shù)來(lái)處理消息的了，后面我們分析消息的處理過(guò)程時(shí)會(huì)看到。
?? ? ? ?ActivityThread類的這個(gè)mH成員變量是什么時(shí)候創(chuàng)建的呢？我們前面在分析應(yīng)用程序的消息循環(huán)時(shí)，說(shuō)到當(dāng)應(yīng)用程序進(jìn)程啟動(dòng)之后，就會(huì)加載 ActivityThread類的main函數(shù)里面，在這個(gè)main函數(shù)里面，在通過(guò)Looper類進(jìn)入消息循環(huán)之前，會(huì)在當(dāng)前進(jìn)程中創(chuàng)建一個(gè) ActivityThread實(shí)例：
?? ? ? ?在創(chuàng)建這個(gè)實(shí)例的時(shí)候，就會(huì)同時(shí)創(chuàng)建其成員變量mH了：
[java] view plaincopy?? ? ? ?前面說(shuō)過(guò)，H類繼承于Handler類，因此，當(dāng)創(chuàng)建這個(gè)H對(duì)象時(shí)，會(huì)調(diào)用Handler類的構(gòu)造函數(shù)，這個(gè)函數(shù)定義在frameworks/base/core/java/android/os/Handler.java文件中：
[java] view plaincopy?? ? ? ?在Hanlder類的構(gòu)造函數(shù)中，主要就是初始成員變量mLooper和mQueue了。這里的myLooper是Looper類的靜態(tài)成員函數(shù)，通過(guò) 它來(lái)獲得一個(gè)Looper對(duì)象，這個(gè)Looper對(duì)象就是前面我們?cè)诜治鱿⒀h(huán)時(shí)，在ActivityThread類的main函數(shù)中通過(guò) Looper.prepareMainLooper函數(shù)創(chuàng)建的。Looper.myLooper函數(shù)實(shí)現(xiàn)在frameworks/base/core /java/android/os/Looper.java文件中：
[java] view plaincopy?? ? ? ?有了這個(gè)Looper對(duì)象后，就可以通過(guò)Looper.mQueue來(lái)訪問(wèn)應(yīng)用程序的消息隊(duì)列了。
?? ? ? ?有了這個(gè)Handler對(duì)象mH后，就可以通過(guò)它來(lái)往應(yīng)用程序的消息隊(duì)列中加入新的消息了。回到前面的queueOrSendMessage函數(shù)中，當(dāng) 它準(zhǔn)備好了一個(gè)Message對(duì)象msg后，就開(kāi)始調(diào)用mH.sendMessage函數(shù)來(lái)發(fā)送消息了，這個(gè)函數(shù)定義在frameworks/base /core/java/android/os/Handler.java文件中：
[java] view plaincopy?? ? ? ?在發(fā)送消息時(shí)，是可以指定消息的處理時(shí)間的，但是通過(guò)sendMessage函數(shù)發(fā)送的消息的處理時(shí)間默認(rèn)就為當(dāng)前時(shí)間，即表示要馬上處理，因此，從 sendMessage函數(shù)中調(diào)用sendMessageDelayed函數(shù)，傳入的時(shí)間參數(shù)為0，表示這個(gè)消息不要延時(shí)處理，而在 sendMessageDelayed函數(shù)中，則會(huì)先獲得當(dāng)前時(shí)間，然后加上消息要延時(shí)處理的時(shí)間，即得到這個(gè)處理這個(gè)消息的絕對(duì)時(shí)間，然后調(diào)用 sendMessageAtTime函數(shù)來(lái)把消息加入到應(yīng)用程序的消息隊(duì)列中去。
?? ? ? ?在sendMessageAtTime函數(shù)，首先得到應(yīng)用程序的消息隊(duì)列mQueue，這是在Handler對(duì)象構(gòu)造時(shí)初始化好的，前面已經(jīng)分析過(guò)了，接著設(shè)置這個(gè)消息的目標(biāo)對(duì)象target，即這個(gè)消息最終是由誰(shuí)來(lái)處理的：
[java] view plaincopy?? ? ? ?這里將它賦值為this，即表示這個(gè)消息最終由這個(gè)Handler對(duì)象來(lái)處理，即由ActivityThread對(duì)象的mH成員變量來(lái)處理。
?? ? ? ?函數(shù)最后調(diào)用queue.enqueueMessage來(lái)把這個(gè)消息加入到應(yīng)用程序的消息隊(duì)列中去，這個(gè)函數(shù)實(shí)現(xiàn)在frameworks/base/core/java/android/os/MessageQueue.java文件中：
[java] view plaincopy?? ? ? ?把消息加入到消息隊(duì)列時(shí)，分兩種情況，一種當(dāng)前消息隊(duì)列為空時(shí)，這時(shí)候應(yīng)用程序的主線程一般就是處于空閑等待狀態(tài)了，這時(shí)候就要喚醒它，另一種情況是應(yīng) 用程序的消息隊(duì)列不為空，這時(shí)候就不需要喚醒應(yīng)用程序的主線程了，因?yàn)檫@時(shí)候它一定是在忙著處于消息隊(duì)列中的消息，因此不會(huì)處于空閑等待的狀態(tài)。
?? ? ? ?第一種情況比較簡(jiǎn)單，只要把消息放在消息隊(duì)列頭就可以了：
[java] view plaincopy?? ? ? ?第二種情況相對(duì)就比較復(fù)雜一些了，前面我們說(shuō)過(guò)，當(dāng)往消息隊(duì)列中發(fā)送消息時(shí)，是可以指定消息的處理時(shí)間的，而消息隊(duì)列中的消息，就是按照這個(gè)時(shí)間從小到 大來(lái)排序的，因此，當(dāng)把新的消息加入到消息隊(duì)列時(shí)，就要根據(jù)它的處理時(shí)間來(lái)找到合適的位置，然后再放進(jìn)消息隊(duì)列中去：
[java] view plaincopy?? ? ? ?把消息加入到消息隊(duì)列去后，如果應(yīng)用程序的主線程正處于空閑等待狀態(tài)，就需要調(diào)用natvieWake函數(shù)來(lái)喚醒它了，這是一個(gè)JNI方法，定義在 frameworks/base/core/jni/android_os_MessageQueue.cpp文件中：
[java] view plaincopy?? ? ? ?這個(gè)JNI層的NativeMessageQueue對(duì)象我們?cè)谇懊娣治鱿⒀h(huán)的時(shí)候創(chuàng)建好的，保存在Java層的MessageQueue對(duì)象的 mPtr成員變量中，這里把它取回來(lái)之后，就調(diào)用它的wake函數(shù)來(lái)喚醒應(yīng)用程序的主線程，這個(gè)函數(shù)也是定義在frameworks/base/core /jni/android_os_MessageQueue.cpp文件中：
[java] view plaincopy?? ? ? ?這里它又通過(guò)成員變量mLooper的wake函數(shù)來(lái)執(zhí)行操作，這里的mLooper成員變量是一個(gè)C++層實(shí)現(xiàn)的Looper對(duì)象，它定義在frameworks/base/libs/utils/Looper.cpp文件中：
[java] view plaincopy?? ? ? ?這個(gè)wake函數(shù)很簡(jiǎn)單，只是通過(guò)打開(kāi)文件描述符mWakeWritePipeFd往管道的寫入一個(gè)"W"字符串。其實(shí)，往管道寫入什么內(nèi)容并不重要， 往管道寫入內(nèi)容的目的是為了喚醒應(yīng)用程序的主線程。前面我們?cè)诜治鰬?yīng)用程序的消息循環(huán)時(shí)說(shuō)到，當(dāng)應(yīng)用程序的消息隊(duì)列中沒(méi)有消息處理時(shí)，應(yīng)用程序的主線程就 會(huì)進(jìn)入空閑等待狀態(tài)，而這個(gè)空閑等待狀態(tài)就是通過(guò)調(diào)用這個(gè)Looper類的pollInner函數(shù)來(lái)進(jìn)入的，具體就是在pollInner函數(shù)中調(diào)用 epoll_wait函數(shù)來(lái)等待管道中有內(nèi)容可讀的。
?? ? ? ?這時(shí)候既然管道中有內(nèi)容可讀了，應(yīng)用程序的主線程就會(huì)從這里的Looper類的pollInner函數(shù)返回到JNI層的nativePollOnce函 數(shù)，最后返回到Java層中的MessageQueue.next函數(shù)中去，這里它就會(huì)發(fā)現(xiàn)消息隊(duì)列中有新的消息需要處理了，于就會(huì)處理這個(gè)消息。
?? ? ? ?3. 消息的處理
?? ? ? ?前面在分析消息循環(huán)時(shí)，說(shuō)到應(yīng)用程序的主線程是在Looper類的loop成員函數(shù)中進(jìn)行消息循環(huán)過(guò)程的，這個(gè)函數(shù)定義在frameworks/base/core/java/android/os/Looper.java文件中：
[java] view plaincopy?? ? ? ?它從消息隊(duì)列中獲得消息對(duì)象msg后，就會(huì)調(diào)用它的target成員變量的dispatchMessage函數(shù)來(lái)處理這個(gè)消息。在前面分析消息的發(fā)送時(shí) 說(shuō)過(guò)，這個(gè)消息對(duì)象msg的成員變量target是在發(fā)送消息的時(shí)候設(shè)置好的，一般就通過(guò)哪個(gè)Handler來(lái)發(fā)送消息，就通過(guò)哪個(gè)Handler來(lái)處理 消息。
?? ? ? ?我們繼續(xù)以前面分析消息的發(fā)送時(shí)所舉的例子來(lái)分析消息的處理過(guò)程。前面說(shuō)到，在Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析這 篇文章的Step 30中，ActivityManagerService通過(guò)調(diào)用ApplicationThread類的scheduleLaunchActivity函 數(shù)通知應(yīng)用程序，它可以加載應(yīng)用程序的默認(rèn)Activity了，而ApplicationThread類的scheduleLaunchActivity 函數(shù)最終把這個(gè)請(qǐng)求封裝成一個(gè)消息，然后通過(guò)ActivityThread類的成員變量mH來(lái)把這個(gè)消息加入到應(yīng)用程序的消息隊(duì)列中去。現(xiàn)在要對(duì)這個(gè)消息 進(jìn)行處理了，于是就會(huì)調(diào)用H類的dispatchMessage函數(shù)進(jìn)行處理。
?? ? ? ?H類沒(méi)有實(shí)現(xiàn)自己的dispatchMessage函數(shù)，但是它繼承了父類Handler的dispatchMessage函數(shù)，這個(gè)函數(shù)定義在 frameworks/base/core/java/android/os/ Handler.java文件中：
[java] view plaincopy?? ? ? ?這里的消息對(duì)象msg的callback成員變量和Handler類的mCallBack成員變量一般都為null，于是，就會(huì)調(diào)用Handler類的 handleMessage函數(shù)來(lái)處理這個(gè)消息，由于H類在繼承Handler類時(shí)，重寫了handleMessage函數(shù)，因此，這里調(diào)用的實(shí)際上是H 類的handleMessage函數(shù)，這個(gè)函數(shù)定義在frameworks/base/core/java/android/app /ActivityThread.java文件中：
[java] view plaincopy?? ? ? ? 因?yàn)榍懊嬖诜治鱿⒌陌l(fā)送時(shí)所舉的例子中，發(fā)送的消息的類型為H.LAUNCH_ACTIVITY，因此，這里就會(huì)調(diào)用ActivityThread類的handleLaunchActivity函數(shù)來(lái)真正地處理這個(gè)消息了，后面的具體過(guò)程就可以參考Android應(yīng)用程序啟動(dòng)過(guò)程源代碼分析這篇文章了。
?? ? ? ? 至此，我們就從消息循環(huán)、消息發(fā)送和消息處理三個(gè)部分分析完Android應(yīng)用程序的消息處理機(jī)制了，為了更深理解，這里我們對(duì)其中的一些要點(diǎn)作一個(gè)總結(jié)：
?? ? ? ? A. Android應(yīng)用程序的消息處理機(jī)制由消息循環(huán)、消息發(fā)送和消息處理三個(gè)部分組成的。
?? ? ? ? B. Android應(yīng)用程序的主線程在進(jìn)入消息循環(huán)過(guò)程前，會(huì)在內(nèi)部創(chuàng)建一個(gè)Linux管道（Pipe），這個(gè)管道的作用是使得Android應(yīng)用程序主線程 在消息隊(duì)列為空時(shí)可以進(jìn)入空閑等待狀態(tài)，并且使得當(dāng)應(yīng)用程序的消息隊(duì)列有消息需要處理時(shí)喚醒應(yīng)用程序的主線程。
?? ? ? ? C. Android應(yīng)用程序的主線程進(jìn)入空閑等待狀態(tài)的方式實(shí)際上就是在管道的讀端等待管道中有新的內(nèi)容可讀，具體來(lái)說(shuō)就是是通過(guò)Linux系統(tǒng)的Epoll機(jī)制中的epoll_wait函數(shù)進(jìn)行的。
?? ? ? ? D. 當(dāng)往Android應(yīng)用程序的消息隊(duì)列中加入新的消息時(shí)，會(huì)同時(shí)往管道中的寫端寫入內(nèi)容，通過(guò)這種方式就可以喚醒正在等待消息到來(lái)的應(yīng)用程序主線程。
?? ? ? ? E. 當(dāng)應(yīng)用程序主線程在進(jìn)入空閑等待前，會(huì)認(rèn)為當(dāng)前線程處理空閑狀態(tài)，于是就會(huì)調(diào)用那些已經(jīng)注冊(cè)了的IdleHandler接口，使得應(yīng)用程序有機(jī)會(huì)在空閑的時(shí)候處理一些事情。
老羅的新浪微博：http://weibo.com/shengyangluo，歡迎關(guān)注！
轉(zhuǎn)載于:https://www.cnblogs.com/Free-Thinker/p/4142491.html
總結(jié)
以上是生活随笔為你收集整理的Android应用程序消息处理机制（Looper、Handler）分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 经典数据结构视频教程下载 (清华大学 严
- 下一篇： android for armeabi,