为了账号安全,请及时绑定邮箱和手机立即绑定

Android ANR全解析&华为AGC性能管理解决ANR案例集

标签:
Android

1、ANR介绍

1.1 ANR是什么

ANR,全称为Application Not Responding,也就是应用程序无响应。如果 Android 应用的界面线程处于阻塞状态的时间过长,就会触发“应用无响应”(ANR) 的错误。

此时系统会向用户显示一个对话框,ANR 对话框会为用户提供强行退出应用的选项。
在这里插入图片描述

1.2 ANR的四种类型

  在Android系统中,应用程序的响应由Activity Manager及Window Manager两个系统服务所监控。通常情况下,应用出现如下四类情况时,系统将报ANR:

  • KeyDispatchTimeout(最常见类型)—— input事件5s内未处理完成导致ANR发生,主要为按键和触摸事件;

日志关键字:InputDispatching Timeout

  • BroadcastTimeout:—— BroadcastReceiver在特定时间内未处理完成导致ANR发生(限制:前台广播10s;后台广播60s);

日志关键字:Timeout of broadcast BroadcastRecord

  • ServiceTimeout —— Service在特定的时间内未处理完成导致ANR发生。(限制:前台服务20s;后台服务200s);

日志关键字:Timeout executing service

  • ContentProviderTimeout —— 内容提供者,在10s内未处理完成导致ANR发生;

日志关键字:Timeout publishing content providers

1.3 ANR的发生原因

经过大量ANR案例的分析,总结出以下三个ANR问题产生的典型场景:

  • 主线程被其他线程锁(占比57%):调用了thread的sleep()、wait()等方法,导致的主线程等待超时。

  • 系统资源被占用(占比14%):其他进程系统资源(CPU/RAM/IO)占用率高,导致该进程无法抢占到足够的系统资源。

  • 主线程耗时工作导致线程卡死(占比9%):例如大量的数据库读写,耗时的网络情况,高强度的硬件计算等。

2、解决ANR问题方法论

2.1 总体思路

  1. 导出ANR日志信息,根据日志信息,判断确认发生ANR的包名类名,进程号,发生时间,导致ANR原因类型等。

  2. 关注系统资源信息,包括ANR发生前后的CPU,内存,IO等系统资源的使用情况。

  3. 查看主线程状态,关注主线程是否存在耗时、死锁、等锁等问题,判断该ANR是App导致还是系统导致的。

  4. 结合应用日志,代码或源码等,分析ANR问题发生前,应用是否有异常,其中具体问题具体分析。

2.2 导出ANR日志

ANR问题发生时,系统会收集ANR相关的日志信息,CPU使用情况,trace日志也就是各线程执行情况等信息,生成一个traces.txt的文件并且放在/data/anr/路径下。

注意:每一次新的ANR问题的发生,会把之前的ANR信息覆盖掉。

我们可以通过adb命令将traces文件导出到本地。

    adb root     
    adb shell ls /data/anr     
    adb pull /data/anr/<filename>

2.3 读取关键日志信息

1)在log中找到ANR发生信息:
Traces文件中的关键字,例如:

09-24 15:20:20.211 1001 1543 1570 XXXXXXX: ANR in xxxxxx 
09-24 15:20:20.211 1001 1543 1570 XXXXXXX: PID: xxxxx 
09-24 15:20:20.211 1001 1543 1570 XXXXXXX: Reason: xxxxxx

其中:

  • ANR in中,包括导致ANR的包名,类名

  • PID 中,为发生ANR的进程PID

  • Reason 中,为导致ANR的原因,例如keyDispatchingTimedOut

2)找到CPU Usage信息

09-24 15:20:20.211 1001 1543 1570 XXXXXX: CPUusage from xxx to xxx ago xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 
09-24 15:20:20.211 1001 1543 1570 XXXXXX: CPUusage from xxx to xxx later xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

其中

  • ago 表示ANR发生前的CPU的使用情况

  • later表示ANR发生后的CPU的使用情况

  • 重点关注xxx%TOTAL: xxx% user + xxx% kernel + xxx% iowait,可通过这几项了解到CPU的占用情况。

2.4 具体分析

分析CPU usage以后,如若还是无法找出问题原因,则需要进一步分析trace文件。traces文件中详细记录了发生ANR前后该进程的各个线程的Stack,一般从主线程的stack入手分析,查看分析ANR问题发生前,应用是否有异常。

其中不同场景下的ANR问题情况不大相同,需要具体情况具体分析,此处就不展开详细描述。

3、ANR问题难点及破题思路

3.1 ANR难点

  用户在应用内的绝大部分操作,比如按钮点击,加载资源,页面跳转等操作,都需要有App的主动反馈,但ANR发生时,在用户等待数秒后,仅会弹出一个“应用无响应”的弹窗给用户,这会给用户带来“应用难用”的感觉,极其影响用户体验。

  但是,现网中的ANR问题又很难处理,问题包括但不限于:

  1. 平时的测试难以覆盖,毕竟ANR经常出现在老设备、弱网络环境的场景下,测试难以做到全场景覆盖。

  2. 对于现网应用的ANR问题,如果问题非必现,则定位难度较高,需要有可以复现问题的实际设备在身边,才能获取到具体日志trace等信息。

  3. ANR问题定位复杂,影响因素多,一些新负责定位ANR问题的同学,上手困难,问题解决比较依赖经验。

