ANR检查定位分析工具

百度MTC是业界领先的移动应用测试服务平台，为广大开发者在移动应用测试中面临的成本、技术和效率问题提供解决方案。同时分享行业领先的百度技术，作者来自百度员工和业界领袖等。

一、ANR是什么

简单说，通常就是App运行的时候，duang~卡住了，怎么搞都动不了。当卡住超过一定时间，Android系统认为这就是一次“ANR（Application Not Responding）”。

具体说，在以下情况发生时，会发生ANR（可能在不同ROM中时间有所更改）：

• 用户的输入在5s内没被App响应；
• BroadcastReceiver的onReceiver()超过10s；
• Service中各生命周期函数执行超过20s。

 

二、ANR必须死

用户在App的绝大部分操作，都需要有App的主动回应，比如按下按钮之后按钮样式的改变、下拉滚动条内容的移动、加载资源时的进度条转转转，它们都是“操作-反馈”配对的模式。对于我们手机上最常见的触摸操作，0.1s的响应延迟已经有很明显的卡顿感了。而对于常见的ANR，用户至少要等5s以上！

 

发生了ANR，往往会弹出对话框，问用户是继续等待还是直接关掉：

相信几乎所有Android手机用户都见过这个然并卵的ANR对话框，但大部分普通用户根本不知道这个对话框在讲什么，并且往往也只有关闭App。漫长的等待就给我看这个？从用户的体验看，就是心中一万只草泥马奔腾起来撞火车的感受。可见ANR对于应用的影响并不亚于Crash。

一般来说，界面相对越不“流畅”的App（说明UI线程耗时操作多）越容易发生ANR（一个输入事件在某个设备A上4秒有了反馈，并不意味着它在其他设备B上是安全的）。ANR其实就是界面卡顿的极端情况。反过来，只要通过合理的方案消灭了App出现的ANR，往往也同时会使App展示界面表现会更加顺滑流畅。

一些典型的ANR问题场景

1）最常见的错误，UI线程等待其它线程释放某个锁，导致UI线程无法处理用户输入；

2）游戏中每帧动画都进行了比较耗时的大量计算，导致CPU忙不过来；

3）Web应用中，网络状态不稳定，而界面在等待网络数据；

4）UI线程中进行了一些磁盘IO（包括数据库、SD卡等等）的操作，在个别设备上因为硬件损坏等原因阻塞住了；

5）手机被其他App占用着CPU，自己获取不到足够的CPU时间片，纯属误伤。

通过ANR日志定位问题

当ANR发生时，我们往往通过Logcat和traces文件（目录/data/anr/）的相关信息输出去定位问题。主要包含以下几方面：

1）基本信息，包括进程名、进程号、包名、系统build号、ANR类型等等；

2）CPU使用信息，包括活跃进程的CPU平均占用率、IO情况等等；

3）线程堆栈信息，所属进程包括发生ANR的进程、其父进程、最近有活动的3个进程等等。

三、测试过程发现ANR的现状

1、在平常测试中，ANR有基本测试不到，因为ANR基本发生在垃圾设备中，弱网络，频繁操作。

2、问题不必现，即使看到了问题，定位麻烦：要去data/anr.txt文件里面查找。必须root,没有对应关系，分析复杂，导出文件就必须依赖手机零距离。

 

四、引入ANR检测工具

由于anr问题不必现，因此引入以下ANR检测工具，当anr问题出现时，自动dump手机中的日志信息如trace文件、堆栈信息等，基本原理如下：

4.1、基本原理

         检测到UI主线程卡顿时间超过设定的时间，如4s，即dump trace文件以及堆栈信息，同时抛出异常，收集信息，根据这些文件信息即可定位到发生anr的原因

 

4.2、ANR检测工具在Baidu Browser中的应用

4.2.1如何在源代码中插入anr检测工具

步骤一：源代码libs中添加anr.jar

 

步骤二：在 Application 的onCreate中添加初始化sdk的代码

initSDK(Context context, String appKey, boolean watchdog, int time)

其中time表示检测判定线程是否超时（发生anr）的门限值，单位：ms

 

步骤三：正常编译打包apk

 

4.2.2如何测试发现并定位anr问题

Ø 安装步骤4.2.1编译打包插入anr检测的apk

Ø 测试app，任意操作（monkey/case），当发生anr时，会自动杀掉进程，并在本地生成日志文件日志路径：/sdcard/lynq_anr下有两个文件夹

 

以Baidu Browser启动为例。

Baidu Browser启动过程主线程过长，在低端机上容易导致发生anr；线程超时，app进程kill掉，查看手机本地trace日志，Crash信息包括trace文件以及堆栈信息

 

Ø 分析trace文件

Trace文件通过eclipse中的DDMS可以查看具体发生ANR卡顿的原因

通过real Time/Call从大到小排序，找到对应的与代码相关消耗时间最大的方法

可以看出书签数据库初始化消耗CPU时间最长。

 

Ø 查看耗时最长方法对应的源代码

找到对应的源代码如下：

主要是数据库的初始化在启动的主线程中进行，容易导致超时在低端机上发生anr问题。

更多干货分享请关注”百度MTC学院“http://mtc.baidu.com/academy/article