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

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 启动阶段，用户在开屏页面卡住 20s 后什么都做不了紧接着 App 就闪退了。这种体验对用户的伤害比普通的崩溃更加严重。

2. 在卡死监控上线之初，今日头条 App 每天卡死崩溃发生的量级大概是普通崩溃的 3 倍，可见如果不做任何治理的话，这类问题的发生量级是非常大的。

3. OOM 崩溃也是由 SIGKILL 异常信号最终触发的，目前 OOM 崩溃主流的监控原理还是排除法。不过传统方案在做排除法的时候漏掉了一类量级非常大的其他类型的崩溃就是这里的卡死崩溃。如果能准确的监控到卡死崩溃，也同样能大大提高 OOM 崩溃