ANR

Bugly专业版支持全面的ANR分析能力，支持Android与iOS ANR异常的搜集与上报，帮助用户更好地优化应用质量。本文主要介绍Bugly专业版的ANR分析能力及功能详情。

ANR 概览

概览详情可参考 崩溃概览。

个例筛选

个例筛选可参考崩溃 个例筛选。

下钻分析

下钻分析可参考崩溃 下钻分析。

出错堆栈

出错堆栈可参考崩溃 出错堆栈。

现场数据

现场数据可参考崩溃 现场数据。

日志

日志可参考崩溃 日志。

FD信息

FD信息可参考崩溃 FD信息。

进程信息

进程信息可参考崩溃 进程信息。

调度时序图

调度时序图以时序图的方式，展示ANR发生时的消息调度情况。点击消息旁的箭头可以展开ANR发生前后的消息调度详情。

其中，长耗时消息以黄色的卡片展示，鼠标hover至消息卡片上，将展示对应消息的Wall Time、CPU Time、Message Handle和Callback等信息。Wall Time表示处理当前消息或某几个消息累加耗时的真实耗时，Wall Time超过 200ms且Type为单条的，可以认定为长耗时消息。CPU Time表示处理当前消息或某几个消息累加运行在CPU上的耗时。

在分析ANR问题时，可以点击模块右上角 仅显示长耗时消息 来过滤筛选出长耗时消息。如果想查看长耗时消息中的详细堆栈，可以点击指定长耗时消息卡片中的 Anr之前60秒卡顿堆栈追踪 ，跳转至卡顿页面查询该设备的卡顿个例上报，结合卡顿个例中的堆栈来综合分析导致ANR的原因。

ANR_INFO

ANR_INFO信息是应用程序在ANR发生时生成的一项系统报告，记录了ANR发生时所在的Activity组件，发生ANR的进程ID，以及发生ANR的原因。

其中，Load表示ANR发生时系统在1分钟、5分钟和15分钟的平均负载情况，平均负载的单位是进程数，代表在ANR发生时系统中正在运行或等待CPU资源的进程数的平均值。CPU Usage代表在ANR发生的时间范围内CPU的详细占用情况，根据这些信息可以辅助进行ANR问题的分析。

ANR Trace

ANR Trace是一个包含应用程序在ANR期间发生的事件和线程堆栈跟踪的日志文件，主要由两部份组成，如下图所示。

第一部份是ANR时间和GC信息，可以了解当前ANR问题发生了多长时间，系统进行了哪些GC操作。第二部份是线程堆栈信息，列出了所有在ANR期间运行线程的堆栈跟踪信息。除每个线程除堆栈信息外，还包含线程ID（tid）、线程优先级（prio）、线程状态（state）、线程调度统计信息（schedstat）、线程使用的CPU时间（utm和stm）等线程的状态信息。结合上述信息，尤其是线程的堆栈跟踪信息，可以快速帮助定位分析造成ANR问题的原因。

FAQ

1.为什么本地ANR没有上报？如何进行排查？

可参考 崩溃上报排查流程。

2.为什么有的信息（如ANR_INFO、ANR Trace）没有数据展示？

ANR相关信息： 部份ANR信息，如ANR Trace、ANR_INFO信息获取不到，可能和厂商定制化的ANR处理逻辑有关，部份机型在系统发出ANR信号后，会直接杀死进程，因此来不及获取对应ANR信息。

其他信息： 与崩溃捕获处理链有关，可能是系统逻辑中断了处理导致信息未采集完成。详情可咨询Bugly小助手。

3. 为什么相同的ANR问题没有被聚在同一个Issue里？

可参考 为什么相同的崩溃问题没有被聚在同一个Issue里？。

4.ANR发生的条件是什么？

在Android中，系统会在以下情况判定ANR（应用程序无响应）事件发生：

• 当应用程序在主线程上执行耗时操作时，例如网络请求或长时间的计算，而没有及时响应用户输入事件（例如点击屏幕或按键）时，系统会认为应用程序无响应。
• 当应用程序在5秒钟内没有响应用户输入事件时，系统会认为应用程序无响应。
• 当应用程序在BroadcastReceiver或Service组件中执行耗时操作时，而没有及时完成操作并释放锁时，系统会认为应用程序无响应。

5.对于ANR应如何优化？有什么优化建议？

• 避免主线程中进行耗时操作。
• 使用异步任务来处理耗时操作。
• 使用多线程处理耗时操作。
• 使用Handler处理消息。