ANR与卡顿关联

解决ANR问题的一个痛点是，出错堆栈并非第一现场时，不知从何着手。卡顿监控一般采样开启，发生ANR的设备，可能只有少部分同时开启了卡顿监控。从大量的ANR上报中，找出少量的同时开启了卡顿监控的个例，并非易事。 针对大家日常分析中遇到的这些问题，Bugly近期进行了优化。本期的一分钟教程主要介绍ANR与卡顿的关联优化。

痛点一：怎么确定当前ANR是否是第一现场？

1. Bugly在ANR上报前，会采集ANR发生前一段时间的UI线程调试信息。结合这些信息，我们可以清晰看到，当前ANR的消息耗时情况，以及ANR前UI线程的消息执行情况。

2. 在本示例中，ANR的消息执行耗时超过7s，本身就是一个主要原因。在ANR前，也发生过好几例卡顿，UI线程消息执行耗时超过200ms。

3. 以下案例中，ANR的消息耗时77ms，但是之前有一个长卡顿，耗时1.8秒。用户从启动到ANR，总共才经历2秒，但是这个长卡顿直接耗时1.8秒，显示前面的长卡顿才有可能是导致ANR的主要原因。

痛点二：怎么过滤出包含UI线程消息调度时序图的个例？

1. 在个例详情的筛选条件中，通过「异常现场」选项，过滤出包含「调度时序图」的个例。

2. 同时选择多个现场条件，如「调度时序图」和「ANR Trace」，表示过滤出包含「调度时序图」或者「ANR Trace」的个例。多个选项之间是或关系。

痛点三：怎么从大量的ANR个例中找出能够成功关联卡顿的那些个例？

1. 在异常现场包含「调度时序图」的基础上，再结合「联动标记」，找到能够成功跟卡顿关联的ANR个例。

2. 这些成功关联了卡顿的个例，在长耗时消息上，往往可以看到，「查看卡顿个例」的可点击链接，点击后，直接进入该条消息对应的卡顿个例上。

3. 长耗时消息是否展示「查看卡顿个例」，跟卡顿的「消息采样率」有关。如果卡顿的消息采样率比较低，成功关联的个例会比较少。相反，如果卡顿的消息采样率比较高，成功关联的个例会比较多。建议在灰度阶段，可以提升卡顿监控的消息采样率(event_sample_ratio)。

备注：

1. Android Bugly SDK 4.3.0 版本开始支持采集UI线程的调度时序图。
2. Android Bugly SDK 4.4.0 版本开始支持ANR与卡顿的联动。4.4.0 版本当前还在灰度阶段，欢迎有意向的产品找「Bugly小助手」一起灰度验证。
3. ANR之后的节点的When字段标识的是该消息期望的执行时间，例如 -7526 表示该消息本期望在7秒之前执行的，但由于main线程卡顿延迟了.