Android ANR 问题第一弹

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/abm1993/article/details/80455032
日常开发测试中,我们经常会遇到各种应用的ANR问题,什么是ANR?application not respond,说的就是你的应用无响应了,卡了
废话不多说,直接上干货
一:Android ANR 分三类
Input dispatch(系统的key,屏幕点击事件)处理超时 ANR timeout 5000ms
BroadcastReceiver 分发+处理超时ANR(广播超时一般指的都是有序广播即ordered类型的广播超时)
    前台广播(加了FLAG_RECEIVER_FOREGROUND)timeout 10000ms
    后台广播 timeout 60000ms
Service 启动+执行超时 ANR
    前台服务 timeout 20000ms
    后台服务 timeout 200000ms

二:分析处理ANR问题
搜索关键Log:am_anr,InputDispatcher
am_anr(通用的ANR第一时间点的Log,Input超时的时候有可能会有延迟),InputDispatcher(当有Input超时的时后,该Log打印时间点是ANR第一发生的时间点),
am_anr log都是由 (User|1|5),(pid|1|5),(Package Name|3),(Flags|1|5),(reason|3)组成的,我们根据reason去分类ANR类型,
然后根据不同的类型从am_anr开始点,往回看相应的timeout时间的Log,大致看一下timeout时间内,我们的应用,或者系统都在做什么。

trace文件一般存在data\anr目录,可以导出看一下,ANR发生时应用各个线程的调用堆栈信息,trace文件也是分析ANR问题的关键,但并不一定是绝对的准确,trace文件只是收集ANR发生时的某一时刻
的调用堆栈信息。某一时刻请自行体会,多看一点ANR问题,便能体会。

三:ANR问题发生常见原因
原因无非两种,要么应用自身原因,要么系统原因
自身原因:
Input dispatch timeout :一般是你的UI主线程做了耗时的操作,请注意Handler(异步处理操作,操作仍在UI主线程因为使用的是主线程的loop和messagequeue),HandlerThread的使用(真正的异步线程操作),
BroadcastReceiver timeout: 一般是你的onReceiver执行时间过长
Service timeout: 很少遇到

系统原因:
主要RAM不足,或者CPU资源不足导致的,需要系统优化自己的性能,
一般会有lowmemorykill的log等等

猜你喜欢

转载自blog.csdn.net/abm1993/article/details/80455032