handler源碼

① Android Handler那些事兒，消息屏障IdelHandlerANR

Handler 是Android SDK中用來處理非同步消息的核心類，子線程可以通過handler來通知主線程進行ui更新。

備註：本文源碼截圖 基於Android sdk 28

Handler機制 消息發送主要流程如圖

應用程序啟動後，zygote fork一個應用進程後，和普通java程序一樣，程序會首先執行ActivityThread中的main函數。在main函數中，程序首先會創建Looper對象並綁定到主線程中，然後開啟loop循環。（ps:主線程loop循環不能退出）

在prepareMainLooper方法中，最終會創建Looper，MessageQueue對象 以及創建native層MessageQueue對象。

使用Handler.sendMessageXXX或這 postDedayXXX發送消息後，最終會調用到SendMessageAtTime方法中。

然後調用MessageQueue.enqueueMessage將消息存到消息隊列中。

存入消息後，然後通過調用native方法 喚醒主線程進行消息處理。

當應用程序啟動，做完一些必要工作之後，便會開啟Loop循環，除非系統異常，否則該循環不會停止。loop循環中，主要做兩件事，第一，從消息隊列中取消息。第二，進行消息分發處理。

MessageQueue.next() 方法 通過調用 native方法 nativePollOnce(ptr, nextPollTimeoutMillis)實現無消息處理時，進入阻塞的功能。
當nextPollTimeoutMillis 值為0時，該方法會立刻返回；
當nextPollTimeoutMillis 值為-1時，該方法會無限阻塞，直到被喚醒；
當nextPollTimeoutMillis 值大於0時，該方法會將該值設置為超時時間，阻塞到達一定時間後，返回；

在loop循環中 ，通過調用 msg.target.dispatchMessage(msg) 進行消息的分發處理

使用當前線程的MessageQueue.addIdleHandler方法可以在消息隊列中添加一個IdelHandler。

當MessageQueue 阻塞時，即當前線程空閑時，會回調IdleHandler中的方法；

當IdelHandler介面返回false時，表示該IdelHandler只執行一次，

a，延遲執行

例如，當啟動Activity時，需要延時執行一些操作，以免啟動過慢，我們常常使用以下方式延遲執行任務，但是在延遲時間上卻不好控制。

其實，這時候使用IdelHandler 會更優雅

b，批量任務，任務密集，且只關注最終結果

例如，在開發一個IM類型的界面時，通常情況下，每次收到一個IM消息時，都會刷新一次界面，但是當短時間內， 收到多條消息時，就會刷新多次界面，容易造成卡頓，影響性能，此時就可以使用一個工作線程監聽IM消息，在通過添加IdelHandler的方式通知界面刷新，避免短時間內多次刷新界面情況的發生。

在Android的消息機制中，其實有三種消息: 普通消息、非同步消息及消息屏障。

消息屏障 也是一種消息，但是它的target為 null。可以通過MessageQueue中的postSyncBarrier方法發送一個消息屏障（該方法為私有，需要反射調用）。

在消息循環中，如果第一條消息就是屏障消息，就往後遍歷，看看有沒有非同步消息:
如果沒有，則無限休眠，等待被喚醒
如果有，就看離這個消息被觸發時間還有多久，設置一個超時時間，繼續休眠

非同步消息 和普通消息一樣，只不過它被設置setAsynchronous 為true。有了這個標志位，消息機制會對它有些特別的處理，我們稍後說。

所以 消息屏障和非同步消息的作用 很明顯，在設置消息屏障後，非同步消息具有優先處理的權利。

這時候我們回顧將消息添加到消息隊列中時，可以發現，其實並不是每一次添加消息時，都會喚醒線程。
當該消息插入到隊列頭時，會喚醒該線程；
當該消息沒有插入到隊列頭，但隊列頭是屏障，且該消息是隊列中 靠前的一個非同步消息，則會喚醒線程，執行該消息；

調用MessageQueue.removeSyncBarrier 方法可以移除指定的消息屏障

ANR 即 Application Not Response， 是系統進程對應用行為的一種監控，如果應用程序沒有在規定時間內完成任務的話，就會引起ANR。

ANR類型

Service Timeout : 前台服務20s, 後台服務200s

BroadcastQueue Timeout : 前台廣播 10s，後台廣播60s

ContentPrivider Timeout : 10s

InputDispatching Timeout : 5s

比如，在啟動一個服務時， AMS端通過應用進程的Binder對象創建Service, 在scheleCreateService()方法中 會調用到當前service的onCreate()生命周期函數；

bumpServiceExecutingLocked()方法內部實際上會調用到scheleServiceTimeoutLocked()方法，發送一個ActivityManagerService.SERVICE_TIMEOUT_MSG類型消息到AMS工作線程中。

消息的延時時間，如果是前台服務，延時20s, 如果是後台服務，延時200s;

如果Service的創建 工作在 上訴消息的延時時間內完成，則會移除該消息，

否則，在Handler正常收到這個消息後，就會進行服務超時處理，即彈出ANR對話框。

復雜情況下，可能會頻繁調用sendMessage 往消息隊列中，添加消息，導致消息積壓，造成卡頓，

1，重復消息過濾

頻繁發送同類型消息時，有可能隊列中之前的消息還沒有處理，又發了一條相同類型的消息，更新之前的數據，這時候，可以採用移除前一個消息的方法，優化消息隊列。

2，互斥消息取消

在發送消息時，優先將消息隊列中還未處理的信息已經過時的消息 移除，優化隊列

3，隊列優化-復用消息

創建消息時，優先採用之前回收的消息，避免重復創建對象，引起GC

完~
（如果錯誤或不足，望指出， 大家共同進步）