Android开发：不会ANR？这里有ANR全解析和各种案例包教包会

最新推荐文章于 2024-07-03 12:30:22 发布

程序员一东

最新推荐文章于 2024-07-03 12:30:22 发布

阅读量1.6k

点赞数 1

文章标签： android

本文链接：https://blog.csdn.net/Eqiqi/article/details/121901207

版权

前言

相比于发生应用程序崩溃，发生ANR更加让人头大，主要原因是崩溃发生的时候会在Logcat中打印出发生异常的位置，开发人员很容易就能定位到崩溃并解决，显然ANR没那么轻松；但是我们大可不必这么忧伤，因为有问题就会有解决办法，解决不了，只是因为没有用对方法

总体思路

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

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

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

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

导出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

其中：

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的占用情况。

具体分析

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

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

ANR问题难点及破题思路

ANR难点

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

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

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

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

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

ANR处理新方案

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

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

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

1.实时监控现网应用ANR，现网应用ANR趋势全掌握。
2.ANR现场信息自动采集和展示，大部分情况无需复现，在线定位问题。
3.通过APM页面，定位思路系统化，快速上手ANR问题定位，及时解决问题。

ANR问题解决案例整理

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

案例（一）：死锁导致的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问题的具体原因：异常场景导致锁资源未被释放，从而造成了主线程出现死锁。

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

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

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

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

文末

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。

进阶学习视频

附上：收集的二十套一二线互联网公司Android面试真题?（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

文章篇幅有限，需要完整版资料的朋友可以微信扫描下方二维码免费获取！
在这里插入图片描述