3.2 ANR处理新方案

除了依赖现有传统的ANR问题定位经验,配合第三方应用监控平台、进行ANR问题的处理,也是方便快捷的ANR处理手段。

提升用户体验迫在眉睫,但ANR问题对用户体验影响大, 定位解决ANR问题老大难,针对这个需求痛点,越来愈多的第三方开始研究并对外提供应用性能监控工具。

**性能管理(App Performance Management,简称APM)**是华为AppGallery Connect质量系列服务中的其中一项,提供分钟级应用性能监控能力,其ANR分析功能,更是解决ANR问题定位与处理的最佳搭档。使用AGC性能管理服务监控应用ANR,能够为您带来以下好处:

1.实时监控现网应用ANR,现网应用ANR趋势全掌握。

2.ANR现场信息自动采集和展示,大部分情况无需复现,在线定位问题。

3.通过APM页面,定位思路系统化,快速上手ANR问题定位,及时解决问题。

4、ANR问题解决案例整理

接下来以华为AGC性能管理服务为例,介绍配合AGC性能管理服务,如何快速定位典型的ANR问题。

4.1 案例(一):死锁导致的ANR问题定位

4.1.1 发现问题
在华为AGC控制台的我的项目-质量-性能管理页面,在“ANR分析”页签下,发现排在第一位的“用户ANR率”高达16.67%,决定优先解决该类ANR问题。

在这里插入图片描述

4.1.2 定位问题
点开TOP排行榜中该类问题卡片,进入了该类“ANR问题详情”页面,进一步查看分析该ANR 问题的数据报告。
在这里插入图片描述

在这个“ANR问题详情”页面中,分析用户数分布饼图,发现该类ANR问题在“应用版本2.0”、“手机型号HUAWEI VOG-AL10”、“系统版本10”这三个条件下,ANR影响的用户数最多。
在这里插入图片描述
在报告下方的“发生记录”中,找到满足这三个条件的发生记录,点击“查看详情”准备针对具体的问题进行分析。
在这里插入图片描述
(1) 分析系统资源状态
首先,通过报告,发现该问题发生时,CPU占用是20%、IO占用是0%、未发生过低内存、应用被分配堆是26.50MB、应用已用堆是8.69MB,线程数是61,从系统资源来看,未出现明显的异常,如下图所示:
在这里插入图片描述
因为ANR问题原因可以分为两大类,一是系统资源不足导致,二是自身代码逻辑导致,综合以上系统资源信息,该ANR问题不是由于系统资源不足导致,那么分析该ANR问题思路转变为:该ANR问题由自身代码逻辑导致,接下来,我们顺着该思路分析这次的ANR问题。
(2) 查看主线程状态:发现ANR代码片段
自身代码逻辑导致ANR问题,其主要分析思路是查看主线程堆栈及线程状态,我们在性能管理页面上“主线程堆栈”页签中能够找到问题堆栈,发现该问题发生时,主线程处于获取锁状态,到此我们能够得出结论:该ANR问题是因为主线程一直在等待锁资源,而被阻塞,导致了后续输入事件未被响应,从而触发了应用的“Input dispatching timed out”类型的ANR。
在这里插入图片描述
查看具体的堆栈信息,我们找到了ANR问题代码片段,发现死锁是发生在“com.aiops.hiperformance.MainActivity.dispatchActivityDestroyed”调用中。查看代码发现,死锁发生在“mLock.readLock().lock()”函数中。
在这里插入图片描述
通过在代码中搜索mLock加锁代码的调用,发现了仅在MainActivity文件中,才会存在“mLock.readLock.lock()”代码, 由此判断,异常代码仅存在于MainActivity中,因此我们缩小了问题代码范围。 在正在的代码编写过程中,锁的申请与释放已经成为一种编码习惯,如果锁未释放,可能是在释放锁之前,出现了某种我们编码未考虑的异常,导致锁未释放或释放失败。 由此分析,我们接下来尝试使用“找到ANR问题发生之前,应用是否有异常发生”的思路,继续分析。

我们先找到申请锁动作开始时间点,由阻塞动作开始时间点往前分析,寻找异常信息。我们切换到“ANR信息”页签, 发现主执行队列首元素在5.5s前已经存在,ANR发生时间是“2020-09-27 09:48:27”, 因此我们可计算出获取锁动作大概是在“2020-09-27 09:48:21”发生。

在这里插入图片描述
(3) 查看应用日志
接下来,我们把页签切到“系统日志”中,我们目前知道锁获取动作在“2020-09-27 09:48:21”左右发生。我们接下来仅需要在日志中,从该时间点往前分析,看是否由相关异常,是导致该锁未被释放的关键因素。
在这里插入图片描述
我们发现在“09:48:18.365”时系统抛出了“OutofBoundsException”异常,并且打印了异常堆栈,我们发现,该异常就出现在MainActivity,也就是我们之前的问题代码范围中,我们通过该堆栈,找到了异常代码。

