相比于发生应用程序崩溃,发生ANR更加让人头大,主要原因是崩溃发生的时候会在Logcat中打印出发生异常的位置,开发人员很容易就能定位到崩溃并解决,显然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>
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
其中:
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
其中
分析CPU usage以后,如若还是无法找出问题原因,则需要进一步分析trace文件。traces文件中详细记录了发生ANR前后该进程的各个线程的Stack,一般从主线程的stack入手分析,查看分析ANR问题发生前,应用是否有异常。
其中不同场景下的ANR问题情况不大相同,需要具体情况具体分析,此处就不展开详细描述。
但是,现网中的ANR问题又很难处理,问题包括但不限于:
提升用户体验迫在眉睫,但ANR问题对用户体验影响大, 定位解决ANR问题老大难,针对这个需求痛点,越来愈多的第三方开始研究并对外提供应用性能监控工具。
性能管理(App Performance Management,简称APM)是华为AppGallery Connect质量系列服务中的其中一项,提供分钟级应用性能监控能力,其ANR分析功能,更是解决ANR问题定位与处理的最佳搭档。使用AGC性能管理服务监控应用ANR,能够为您带来以下好处:
1.实时监控现网应用ANR,现网应用ANR趋势全掌握。
2.ANR现场信息自动采集和展示,大部分情况无需复现,在线定位问题。
3.通过APM页面,定位思路系统化,快速上手ANR问题定位,及时解决问题。
发现问题
在华为AGC控制台的我的项目-质量-性能管理页面,在“ANR分析”页签下,发现排在第一位的“用户ANR率”高达16.67%,决定优先解决该类ANR问题。
定位问题
点开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问题的具体原因:异常场景导致锁资源未被释放,从而造成了主线程出现死锁。
解决问题
为了修复了该问题,我们做了以下措施,解决该问题的同时,预防同类问题发生:
对于很多初中级Android工程师而言,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路,本文的重点是你有没有收获与成长,其余的都不重要,希望读者们能谨记这一点。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。