其实和app无关的anr问题分析

每个Android程序员都会遇到anr问题，anr问题的根源是代码处理中超时，例如超时广播处理超时10s之类的。处理的方法百度google可以见到千篇一律的主线程不要做耗时操作，这个是没错，不过依据我个人这几年的经验来看，大部分app遇到的anr问题和app自生是没有任何关系的。看一份日志：

08-19 12:14:57.269475  1111  1130 E ANRManager: ANR in com.android.incallui, time=104273863
08-19 12:14:57.269475  1111  1130 E ANRManager: Reason: Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x50000010 }
08-19 12:14:57.269475  1111  1130 E ANRManager: Load: 9.35 / 8.88 / 8.57
08-19 12:14:57.269475  1111  1130 E ANRManager: Android time :[2017-08-19 12:14:57.26] [104277.344]
08-19 12:14:57.269475  1111  1130 E ANRManager: CPU usage from 8312ms to 0ms ago:
08-19 12:14:57.269475  1111  1130 E ANRManager:   99% 1013/kworker/5:2: 0% user + 99% kernel
08-19 12:14:57.269475  1111  1130 E ANRManager:   12% 1111/system_server: 8.9% user + 3.3% kernel / faults: 10372 minor 39 major
08-19 12:14:57.269475  1111  1130 E ANRManager:   5% 19573/com.android.systemui: 2.6% user + 2.4% kernel / faults: 1851 minor 19 major
08-19 12:14:57.269475  1111  1130 E ANRManager:   4.9% 334/surfaceflinger: 2.1% user + 2.7% kernel / faults: 309 minor
08-19 12:14:57.269475  1111  1130 E ANRManager:   2.6% 6479/com.netease.mail: 1.9% user + 0.7% kernel / faults: 3681 minor 119 major
08-19 12:14:57.269475  1111  1130 E ANRManager:   2.4% 215/mmcqd/0: 0% user + 2.4% kernel
08-19 12:14:57.269475  1111  1130 E ANRManager:   0.7% 362/fingerprintd: 0% user + 0.7% kernel / faults: 99 minor 1 major
08-19 12:14:57.269475  1111  1130 E ANRManager:   2% 6614/com.netease.mail:pushservice: 1.2% user + 0.8% kernel / faults: 4560 minor 60 major
08-19 12:14:57.269475  1111  1130 E ANRManager:   0% 32044/kworker/8:1: 0% user + 0% kernel
08-19 12:14:57.269475  1111  1130 E ANRManager:   1.2% 7718/cn.kidyn.qdmedical160:pushservice: 0.8% user + 0.3% kernel / faults: 3180 minor 28 major
08-19 12:14:57.269475  1111  1130 E ANRManager:   0.6% 61/dlpt_notify_thr: 0% user + 0.6% kernel

trace如下：

----- pid 2378 at 2017-08-19 12:14:53 -----
Cmd line: com.android.incallui
...

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x76af3f88 self=0x7f8703c400
  | sysTid=2378 nice=0 cgrp=default sched=0/0 handle=0x7f8aec02c0
  | state=S schedstat=( 186406401691 149117611257 631811 ) utm=14323 stm=4317 core=7 HZ=100
  | stack=0x7fc2bda000-0x7fc2bdc000 stackSize=8MB
  | held mutexes=
  at android.hardware.SystemSensorManager$BaseEventQueue.nativeDisableSensor(Native method)
  at android.hardware.SystemSensorManager$BaseEventQueue.disableSensor(SystemSensorManager.java:417)
  at android.hardware.SystemSensorManager$BaseEventQueue.removeAllSensors(SystemSensorManager.java:347)
  at android.hardware.SystemSensorManager.unregisterListenerImpl(SystemSensorManager.java:155)
  - locked <0x019000a9> (a java.util.HashMap)
  at android.hardware.SensorManager.unregisterListener(SensorManager.java:625)
  at android.view.OrientationEventListener.disable(OrientationEventListener.java:108)
  at com.android.incallui.InCallActivity.onStop(InCallActivity.java:470)
  at android.app.Instrumentation.callActivityOnStop(Instrumentation.java:1289)
  at android.app.Activity.performStop(Activity.java:6413)
  at android.app.ActivityThread.handleSleeping(ActivityThread.java:3845)
  at android.app.ActivityThread.-wrap19(ActivityThread.java:-1)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1672)
  at android.os.Handler.dispatchMessage(Handler.java:111)
  at android.os.Looper.loop(Looper.java:207)
  at android.app.ActivityThread.main(ActivityThread.java:5727)
  at java.lang.reflect.Method.invoke!(Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:891)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:752)

mainlog中是说处理广播超时，如果是广播处理超时那么trace日志中主线程堆栈一定是在广播处理的onReceive中，但是可见trace中的堆栈和anr所报没有啥关系。

其实在mainlog中已经给出了anr原因的解释，pid为1013的进程占用了99%的cpu，而且全部是在运行kernel层的代码。

ANRManager处理超时是不会管具体超时原因的，任何超时都会导致正在处理的app进程抛anr出来，但是有可能和app没有任何关系，anr的出口肯定是app，抛出anr的app只是正好撞在了枪口上。由于这个anr机制的原因，anr问题永远不会被消灭，无论你的app代码写的效率再高再完美。