iOS 稳定性问题治理：卡死崩溃监控原理及最佳实践

不同于 Android 系统中的卡死（ANR）问题，目前业界对 iOS 系统中 App 发生的卡死崩溃问题并无成熟的解决方案，主要原因是：

1. 通常 App 卡死时间超过 20s 之后会触发操作系统的保护机制，发生崩溃，此时在用户的设备中能找到操作系统生成的卡死崩溃日志，但是因为 iOS 系统封闭生态的关系，App 层面没有权限拿到卡死崩溃的日志。

2. 一般而言用户遇到卡死问题的时候并没有耐心等待那么久的时间，可能在卡住 5s 时就已经失去耐心，直接手动关闭应用或者直接将应用退到后台，因此这两种场景下系统也就不会生成卡死崩溃日志。

由于上面提到的两个原因，目前业界 iOS 生产环境中的卡死监控方案其实主要是基于卡顿监控，即当用户在使用 App 的过程中页面响应时间超过一定的卡顿的阈值（一般是几百 ms）之后判定为一次卡顿，然后抓取到当时现场的调用栈并且上报到后台分析。这种方案的缺陷主要体现在：

1. 没有将比较轻微的卡顿问题和严重的卡死问题区分开，导致上报的问题数量太多，很难聚焦到重点。实际上这部分问题对用户体验的伤害其实是远远大于卡顿的。

2. 因为一些使用低端机型的用户更容易在短时间内遇到频繁的卡顿，但是调用栈抓取，日志写入和上报等监控手段都是性能有损的，这也是卡顿监控方案在生产环境中一般只能小流量而不能全量的原因。

3. 试想一次卡顿持续了 100ms，前 99ms 都卡在 A 方法的执行上，但是最后 1ms 刚好切换到了 B 方法在执行，这时候卡顿监控抓到的调用栈是 B 方法的调用栈，其实 B 方法并不是造成卡顿的主要原因，这样也就造成了误导。

基于上述的痛点，字节跳动 APM 中台团队自研了一套专门用于定位生产环境中的卡死崩溃的解决方案，本文将详细的介绍该方案的思路和具体实现，以及通过本方案上线后总结出来的一些典型问题和最佳实践，期望对大家有所启发。

卡死崩溃背景介绍

什么是 watchdog

如果某一天我们的 App 在启动时卡住大概 20s 然后崩溃之后，从设备中导出的系统崩溃日志很可能是下面这种格式：

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace ASSERTIOND, Code 0x8badf00d
Triggered by Thread:  0

下面就其中最重要的前 4 行信息逐一解释：

1. Exception Type

EXC_CRASH：Mach 层的异常类型，表示进程异常退出。

SIGKILL：BSD 层的信号，表示进程被系统终止，而且这个信号不能被阻塞、处理和忽略。这时可以查看 Termination Reason 字段了解终止的原因。

1. Exception Codes

这个字段一般用不上，当崩溃报告包含一个未命名的异常类型时，这个异常类型将用这个字段表示，形式是十六进制数字。

1. Exception Note

EXC_CORPSE_NOTIFY 和 EXC_CRASH 定义在同一个文件中，意思是进程异常进入 CORPSE 状态。

1. Termination Reason

这里主要关注 Code 0x8badf00d，可以在苹果的官方文档中查看到 0x8badf00d 意味着 App ate bad food，表示进程因为 watchdog 超时而被操作系统结束进程。通过上述已经信息可以得出 watchdog 崩溃的定义：

在iOS平台上，App如果在启动、退出或者响应系统事件时因为耗时过长触发系统保护机制，最终导致进程被强制结束的这种异常定义为watchdog类型的崩溃。

所谓的 watchdog 崩溃也就是本文所说的卡死崩溃。

为什么要监控卡死崩溃

大家都知道在客户端研发中，因为会阻断用户的正常使用，闪退已经是最严重的 bug，会直接影响留存，收入等各项最核心的业务指标。之前大家重点关注的都是诸如 unrecognized selector、EXC_BAD_ACCESS 等可以在 App 进程内被捕获的崩溃（下文中称之为普通崩溃），但是对于 SIGKILL 这类因为进程外的指令强制退出导致的异常，原有的监控原理是覆盖不到的，也导致此类崩溃在生产环境中被长期忽视。除此之外，还有如下理由：

1. 因为卡死崩溃最常见发生于 App 启动阶