前言

ANR(Application Not Responding),应用程序无响应,会严重影响用户体验。作为测试开发人员更深入的理解 ANR 原理,可以更好的针对各类卡顿性能问题制定对应的监控策略。本文简单总结了 Android 系统的 ANR 监测与现有的监测方案的原理对比。

ANR 的触发条件

ANR 的本质是一个性能问题,即主线程中的耗时操作造成主线程堵塞,导致应用失去响应能力。常见的超时时限:

Service 与 Bradcast 只会打印 trace 信息,不会提示用户 ANR 弹窗,大部分可感知的 ANR 都是由于 InputEvent。

Android 对 ANR 的监控机制

Android 应用程序是通过消息来驱动的,Android 某种意义上也可以说成是一个以消息驱动的系统,UI、事件、生命周期都和消息处理机制息息相关。Android 的 ANR 监测方案也是一样,大部分就是利用了 Android 的消息机制。

InputEvent 的 ANR 与上图有些许不同,是在 Native 监控,但同样会堵塞主线程的消息队列,后面会讲到一部分监测场景。

应用 ANR 检测方案

目前流行的 ANR 检测方案有开源的 BlockCanary 、ANR-WatchDog、SafeLooper, 还有根据谷歌原生系统接口监测的方案:FileObserver。下面就针对这四种方案根据场景解析对比。

BlockCanary

BlockCanary 是国内开发者 markzhai 开发的一款非侵入式的轻量性能监控组件,在 Github 上有接近 4000 star。原理巧妙的利用了 Android 原生 Looper.loop 中的一个 log 打印逻辑。

这个 log 打印逻辑正是在 Message 消息分发前后,大部分的性能卡顿问题都是在这里发生的,监控这两个逻辑之间的时间差就可以得到当前主线程的卡顿状态,如果超时则获取 trace 信息并上报。具体实现:

ANR-WatchDog

ANR-WatchDog 是参考 Android WatchDog 机制(com.android.server.WatchDog.java)起个单独线程向主线程发送一个变量 +1 操作,自我休眠自定义 ANR 的阈值,休眠过后判断变量是否 +1 完成,如果未完成则告警。

SafeLooper

SafeLooper 是个比较新奇的思路,本身就是一个堵塞的消息,在自己内部进行消息的处理,通过反射接管主线程 Looper 的功能。

此方案使用反射进行 message 管理会有很大的性能损耗,但可以自由定制,这种 AOP 的思想是可以借鉴的。

FileObserver

有 ANR 的流程就可以知道/data/anr 文件夹的变化代表着 ANR 的发生,AMS 在 dumpStackTrace 方法中给了我们一些提示。

按照这个思路,当 ANR 发生的时候,我们是可以通过监听该文件的写入情况来判断是否发生了 ANR,看起来这是一个不错的时机。需要注意的是,所有应用发生 ANR 的时候都会进行回调,因此需要做一些过滤与判断,如包名、进程号等。ANR 生成的 trace 如图:

总结

本文汇总了目前主流的 ANR 监测方案的原理和实现,目前能了解到的方案并不太多,在 Goolge Play 上有 2.68% 实用率的 ACRA 库也只是推荐了 WatchDog 方式。建议 FileObserver 和 watchDog 组合使用,能覆盖绝大部分的机型和 ANR 异常。如果其他同学有更好的建议和方案欢迎交流,共同进步。

参考文献

https://github.com/ACRA/acra
https://github.com/markzhai/AndroidPerformanceMonitor
https://github.com/SalomonBrys/ANR-WatchDog
http://gityuan.com/2016/07/02/android-anr/
http://blog.csdn.net/zhudaozhuan/article/details/50964832


↙↙↙阅读原文可查看相关链接,并与作者交流