ANR Bug分析

ANR即Application Not Responding，顾名思义就是应用程序无响应。在Android中，一般情况下，四大组件均是工作在主线程中的，Android中的Activity Manager和Window Manager会随时监控应用程序的响应情况，如果因为一些耗时操作（网络请求或者IO操作）造成主线程阻塞一定时间（例如造成5s内不能响应用户事件或者BroadcastReceiver的onReceive方法执行时间超过10s），那么系统就会显示ANR对话框提示用户对应的应用处于无响应状态。

简单总结就是：

• 不要让主线程干耗时的工作
• 不要让其他线程阻塞主线程的执行

下面记录ANR bug分析过程：

一、
1、Application is not responding时机：

2、先看下是否是GC引起，搜索dalvikvm-heap，看下ANR前后GC情况

3、看下trace文件

4、查看cpuinfo

5、看下这两个线程分别在做什么事情
111115

111116

分析：发生ANR之前CPU占用不高，trace显示卡在startActivityForResult，该方法为系统方法不会出现耗时长的问题；主要原因是GC，ANR之前主要的内存分配在11115和11116线程

解决：加载图时，初始进入只加载首屏，不再全部加载。

二、
1、Application is not responding时机：

2、

3、trace文件

初步定位是某一个控件卡住了主线程

4、回到log中

找到该控件在ANR之前，在执行什么操作？确认是执行动画时卡住。

分析：发生ANR之前CPU占用不高，trace显示卡在某一个控件，调用startAnim；主要原因是GC引起。

解决：对于部分rom上，做限定动画，只限示静态图。

三、
1、Application is not responding时机：

2、

3、

4、

5、

6、

7、

8、

分析：从logcat看，ANR前出现两次大的时间跳变，均在7秒左右，跳变期便主要是播放器的xxx；
内存占用并不是很高，CPU占用率偏高，尤其是在UI跳变的时段，主要是播放器的IO占用CPU较高；从cpuinfo看占用最高的都是mediaserver的线程，解码时IO比较大，加上设备性能差，导致用率偏高，IO受阻。发生ANR。

解决：考虑到竞品也是一样的表现，受限于设备本身性能，导致解码时出现问题。