釋放雙眼，帶上耳機，聽聽看~！
在Android開發中，當程序發生異常時會拋出異常信息，先說下三種常見類型：
列表內容KeyDispatchTimeout(谷歌default 5s，MTK平臺上是8s) –主要類型
按鍵或觸摸事件在特定時間內無響應
BroadcastTimeout(10s)
BroadcastReceiver在特定時間內無法處理完成
ServiceTimeout(20s) –小概率類型
Service在特定的時間內無法處理完成
一些典型的ANR 問題場景
1)最常見錯誤，UI線程等待其它線程釋放某個鎖，導致UI線程無法處理用戶輸入；
2)游戲中每幀動畫都進行了比較耗時的大量計算，導致CPU忙不過來；
3)Web應用中，網絡狀態不穩定，而界面在等待網絡數據；
4)UI線程中進行了一些磁盤IO(包括數據庫、SD卡等等)的操作，在個別設備上因為硬件損壞等原因阻塞住了；
5)手機被其他App占用著CPU，自己獲取不到足夠的CPU 時間片，純屬誤傷。
排查分析的思路：
1、通過ANR 日志定位問題
當ANR發生時，我們往往通過Logcat和traces文件(目錄/data/anr/)的相關信息輸出去定位問題。主要包含以下幾方面：
1)基本信息，包括進程名、進程號、包名、系統build號、ANR 類型等等；
2)CPU使用信息，包括活躍進程的CPU 平均占用率、IO情況等等；
3)線程堆棧信息，所屬進程包括發生ANR的進程、其父進程、最近有活動的3個進程等等。
1.1首先通過Log來獲取異常信息
android系統會自動幫我們生成一個log日志輸出文件，在data/system/dropbox/下，真機測試需要root權限，模擬器在DDMS下可以查看。
用這種方法，出現問題，根本不需要斷點調試 ， 直接定位到問題，屢試不爽 。
從LOG可以看出ANR的類型，CPU的使用情況，
一般在如下幾種情況會產生log 。
1，程序異常退出 ， uncaused exception
2，程序強制關閉 ，Force Closed (簡稱FC)
3，程序無響應 ， Application No Response (簡稱ANR) ， 順便，一般主線程超過5秒么有處理就會ANR
步驟：
1.打開log文件 ， 由于是ANR錯誤，因此搜索”ANR ” ， 為何要加空格呢，你加上和去掉比較一下就知道了 。 可以屏蔽掉不少保存到anr.log文件的無效信息
定位到關鍵的事件信息如下：
01-15 16:49:02.433 E/ActivityManager( 2466): ANR in com.android.mms (com.android.mms/.ui.SlideshowActivity)
01-15 16:49:02.433 E/ActivityManager( 2466): Reason: keyDispatchingTimedOut
01-15 16:49:02.433 E/ActivityManager( 2466): Load: 0.6 / 0.61 / 0.42
01-15 16:49:02.433 E/ActivityManager( 2466): CPU usage from 1337225ms to 57ms ago:
01-15 16:49:02.433 E/ActivityManager( 2466): sensorserver_ya: 8% = 0% user + 8% kernel / faults: 40 minor
......
01-15 16:49:02.433 E/ActivityManager( 2466): -com.android.mms: 0% = 0% user + 0% kernel
01-15 16:49:02.433 E/ActivityManager( 2466): -flush-179:8: 0% = 0% user + 0% kernel
01-15 16:49:02.433 E/ActivityManager( 2466): TOTAL: 25% = 10% user + 14% kernel + 0% iowait + 0% irq + 0% softirq
01-15 16:49:02.436 I/ ( 2466): dumpmesg > "/data/log/dumpstate_app_anr.log"
我們用自然語言來描述一下日志，
01-15 16:49:02.433 E/ActivityManager( 2466): ANR in com.android.mms (com.android.mms/.ui.SlideshowActivity)
翻譯：在16:49分2秒433毫秒的時候 ActivityManager (進程號為2466) 發生了如下錯誤：com.android.mms包下面的.ui.SlideshowActivity 無響應 。
01-15 16:49:02.433 E/ActivityManager( 2466): Reason: keyDispatchingTimedOut
翻譯：原因 ， keyDispatchingTimeOut – 按鍵分配超時
01-15 16:49:02.433 E/ActivityManager( 2466): Load: 0.6 / 0.61 / 0.42
翻譯：5分鐘，10分鐘，15分鐘內的平均負載分別為：0.6 , 0.61 , 0.42
我們大概知道問題是什么了，問題是在點擊按鈕某時候可能處理不過來按鈕事件，導致超時無響應 。但我們不能準確的知道到底問題在哪兒 ， 只是猜測 ，比如這個應用程序中，多個IO操作的地方都在主線程中，可能引起問題，但不好判斷到底是哪個 ，所以我們目前掌握的信息還不夠 。
于是我們再分析虛擬機信息 ，搜索“Dalvik Thread”關鍵詞，快速定位到本應用程序的虛擬機信息日志
1.2通過分析trace文件得到ANR信息(真機導出，模擬機在DDMS下查看)
如果ANR發生，對應的應用會收到SIGQUIT異常終止信號，dalvik虛擬機就會自動在/data/anr/目錄下生成trace.txt文件，將異常信息寫入到traces文件中，系統會記錄異常的位置、CPU和內存當時的使用情況，通過查看日志基本就能判斷問題所在。
接下來用adb shell命令導出該文件，通過shell命令就可以了。
adb pull /data/anr/traces.txt d:/ =》意思是將手機上的traces.txt導出到電腦的d目錄下
或者
1、adb shell
2、cat /data/anr/xxx >/mnt/sdcard/yy/zz.txt
3、exit
4、adb pull /mnt/sdcard/yy/zz.txt d: ,即可將文件導出到了d盤。
在發生ANR時，
步驟：
1. 找到ANR關鍵字(大寫匹配)
2. 向上查找timeout關鍵字，這個時候能找到ANR的原因，如： Application do too much work in main thread 等。
3. 查看trace 文件找出出現的最終原因。
測試過程發現ANR的現狀
1、在平常測試中，ANR基本測試不到，因為ANR基本發生在垃圾設備中，弱網絡，頻繁操作。
2、問題不必現，即使看到了問題，定位麻煩：要去data/anr.txt 文件里面查找。必須root,沒有對應關系，分析復雜，導出文件就必須依賴手機零距離。
由于anr問題不必現，因此引入以下ANR檢測工具，當anr問題出現時，自動dump手機中的日志信息如trace文件、堆棧信息
基本原理
檢測到UI主線程卡頓時間超過設定的時間，如4s，即dump trace文件以及堆棧信息，同時拋出異常，收集信息，根據這些文件信息即可定位到發生anr的原因
1.3在源代碼中插入ANR檢測工具(BlockCanary、StrictMode)
1.4使用第三方SDK輸出Crach信息到后臺服務器：
如騰訊bugly 和umeng
