android ANR总结

application not response总结

引发ANR主要2类：

• 主线程繁忙，来不及处理消息；
• 系统繁忙，主线程得不到调度，比如cpu负载过高，降频。

Service： 前台20秒/后台200秒
Broadcast：前台10秒/后台60秒
ContentProvider: 10秒
Input Event： 5秒

Service超时：
onBind中做了耗时的网络初始化工作。改成异步，并确保使用的地方初始化已经完成；
Provider超时：
耗时操作。
Broadcast超时：
静态广播，冷启动的时候，容易触发；改成动态。
SP问题：
1. 初始化SP是异步的；但是如果马上去读取就卡住了；解决办法，多分几个名字来存储，保证每一个比较小；
2. 在ActivityThread处理生命周期Pause/Stop（服务|Activity）， QueueWork.waitToFinish的时候卡住。
解决办法，hook sFinished poll。不让他等待了。网上一大堆代码。
3. 自己实现SP。
其他问题：
主线程消息等待中

监控方案：
blockCanary，ANR-watchDog。 FileObserver, 插桩。
监听“android.intent.action.ANR”广播

特殊case：案例分析：

1，焦点Window丢失
Reason: Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.)
2，input事件处理超时
Reason: Input dispatching timed out (Waiting to send key event because the focused window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: 0. Wait queue length: 1.)
有的时候也并非系统卡顿、CPU过载等问题，而是因为dump profile的监控工具正在抓取日志导致时间消耗，然后monkey的快速点击，来回切换activity超时。
可以针对如下日志，找寻一下，可以忽略这种因为提取系统内存信息的dump导致的anr。

ActivityManager: dumpHeapFinished
hprof heap dump