參考文章：http://blog.csdn.net/dadoneo/article/details/8270107
書籍：Andriod高階進階
一、什么是Anr：
application not responding 程序無響應(yīng)。程序在規(guī)定的時間內(nèi)沒有響應(yīng)。
超時時間的計數(shù)一般是從按鍵分發(fā)給app開始。超時的原因一般有兩種：**
1.當前的事件沒有機會得到處理（即UI線程正在處理前一個事件，沒有及時的完成或者looper被某種原因阻塞住了）
2.當前的事件正在處理，但沒有及時完成
二、Anr的主要原因
ANR一般有三種類型：
1：KeyDispatchTimeout(5 seconds) --主要類型
按鍵或觸摸事件在特定時間內(nèi)無法得到響應(yīng)
2：BroadcastTimeout(10 seconds)
BroadcastReceiver在的onRecieve運行在主線程中，短時間內(nèi)無法處理完成導(dǎo)致
3：ServiceTimeout(20 seconds) --小概率類型
Service的各個聲明周期在特定時間內(nèi)無法處理完成
Anr場景分析
1.使用命令導(dǎo)出anr日志
adb pull /data/anr/traces.txt ~/Desktop/
**2.分析關(guān)鍵信息
以每行的重點內(nèi)容沒準，每行自帶時間戳
Process：anr發(fā)生的時間和進程，和生成traces文件的時間
CPUusage ... ago ：cpu在anr發(fā)生前的使用情況
CPUusage ...later: cpu在anr后的使用情況
ABI: 手機的cpu架構(gòu)
HEAP: 堆的內(nèi)存信息
ANR in： 包名，和類名
Reason：原因
TOTAL：總的CPU使用率
prio:線程的優(yōu)先級
tid：線程鎖id 主線程的id為1 主要看這個線程的
Sleeping：線程的狀態(tài)
sCount：線程被掛起的次數(shù)
dsCount：線程是否被調(diào)試
04-01 13:12:11.572** I/InputDispatcher( 220): Application is not responding**:Window{2b263310com.[Android](http://lib.csdn.net/base/android).email/com.android.email.activity.SplitScreenActivitypaused=false}. 5009.8ms since event, 5009.5ms since waitstarted
04-0113:12:11.572 I/WindowManager( 220): Input event dispatching timedout sending tocom.android.email/com.android.email.activity.SplitScreenActivity
04-01 **13:12:14.123 I/Process( 220): Sending signal. PID: 21404 SIG: 3---****發(fā)生**ANR**的時間和生成**trace.txt**的時間**
04-01 13:12:14.123 I/dalvikvm(21404):threadid=4: reacting to signal 3
……
04-0113:12:15.872 E/ActivityManager( 220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
04-0113:12:15.872 E/ActivityManager( 220): Reason:keyDispatchingTimedOut
04-0113:12:15.872 E/ActivityManager( 220): Load: 8.68 / 8.37 / 8.53
04-0113:12:15.872 E/ActivityManager( 220): **CPUusage from 4361ms to 699ms ago** ----CPU在ANR發(fā)生前的使用情況
04-0113:12:15.872 E/ActivityManager( 220): 5.5%21404/com.android.email: 1.3% user + 4.1% kernel / faults: 10 minor
04-0113:12:15.872 E/ActivityManager( 220): 4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major
04-0113:12:15.872 E/ActivityManager( 220): 0.9%52/spi_qsd.0: 0% user + 0.9% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%65/irq/170-cyttsp-: 0% user + 0.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): 0.5%296/com.android.systemui: 0.5% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): **100%TOTAL: 4.8% user + 7.6% kernel + 87% iowait**
04-0113:12:15.872 E/ActivityManager( 220): **CPUusage from 3697ms to 4223ms later**:-- ANR后CPU的使用量
04-0113:12:15.872 E/ActivityManager( 220): 25%21404/com.android.email: 25% user + 0% kernel / faults: 191 minor
04-0113:12:15.872 E/ActivityManager( 220): 16% 21603/__eas(par.hakan: 16% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 7.2% 21406/GC: 7.2% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 1.8% 21409/Compiler: 1.8% user + 0% kernel
04-0113:12:15.872 E/ActivityManager( 220): 5.5%220/system_server: 0% user + 5.5% kernel / faults: 1 minor
04-0113:12:15.872 E/ActivityManager( 220): 5.5% 263/InputDispatcher: 0% user + 5.5% kernel
04-0113:12:15.872 E/ActivityManager( 220): **32%TOTAL: 28% user + 3.7% kernel**
典型的分析情況
1.如果TOTAL的和接近100，有可能是因為當前使用的app占用的cpu太高，導(dǎo)致系統(tǒng)將你的殺死。
2.如果TOTAL很小，則說明線程被阻塞了，主線程在等待下條消息的進入，任務(wù)在等待時anr。
3.如果ioWait很高，則說明是io操作導(dǎo)致的
分析
因為主線程被阻塞導(dǎo)致的關(guān)鍵信息。
at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:119)
at android.os.Looper.loop(Looper.java:110)
DALVIK THREADS:(mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0
hwll=0)"main" prio=5 tid=1NATIVE | group="main" sCount=1
dsCount=0obj=0x2aad2248 self=0xcf70 | sysTid=21404 nice=0
sched=0/0cgrp=[fopen-error:2]
handle=1876218976
**at android.os.MessageQueue.nativePollOnce(Native Method)
at android.os.MessageQueue.next(MessageQueue.java:119)
at android.os.Looper.loop(Looper.java:110**)
at android.app.ActivityThread.main(ActivityThread.java:3688)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624)
at dalvik.system.NativeStart.main(Native Method)
io讀寫導(dǎo)致的anr
關(guān)鍵點：ioWait很高，ContentResolver in AsyncTask onPostExecute
1.首先看到total中ioWait很高，說明是io操作導(dǎo)致的。
2.具體原因
可以看到關(guān)鍵詞sqlite，ContentResolver
在主線程進行了網(wǎng)絡(luò)訪問
關(guān)鍵詞OSNetworkSystem.receiveStream，net
內(nèi)存不足導(dǎo)致
可以看到TOTAL的使用率有98，所以內(nèi)存不足。
關(guān)鍵詞：VMWAIT，VMRuntime.trackExternalAllocation
廣播阻塞導(dǎo)致anr
android.intent.action.SCREEN_OFF廣播為order，即如果其中注冊了此廣播的任何應(yīng)用在處理此廣播時未返回，則會導(dǎo)致后續(xù)broadcast的失敗，出現(xiàn)ANR，導(dǎo)致系統(tǒng)無法喚醒。而導(dǎo)致廣播未被及時處理的原因，除了可能是由于對應(yīng)的Receiver處理函數(shù)中一些操作長時間未完成外，也可能是由于整個應(yīng)用進程被block了，從而沒有機會去調(diào)用Receiver函數(shù)。
1.針對onRecieve中的耗時操作，可以將業(yè)務(wù)單獨加入到一個線程中執(zhí)行
快速定位anr
1.如果是ANR問題 ， 則搜索“ANR”關(guān)鍵詞 。 快速定位到關(guān)鍵事件信息 。
2.如果是ForceClosed(程序強制關(guān)閉) 和其它異常退出信息，則搜索"Fatal" 關(guān)鍵詞， 快速定位到關(guān)鍵事件信息 。
ANR的避免和檢測
使用StrictModel
它是android sdk提供的一個用來檢測代碼中是否存在違規(guī)操作的工具類
1.線程檢測策略
ThreadPolicy
1.detectCustomSlowCalls：檢測耗時操作
2.detectDiskWrites：檢測磁盤寫入
3.detectDiskRead：檢測磁盤讀取
4.detectNetWork：檢測網(wǎng)絡(luò)
5.detectAll：啟用所有策略
VmPolicy
虛擬機檢測策略
1.detectActivityLeaks：是否存在activity泄露
2.detectLeakedClosableObjects：是否存在沒有關(guān)閉的closable對象
3.detectLeakedSqlLiteObjects：是否存在sqlite對象泄露
4.detectClassInstanceLimit：是否存在實力個數(shù)超限制
5.detectALL：啟用所有策略
使用方式
在application的oncreate方法前
StrictMode.setThreadPolicy(new StrictModel.ThreadPolicy.Builder().detectAll().penaltyLog().build())；
//penlatyLog表示是否打印日志。
