Android消息循環機制(一)

Android的Handler是什么?網上很多資料都會介紹說Android Handler是用來處理跨線程通信,跨線程更新UI的,這么說肯定沒錯,但這只是Handler的作用,個人覺得并沒有說到核心點上。

跨線程通信,Java的內存模型本身就已經實現了,在java里跨線程通信非常簡單,直接引用變量就可以了,當然如果需要處理線程安全問題用synchronized或者volatile處理就可以了。 為什么還要用Handler?單純說Handler跨線程通信,其實是不合適的。
那Handler到底是什么?Handler其實是Android的消息循環模型。
看一個最普通的java代碼。

public static void main(String[] args){
    System.out.println("Hello World");
}

一共三行。JVM虛擬機可能是這樣處理的。

-->>創建線程
-->>執行1,2,3行
-->>代碼結束,線程結束

那問題來了,我們App如果也是類似上面的代碼的話就會有問題了,一個最簡單的HelloWorld App并不會在繪制完HelloWrold TextView之后就結束線程。那怎么辦?
AndroidSdk里有個類ActivityManagerService,里面有個startProcessLocked方法,有類似下面的代碼。

if (entryPoint == null) entryPoint = "android.app.ActivityThread";
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "Start proc: " +
        app.processName);
checkTime(startTime, "startProcess: asking zygote to start proc");
Process.ProcessStartResult startResult = Process.start(entryPoint,
        app.processName, uid, uid, gids, debugFlags, mountExternal,
        app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
        app.info.dataDir, entryPointArgs);

第一行的"android.app.ActivityThread"其實就是App的入口類,在ActivityThread,里面有個main方法。這個方法就是整個App的入口。

public static void main(String[] args) {
    ......
    Looper.prepareMainLooper();
    ......
    Looper.loop();
    throw new RuntimeException("Main thread loop unexpectedly exited");
}

這段代碼最后一行很有意思,是一個異常,說明如果代碼跑到這里App就崩潰了。我們App既然沒有崩潰,那就表示這個代碼從來沒有被執行到。怎么才能不被執行到?死循環。死循環只要不發生異常是永遠不會結束的。跟進去發現確實是一個死循環。

public static void loop() {
    ......
    for(;;){
      ......
    }
    ......
}

死循環如果不停的去輪詢一個變量,檢查狀態獲取消息,然后需要處理數據了,就修改被輪詢的對象應該也是可以的,但有個很嚴重的問題,這樣不加節制的死循環,即使當前沒有任何消息需要處理也會吃滿CPU,那為了不必要的CPU消耗,我們肯定是希望有個東西能通知我們什么時候有消息了,什么時候再喚醒才最好。我們先看下Android里,App在安靜狀態代碼都在干嘛。新建一個HelloWorld項目,跑起來,然后進度debug模式,在dubug模式里,點擊下圖里的紅色框中的按鈕,這個按鈕可以dump當前App的堆棧數據。


dump_stack_0.png

打印主線程堆棧狀態:


dump_stack_1.png

無論dump多少次,只要App是安靜狀態,沒有處理任何事件就永遠是上面的代碼。上面的結果是什么意思?上面的結果表示App在安靜的時候是阻塞在了
android.os.MessageQueue.nativePollOnce(Native Method)
android.os.MessageQueue.next(MessageQueue.java:323)

我們先查看下App的CPU占用,只要是安靜狀態CPU占用就一直為0。


安靜狀態CPU占用.png

這表示Android并沒有空轉CPU,用腳趾頭想其實也不可能空轉,一直空轉那CPU還不得罵人了。跟進MessageQueue的next方法,for死循環調用的nativePollOnce(ptr, nextPollTimeoutMillis);是個Native方法,是用C實現的,背后的原理其實是利用的Linux的epoll機制。有興趣的可以搜epoll的相關資料。

Android整個消息過程大致可以理解為這樣:
A、主線程
-->>Android App進程創建
-->>初始化創建一個消息隊列
-->>主線程死循環讀取消息隊列
-->>消息處理完nativePollOnce掛起等待新消息

B、其他線程
-->>直接引用主線程的消息隊列,添加消息到隊列里。(由于做了線程同步這時候主線程的隊列數據已經和子線程一致了)
-->>調用nativeWake通知Native喚醒主線程

C、主線程
-->>主線程nativePollOnce掛起取消
-->>處理消息
-->>消息處理完消息,nativePollOnce繼續掛起等待新消息
......
無限循環
……

如果希望一個Runnable在主線程執行,那很簡單:
在任意線程(可以是主線程也可以不是主線程)創建Runnable,然后在任意線程將Runnable添加到主線程的消息隊列,然后調用nativeWake通知Native喚醒主線程,主線程喚醒,然后主線程調用Runnable。注意這時候Runnable就已經是主線程在調用執行了。
這就是Handler的大致工作過程,Android就是通過Handler來實現消息循環機制的。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容