一、什麼是Anr：
application not responding 程序無響應。程序在規定的時間內沒有響應。
超時時間的計數一般是從按鍵分發給app開始。超時的原因一般有兩種：
1.當前的事件沒有機會得到處理（即UI線程正在處理前一個事件，沒有及時的完成或者looper被某種原因阻塞住了）；
2.當前的事件正在處理，但沒有及時完成。
二、Anr的主要原因
ANR一般有三種類型：
1：KeyDispatchTimeout(5 seconds) --主要類型
按鍵或觸摸事件在特定時間內無法得到響應
2：BroadcastTimeout(10 seconds)
BroadcastReceiver在的onRecieve運行在主線程中，短時間內無法處理完成導致
3：ServiceTimeout(20 seconds) --小概率類型
Service的各個聲明週期在特定時間內無法處理完成
Anr場景分析
1.使用命令導出anr日誌
adb pull /data/anr/traces.txt ~/Desktop/
2.分析關鍵信息
以每行的重點內容沒準，每行自帶時間戳
Process：anr發生的時間和進程，和生成traces文件的時間
CPUusage ... ago ：cpu在anr發生前的使用情況
CPUusage ...later: cpu在anr後的使用情況
ABI: 手機的cpu架構
HEAP: 堆的內存信息
ANR in：包名，和類名
Reason：原因
TOTAL：總的CPU使用率
prio:線程的優先級
tid：線程鎖id 主線程的id爲1 主要看這個線程的
Sleeping：線程的狀態
sCount：線程被掛起的次數
dsCount：線程是否被調試
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---****發生**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發生前的使用情況
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太高，導致系統將你的殺死。
2.如果TOTAL很小，則說明線程被阻塞了，主線程在等待下條消息的進入，任務在等待時anr。
3.如果ioWait很高，則說明是io操作導致的
分析
因爲主線程被阻塞導致的關鍵信息。
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讀寫導致的anr
關鍵點：ioWait很高，ContentResolver in AsyncTask onPostExecute
1.首先看到total中ioWait很高，說明是io操作導致的。
2.具體原因
可以看到關鍵詞sqlite，ContentResolver
在主線程進行了網絡訪問
關鍵詞OSNetworkSystem.receiveStream，net
內存不足導致
可以看到TOTAL的使用率有98，所以內存不足。
關鍵詞：VMWAIT，VMRuntime.trackExternalAllocation
廣播阻塞導致anr
android.intent.action.SCREEN_OFF廣播爲order，即如果其中註冊了此廣播的任何應用在處理此廣播時未返回，則會導致後續broadcast的失敗，出現ANR，導致系統無法喚醒。而導致廣播未被及時處理的原因，除了可能是由於對應的Receiver處理函數中一些操作長時間未完成外，也可能是由於整個應用進程被block了，從而沒有機會去調用Receiver函數。
1.針對onRecieve中的耗時操作，可以將業務單獨加入到一個線程中執行：
快速定位anr
1.如果是ANR問題 ， 則搜索“ANR”關鍵詞 。快速定位到關鍵事件信息 。
2.如果是ForceClosed(程序強制關閉) 和其它異常退出信息，則搜索"Fatal" 關鍵詞， 快速定位到關鍵事件信息 。
ANR的避免和檢測
使用StrictModel
它是android sdk提供的一個用來檢測代碼中是否存在違規操作的工具類
1.線程檢測策略
ThreadPolicy
1.detectCustomSlowCalls：檢測耗時操作
2.detectDiskWrites：檢測磁盤寫入
3.detectDiskRead：檢測磁盤讀取
4.detectNetWork：檢測網絡
5.detectAll：啓用所有策略
VmPolicy
虛擬機檢測策略
1.detectActivityLeaks：是否存在activity泄露
2.detectLeakedClosableObjects：是否存在沒有關閉的closable對象
3.detectLeakedSqlLiteObjects：是否存在sqlite對象泄露
4.detectClassInstanceLimit：是否存在實力個數超限制
5.detectALL：啓用所有策略
使用方式
在application的oncreate方法前
StrictMode.setThreadPolicy(new StrictModel.ThreadPolicy.Builder().detectAll().penaltyLog().build())；
//penlatyLog表示是否打印日誌。
最後這裏是關於我自己的Android 學習，面試文檔，視頻收集大整理，有興趣的夥伴們可以看看~