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。
解决:考虑到竞品也是一样的表现,受限于设备本身性能,导致解码时出现问题。