如何有效分析Android应用中的ANR日志以优化性能？

分析ANR日志

一、

解决Android应用无响应（ANR）问题是开发者必须掌握的重要技能，ANR问题一般从开发阶段、线上监控阶段和分析阶段三个方面进行解决，在开发阶段，通过工具检查方法耗时和卡顿情况；在线上监控阶段，依靠监控工具发现并上报ANR；在分析阶段，通过分析ANR日志定位问题，本文将详细解析如何分析ANR日志，帮助开发者快速找到和解决ANR问题。

二、ANR产生机制

输入事件超时（5秒）

InputDispatcher发送key事件给对应的进程的Focused Window，如果对应window不存在、处于暂停态或通道占满等，就会发生ANR。

MotionEvent事件有例外之处：当Touched Window的input waitQueue中有超过0.5秒的事件，InputDispatcher会暂停该事件，并等待5秒，若仍未收到finish事件，则触发ANR。

2. 广播类型超时（前台15秒，后台60秒）

静态注册的广播和有序广播会导致ANR，动态注册的非有序广播不会。

广播发送时判断进程是否存在，不存在则创建，创建进程的时间算在超时时间内，只有前台显示Activity才会弹出ANR对话框，否则直接杀掉当前进程。

3. 服务超时（前台20秒，后台200秒）

Service的方法如onCreate(), onStartCommand(), onStart(), onBind(), onRebind(), onTaskRemoved(), onUnbind(), onDestroy()等触发ANR。

前台Service超时时间为20秒，后台Service为200秒，用户态下执行的Service为前台执行。

ContentProvider类型

ContentProvider创建发布超时不会导致ANR，但使用ContentProviderclient访问ContentProvider可自主选择触发ANR，超时时间自己设定。

三、导致ANR的原因

应用层导致ANR（耗时操作）

函数阻塞：如死循环、主线程IO、处理大数据。

锁出错：主线程等待子线程的锁。

内存紧张：系统分配给应用的内存有限，长期内存紧张导致频繁交换，进而导致操作超时。

系统导致ANR

CPU被抢占：前台玩游戏可能导致后台广播被抢占CPU。

系统服务无法及时响应：如获取系统联系人等，系统服务能力有限，可能长时间不响应导致ANR。

其他应用占用大量内存。

四、分析ANR日志

发生ANR时，系统会产生一份anr日志文件（通常位于手机的/data/anr目录），包含以下重要信息：

CPU负载

Load: 2.62 / 2.55 / 2.25
CPU usage from 0ms to 1987ms later (2020-03-10 08:31:55.169 to 2020-03-10 08:32:17.156):
41% 2080/system_server: 28% user + 12% kernel / faults: 76445 minor 180 major
26% 9378/com.xiaomi.store: 20% user + 6.8% kernel / faults: 68408 minor 68 major
...省略N行...
66% TOTAL: 20% user + 15% kernel + 28% iowait + 0.7% irq + 0.7% softirq

第一行：1、5、15分钟内正在使用和等待使用CPU的活动进程的平均数。

第二行：表明负载信息抓取在ANR发生之后的0~1987ms，同时也指明了ANR的时间点：2020-03-10 08:31:55.169。

中间部分：各个进程占用的CPU的详细情况。

最后一行：各个进程合计占用的CPU信息。

名词解释：

user：用户态。

kernel：内核态。

faults：内存缺页，minor——轻微的，major——重度，需要从磁盘拿数据。

iowait：IO使用（等待）占比。

irq：硬中断。

softirq：软中断。

内存信息

Total number of allocations 476778　　进程创建到现在一共创建了多少对象
Total bytes allocated 52MB　进程创建到现在一共申请了多少内存
Total bytes freed 52MB　　　进程创建到现在一共释放了多少内存
Faults: major=2 minor=1 (details omitted)

Total number of allocations：进程创建到现在一共创建了多少对象。

Total bytes allocated：进程创建到现在一共申请了多少内存。

Total bytes freed：进程创建到现在一共释放了多少内存。

Faults：内存缺页，minor——轻微的，major——重度，需要从磁盘拿数据。

五、经典案例分析

1. KeyDispatchTimeout案例

现象：用户点击按钮后应用无响应。

日志分析：发现InputDispatcher发送key事件后，窗口没有响应，最终触发ANR。

解决方法：优化UI线程的处理逻辑，避免在主线程中进行耗时操作。

ServiceTimeout案例

现象：后台服务长时间未响应。

日志分析：发现后台服务在处理复杂任务时超时。

解决方法：将复杂任务放到IntentService中异步处理，或者优化任务的执行效率。

六、相关问题与解答

Q1: 什么是ANR？它有哪些常见类型？

A1: ANR（Application Not Responding）是指应用程序无响应的状态，常见类型包括KeyDispatchTimeout、BroadcastTimeout、ServiceTimeout和ContentProviderTimeout。

Q2: 如何快速定位ANR日志中的问题？

A2: 通过查看anr trace文件中的CPU负载和内存信息，可以初步判断是系统资源紧张还是应用自身问题导致的ANR，进一步分析具体的线程堆栈信息，可以精确定位到问题代码。

七、归纳

ANR问题的分析和解决需要对系统和应用的运行机制有深入的理解，通过本文介绍的ANR产生机制、原因分析及日志解读方法，希望能帮助开发者更好地应对和解决ANR问题，在实际开发中，预防和监控同样重要，建议在开发阶段就做好性能优化和异常监控，以减少线上ANR的发生。

小伙伴们，上文介绍了“分析anr日志”的内容，你了解清楚吗？希望对你有所帮助，任何问题可以给我留言，让我们下期再见吧。