ANR一般性分析方法

Posted 2020-07-14

android项目的ANR问题经常让开发者困扰。究其原因，有些ANR问题很难定位。

若ANR和普通crash一样，打出耗时操作的调用栈，那么想办法修复就好了。

最近项目中的ANR问题较为严重，相信每个快速膨胀的app都会经历这个时刻，总结一些经验供大家参考。

 

ANR原因

ANR是耗时操作造成。

若有A/B/C事件串行执行于UI线程，当C事件发生ANR时，说明A->B->C太耗时了，并不能确定耗时操作在哪个具体事件上。

 

ANR基本定位

ANR的有用信息，我们需要在trace文件中获取。

trace文件路径：data\anr\traces_packageName.txt

在trace文件中，我们能够看到如下信息

DALVIK THREAD（14）表明trace文件中收集了14个线程的信息与调用栈。

下面的"main"指的是主线程，我们分析"main"所在的片段即可定位ANR。

图中所示，调用栈指向了com.puff.test.MainActivity.onResume方法，这就是ANR发生的原因，调用到onResume方法时，超时了！

 

ANR定位不准

当跟随调用栈查看onResume方法时，我们发现唯一的操作便是耗时操作

onResume阻塞了2s，造成了ANR。但是Activity的超时需要5s未响应，看来ANR的原因不仅仅是onResume造成的。

我们继续跟踪onResume之前调用的onCreate与onStart

  

所以根据trace文件定位ANR未必能准确，trace只给出了造成ANR的直接原因，间接原因仍然需要分析。

 

ANR辅助定位——BlockCanary

通过trace文件能够确定发生ANR的位置，但只是压死骆驼的最后一根稻草。

而BlockCanary工具却能统计到过程中所有耗时操作(耗时阈值由自己设置)。

 

原理比较简单，通过替换Looper的Printer达到计算msg处理的耗时。

同时也提供了一些很有帮助的参数，譬如总耗时与线程耗时，可用内存等。

具体内容可详见 BlockCanary

 

ANR辅助定位——埋点

通过trace文件与BlockCanary工具基本上可以定位耗时操作了，不过仍然有些情况会让人困扰。

若query(*,*)是耗时操作，在onStart中调用了多次，造成了onResume产生ANR，那么虽然能定位query是耗时操作，却不能确定是哪个操作真正耗时。

方法内多次调用同一耗时操作，那么就果断埋点吧！

通过埋点统计操作用时，即可更准确定位耗时操作。

 

多次采样确定ANR耗时操作

ANR不好复现，耗时操作的耗时也不稳定，通过多次采样来确定耗时操作似乎已经是通用方案了。

若是层级较深或复杂操作才能触发耗时操作的，推荐使用iTestin工具进行自动化测试。

iTestin工具的功能非常丰富，常用的操作都可以通过iTestin来模拟进行，更多的内容就阅读文档吧http://i.testin.cn/。

若是比较简单的操作，可以直接通过adb的shell命令进行自动化测试了。

譬如上例中onResume经常发生ANR，那么多次启动并关闭就可以多次采样了。

adb shell am start com.puff.test/com.puff.test.MainActivity

adb shell am kill com.puff.test

便可执行启动与关闭页面，我们再循环执行一定次数就可以采样了。