每日一道面試題（第8期）---ANR出現的場景以及解決方案

零零碎碎的東西老是記不長久，僅僅學習別人的文章也只是他人咀嚼後留下的殘渣。無心中發現了這個每日一道面試題，想了想若是隻是簡單地去思考，那麼不只會收效甚微，甚至難一點的題目本身可能都懶得去想，堅持不下來。因此不如把每一次的思考、理解以及別人的看法記錄下來。不只加深本身的理解，更要激勵本身堅持下去。

ANR： application not response，應用程序沒有響應。Android應用程序基於消息處理機制保證在發生輸入、觸摸等須要響應的事件以後，在規定的時間內沒有獲得有效的響應或者響應時間過長，都會發生ANR，彈出ANR對話框---等待應用或者退出應用。

Android中的響應性事件處理受到Activity Manager Service、Window Manager Service這兩個系統服務的監視，全部與ANR相關的消息，都通過系統進程（system_service）的調度，而後分發給應用進程進行實際的消息處理。系統進程經過系統服務的監視，根據不一樣的狀況限制不一樣的超時時長，一旦在限制的時間內得不到響應，就會調用AppNotRespondingDialog.show()顯示ANR對話框。

實際上，Android的主線程，也就是用來繪製View的UI線程，是線程不安全的，因此就使用ANR原則對主線程進行限制，保證主線程在串行處理事件時保持流暢性，給用戶良好的體驗（好比UI的繪製工做必須在16ms內完成）。因此在主線程中的全部耗時操做（密集型cup操做、網絡請求、大量IO等），都有可能發生ANR。

Android四大組件Activity、Service、BroadcastReceiver、ContentProvider都是運行在主線程中，對此定義不一樣的標準限制它們的響應時長：

• Service TimeOut：Service：前臺Service（通知欄有顯示）20s內、後臺Service200s內
• BroadcastQueue TimeOut：BroadcastReceiver中，前臺廣播10s，後臺廣播60s。
• ContentProvider TimeOut：在publish中超過10s
• InputDispatching TimeOut：鍵盤輸入事件、觸摸事件5s內得不到響應

ANR監測機制： 總體的一個大體流程就是---事件開始前進行計時->進行事件處理->事件處理完，限制時間沒到，移除計時，系統正常進行。事件沒處理完，限制時間已到，移除計時，彈出ANR對話框

發生事件處理超時的狀況有兩種：

• 當前事件沒有機會獲得處理，主線程正在響應另外的時間，當前事件被阻塞
• 當前事件正在處理，但處理事件過長致使長時間得不到響應

ANR預防： 耗時操做在儘可能子線程中操做---AsyncTask、intentService、HandlerThread，多線程操做避免死鎖的出現以及快速的解決辦法，還有就是UI層次的複雜繪製，儘可能減小布局嵌套，若是Activity初始化須要必定的耗時，能夠考慮立刻顯示Activity顯示Dialog加載框異步加載數據。