如何解读MetricKit的histogrammedApplicationResumeTime指标

苹果官方文档对histogrammedApplicationResumeTime的公开描述仅为：

应用从后台恢复的不同耗时分布直方图。

该描述存在明显简化，实际统计逻辑和多数开发者的直觉认知存在偏差：

• 计时起点为应用进程收到 UIApplicationWillEnterForegroundNotification 系统通知的时刻，即系统判定应用即将从后台切换至前台的时间点，用户点击应用图标/卡片唤起应用到系统触发该通知之间的系统调度耗时，不会被计入该指标。
• 计时终点为应用完成全部前台激活生命周期回调、首帧UI渲染提交完成、主线程RunLoop首次进入空闲状态的时刻。
• 核心统计逻辑：该指标统计的是起点到终点之间，应用进程处于非挂起可运行状态的时间累加值，而非两点之间的连续墙钟时间差，也不等同于用户实际感知到的应用恢复响应时长。

观测到的超长耗时全部来自符合系统统计规则、但不属于用户可感知恢复流程的场景，核心诱因有三类：

• 未正确收尾的后台任务
  这是小时级异常值的最主要来源。如果应用进入后台时调用 beginBackgroundTask: 申请了后台执行权限，但因代码逻辑漏洞（异常分支漏写 endBackgroundTask:、后台任务阻塞主线程等）未在系统规定的后台时限内结束任务，后续应用被用户唤起回到前台时，MetricKit会将该后台任务从申请到最终结束的全部可运行时间，累加到恢复耗时统计中。
• 恢复流程被中途打断
  如果应用触发前台恢复流程后，在生命周期回调（如applicationDidBecomeActive:、首屏控制器viewDidAppear:）执行完成前，用户触发了打断操作（按锁屏键、切至其他应用、接听来电等），系统会临时挂起应用。待用户后续再次切回应用完成激活时，从第一次触发恢复到最终完成激活的全周期内，所有进程可运行时间都会被累加统计，很容易产生数十分钟到数小时的异常值。
• 特殊系统状态干扰
  若用户设备连接调试工具、恢复过程中触发系统权限弹窗（定位、通知、相册权限等）后用户很久才完成操作，这段等待期内应用处于可运行状态的时间也会被计入统计。

• 不要直接使用该指标的全量分位值评估用户体验，建议先过滤掉10s以上的异常值，这部分数据基本不对应真实用户感知的恢复卡顿。
• 如需统计准确的用户可感知热启动耗时，建议自行在应用内埋点：以应用启动/唤起的最早时间戳为起点，首屏可交互为终点做统计，与MetricKit数据交叉校验。

内容的提问来源于stack exchange，提问作者Andrey Morozov