在这里插入图片描述
发现在“getShareDataInterceptor”调用时,抛出了“越界异常”,导致了“mLock.readLock”未被释放,由此我们已经知道导致该ANR问题的具体原因:异常场景导致锁资源未被释放,从而造成了主线程出现死锁。

4.1.3 解决问题
为了修复了该问题,我们做了以下措施,解决该问题的同时,预防同类问题发生:

  1. 分析异常具体原因并修改代码,防止越界异常再次出现。

  2. 捕获该异常,保护代码在资源释放前被异常抛出。

  3. 排查其他代码,在资源释放前,加上保护,保证资源及时释放。

4.2 案例(二):IO资源不足导致ANR问题定位

4.2.1 定位问题
直奔问题核心,直接进入“单次ANR问题” 页面,去分析问题,强化我们借助性能管理服务定位ANR问题思路。
在这里插入图片描述
(1)分析系统资源状态.
首先,通过报告,发现该问题发生时,CPU占用是100%、IO占用是84%、未发生过低内存、应用被分配堆是26.50MB、应用已用堆是8.69MB,从系统资源来看,CPU占用和IO占用出现明显异常,如下图所示:

由定位大部分ANR问题经验可知,该ANR问题是由于系统资源不足导致,那么分析该ANR问题思路为:找到自身应用程序ANR代码片段,分析否能够优化代码,在高IO情况下,不触发ANR。

(2)查看主线程状态:发现问题原因
我们切换到“主线程堆栈”页签,观察主线程代码。
在这里插入图片描述

通过观察主线程堆栈,我们发现了一个存在问题的地方,主线程里面直接在做数据库操作,在系统IO高的情况,此操作必定会导致主线程被阻塞。我们通过堆栈找到对应的代码。
在这里插入图片描述

由此我们确认,在代码中存在访问SQLite的操作。这时候有经验的开发者已经知道,问题能够通过优化解决,仅需要将该IO操作放在线程中执行即可。

(3) 查看应用日志
已经在上一环节分析出ANR原因,无需此步骤。

4.2.2 解决问题
我们做了以下措施,优化了该问题代码,预防ANR问题发生。
在这里插入图片描述

4.3 案例(三):主线程死循环导致ANR问题定位
4.3.1 定位问题
话不多说,直接到“单次ANR问题”,固化问题定位思路。
在这里插入图片描述

(1)首先,通过报告,发现该问题发生时,CPU占用是25%、IO占用是0%、未发生过低内存、应用被分配堆是18.01MB、应用已用堆是8.08MB,线程数是43,从系统资源来看,均未出现明显异常,如下图所示:
在这里插入图片描述

由定位大部分ANR问题经验可知,该ANR问题大概率不是由于系统资源不足导致,那么分析该ANR问题思路转变为:该ANR问题由自身代码逻辑导致,接下来,我们顺着该思路分析这次的ANR问题。

(2)查看主线程状态:发现问题原因
自身代码逻辑导致ANR问题,其主要分析思路是查看主线程堆栈及线程状态,我们在性能管理页面上“主线程堆栈”页签中能够找到问题堆栈。
在这里插入图片描述

发现该问题发生时,发现主线程堆栈在getActivity中被阻塞,主线程处于“SUSPENDED”状态。这时我们通过堆栈,找到问题代码。
在这里插入图片描述

通过代码分析,怀疑主线程在该处出现死循环。我们知道如果应用程序出现死循环会导致应用程序的CPU用户态时间占用异常升高,我们知道“ANR信息”页签中记录了ANR发生时的各进程的CPU占用信息,于是我们在页面上切换到“ANR信息”页签。
在这里插入图片描述

我们在“ANR信息”页签中发现,自身应用程序CPU用户态的资源占用达到了94%,因此验证了我们之前的猜想:主线程出现了死循环,导致了ANR问题。

(3)查看应用日志
已经在上一环节分析出ANR原因,无需此步骤。

4.3.2 解决问题
我们做了以下措施,优化了该问题代码,预防ANR问题发生。
在这里插入图片描述

5、案例总结

以上ANR问题的解决与处理,都是配合华为AppGallery Connect性能管理管理服务完成的,其中的ANR问题分析报告,ANR问题发生时的问题记录,都由AGC性能管理服务界面所提供。

通过AGC性能服务里的 ANR分析详情 可以查看发生某类ANR问题时的趋势及分布信息,其中包括按应用版本版本分布,按手机型号分布,按系统版本分布和问题发生的实时走势。帮助分析这一类ANR问题对用户的影响趋势,以及问题复现条件。

另外开发者可以通过详细的问题发生记录,获取到该问题发生时更加详细的设备信息,系统信息,应用信息和堆栈日志,帮助开发者快速定位该问题。

6、相关链接

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消