導致ANR的幾種情況

• KeyDispatchTimeout（5s）：按鍵或觸控事件在特定時間內無法處理完成

• BroadcastTimeout（前臺10s，後臺60s）：廣播在特定時間內無法處理完成

• ServiceTimeout（前臺20S，200S後臺）：服務在特定的時間無法處理完成另外還有ProviderTimeout看門狗和等導致的ANR

常見的原因

A.耗時操作，如複雜的layout，龐大的for迴圈，IO等。
B.被Binder 對端block
C.被子執行緒同步鎖block
D.Binder被佔滿導致主執行緒無法和SystemServer通訊
E.得不到系統資源（CPU/RAM/IO）
其中ABCD比較好分析，而E比較困難。

應用ANR產生的時候，ActivityManagerService的appNotResponding方法就會被呼叫，然後在檔案中寫入/data/anr/traces.txt ANR相關資訊。

通常發生了ANR，ActivityManager會列印報錯資訊：

日誌分析：

ANR日誌列印了的基本資訊，我們可以分析CPU使用率得知ANR的簡單情況;如果CPU使用率很高，100％接近，可能在進行大規模的計算更可能的英文陷入死迴圈;如果使用CUP率很低，說明主執行緒被阻塞了，並且當IOWAIT很高，可能是主執行緒在等待I / O操作的完成。
對於ANR只是分析日誌很難知道問題所在，我們還需要透過跟蹤檔案分析棧呼叫情況。

traces.txt是如何生成的

當APP（APP包括系統和使用者APP）程式出現ANR，應用響應慢或看門狗的監視沒有得到回饋時，系統會傾倒此時的程式之上，執行緒程式中的執行狀態就都到這個跟蹤轉儲檔案中了。每次發生ANR，這個檔案都會被清空，寫入新的內容。如果想檢視以前發生ANR的資訊，可以去檢視檔案DB。

DropBox中的日誌

traces.txt只保留最後一次發生時的資訊ANR的Android 2.2開始增加了功能的Dropbox，保留歷史上發生的所有的ANR日誌。
“/資料/系統/保管箱” DB是指定的檔案存放位置。
天3日誌儲存的最長時間

原文：