作者：石器时期小古董
链接：https://www.jianshu.com/p/cfa9ed42e379
一、什么是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 waitstarted04-0113:12:11.572 I/WindowManager( 220): Input event dispatching timedout sending tocom.android.email/com.android.email.activity.SplitScreenActivity04-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:keyDispatchingTimedOut04-0113:12:15.872 E/ActivityManager( 220): Load: 8.68 / 8.37 / 8.5304-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 minor04-0113:12:15.872 E/ActivityManager( 220): 4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major04-0113:12:15.872 E/ActivityManager( 220): 0.9%52/spi_qsd.0: 0% user + 0.9% kernel04-0113:12:15.872 E/ActivityManager( 220): 0.5%65/irq/170-cyttsp-: 0% user + 0.5% kernel04-0113:12:15.872 E/ActivityManager( 220): 0.5%296/com.android.systemui: 0.5% user + 0% kernel04-0113:12:15.872 E/ActivityManager( 220): 100%TOTAL: 4.8% user + 7.6% kernel + 87% iowait04-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 minor04-0113:12:15.872 E/ActivityManager( 220): 16% 21603/__eas(par.hakan: 16% user + 0% kernel04-0113:12:15.872 E/ActivityManager( 220): 7.2% 21406/GC: 7.2% user + 0% kernel04-0113:12:15.872 E/ActivityManager( 220): 1.8% 21409/Compiler: 1.8% user + 0% kernel04-0113:12:15.872 E/ActivityManager( 220): 5.5%220/system_server: 0% user + 5.5% kernel / faults: 1 minor04-0113:12:15.872 E/ActivityManager( 220): 5.5% 263/InputDispatcher: 0% user + 5.5% kernel04-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表示是否打印日志。
是公司养活了你，还是你养活了公司？
赢利之后的4个流向
2020互联网公司挣扎求生图鉴
你上次ANR如何办理的？
