Android卡顿优化 | ANR分析与实战（附ANR-WatchDog源码分析及实战、与AndroidPerformanceMonitor的区别）

本文要点

• ANR概述
• 发生ANR后Android系统的执行流程
• ANR-WatchDog原理与实战
• ANR的传统解决套路
• ANR模拟实战
• 线上ANR监控方案【ANR-WatchDog原理分析】
• ANR-WatchDog实战
• ANR-WatchDog总结
• ANR-WatchDog与AndroidPerformanceMonitor的区别

项目GitHub

ANR概述

• KeyDispatchTimeout，5s
  即按键或者触摸事件，在特定的时间（一般5s）之内没有响应；

• BroadcastTimeout，前台10s，后台60s
  BroadReceiver 在特定的时间（一般前台10s，后台60s）之内没有响应完成；

• ServiceTimeout，前台20s，后台200s
  Service 在特定的时间（一般前台20s，后台200s）之内没有处理完成；

发生ANR后Android系统的执行流程

• APP发生ANR
• 进程接收异常终止信号，开始写入进程ANR信息（当时场景，包含当前线程所有堆栈信息、CPU/IO的使用情况等）；
• 弹出ANR提示框，提示用户关闭APP或者继续等待；（不同ROM表现不同，有的手机厂商会去掉这个提示框）

ANR的传统解决套路

• 【线下】在AS的Terminal中，使用
  adb pull data/anr/traces.txt 要存储在本地的路径
  导出上面提到的ANR现场信息文件；
  导出来后，便可对文件内容进行详细分析：从CPU、IO、锁冲突等原因思考；

ANR模拟实战

• 模拟ANR原因：锁冲突；
  

  更改代码：
  运行程序，等到程序ANR或崩溃，
  
  在Terminal使用刚刚提到的命令，导出ANR的信息文件：
  生成文件：
  打开文件，可以找到原因：
  上次的BlockCanary同样捕捉到原因：

线下套路其实就是在APP发生ANR时，
导出信息文件，
查看文件，结合代码进行分析；

线上ANR监控方案

• 通过FileOberver监控上述的ANR信息文件的变化，
  如果这个文件发生了变化，那就说明发生了ANR，
  那便可以把它上报到服务器，进行详细的分析；
  【高版本需注意权限问题】

• ANR-WatchDog

  • 依赖compile 'com.github.anrwatchdog:anrwatchdog:1.4.0'
  • 官网 https://github.com/SalomonBrys/ANR-WatchDog
  • 原理（源码分析）：ANRWatchDog本身就是Thread的子类：
    
    ANRWatchDog中，用一个绑定了主线程Looper的Handler，
    去处理_ticker【一个Runnable任务单元】；
    任务单元对一些值进行了处理，如_tick、_reported：
    _tick在初始为ANRWatchDog的全局变量时，被赋值为0；^^^^^^^^^^^^^^^^^
    在ANRWatchDog的run()中，
    首先被利用去判定_ticker被post没有（因为一开始就_tick为0的话说明_tick还没被post），
    没有便将_tick=加上卡顿周期，之后post了_ticker；
    此时_tick不为0！！^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    _ticker中的run()，再一次将_tick置零；^^^^^^^^^^^^^^^^^^^^^^^^^^
    所以只要_ticker不被处理，其run()便不会执行，
    _tick就不会被置零，
    
    由此根据_tick的值可以判断_ticker是否被处理了；
    _tick重新归零则主线程处理了_ticker，
    _tick不为零则判定主线程卡顿，它没处理_tick！！！！！！！！
    
    
    ANRWatchDog的run()中，
    用刚说的主线程Handler，post了_ticker这个任务，
    然后自己sleep一段时间【即一个卡顿周期，稍后细说】，
    如果sleep结束之后，如果_tick != 0 && !_reported，
    则说明主线程还没有处理_ticker的run()，
    没有处理_ticker这个任务单元,
    那便认为主线程发生了卡顿【如源码注释所示】：！！！！！！
    确定发生了卡顿，就开始封装一个ANRError，进行后续处理了：
    另外补充一下，
    ANRWatchDog提供了两个重载的构造器，
    提供给开发者对卡顿判定周期进行设置，开发者不设置则使用默认配置：
    【跟BlockCanary同一个德行】
    接着仔细看ANRError的构造流程
    这里是有两种构造方式New()、NewMainOnly()，其最终处理都差不多，
    就是通过mainLooper拿到主线程，
    再通过主线程拿到现场的堆栈信息，
    最后返回构造好的ANRError实例：
    拿到ANRError实例之后，
    通过_anrListener.onAppNotResponding(error);回调机制处理ANRError实例；
    
    回调机制就妙啊！^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    刚刚的_anrListener.onAppNotResponding(error);只是一个应用层上的调用；
    onAppNotResponding()的实现方式暴露给开发者了，
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    在外部可以通过setANRListener()自己定制包含不同处理方式的ANRListener：
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    开发者不定制，则使用框架自带的默认处理方式呗：
    处理方式简单粗暴哈，直接把ANRError丢出去，
    这样APP就直接崩溃了：
    ANRError乃是Error的子类：

ANR-WatchDog实战

• 引入依赖

• 初始化ANR-WatchDog：
• 还是上面那个项目，手动阻塞60s，
  运行程序，
  程序会5s后崩溃【5s是默认周期时间，崩溃操作见上面源码分析】
  在logcat定位关键字fatal，可以看到ANRError打印的信息，
  信息中包括了崩溃现场所有线程的堆栈信息；
  以及显示bug代码的位置；

优化：
当然默认的APP崩溃处理法并不妥当，
影响用户体验，
实际开发中，
我们可以自己定义ANRListener，自定义处理方式【上面说过了】，
把堆栈信息上报给服务器就是了！！！！

总结

• 非浸入式
• 弥补高版本无权限问题

与AndroidPerformanceMonitor的区别

• AndroidPerformanceMonitor：
  原理是基于Handler-Message机制，
  监控主线程每一个Message的执行，
  在每一个Message的分发执行前后，进行信息处理；
  （不足：
  一般没有阻塞的情况下，
  每一个Message的执行时间是非常短暂的，
  达不到ANR的级别；
  而且InputEvent在queue.next中block，不会继续执行dispatchMessage，
  而是从native回调给InputEventReceiver.dispatchInputEvent处理分发，
  所以BlockCanary也就无法监控到这类ANR）
• ANR-WatchDog：
  不管主线程是怎么执行的，
  只管最后的结果，
  我sleep一个周期之后，就要看我_tick值有没有被修改，
  没被修改就是ANR！
• AndroidPerformanceMonitor适合全程监控卡顿，
  ANR-WatchDog适合补充ANR监控；
  两者可以相辅相成，结合使用！

---

参考：

• 慕课网
  推荐：
• Android ANR监测方案解析【各个工具优缺点解析】
• 深入探索Android卡顿优化（下）