iOS 稳定性问题治理：卡死崩溃监控原理及最佳实践(1)，如果不想35岁被淘汰这篇文章必看

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 崩溃监控的准确性。关于 OOM 崩溃的具体监控原理和优化思路可以参考：iOS 性能优化实践：头条抖音如何实现 OOM 崩溃率下降 50%+

因此，基于以上信息我们可以得出结论：卡死崩溃的监控和治理是非常有必要的。经过近 2 年的监控和治理，目前今日头条 App 卡死崩溃每天发生的量级大致和普通崩溃持平。

卡死崩溃监控原理

========

卡顿监控原理

---

其实从用户体验出发的话，卡死的定义就是长时间卡住并且最终也没有恢复的那部分卡顿，那么下面我们就先回顾一下卡顿监控的原理。我们知道在 iOS 系统中，主线程绝大部分计算或者绘制任务都是以 runloop 为单位周期性被执行的。单次 runloop 循环如果时长超过 16ms，就会导致 UI 体验的卡顿。那如何检测单次 runloop 的耗时呢？

通过上图可以看到，如果我们注册一个 runloop 生命周期事件的观察者，那么在 afterWaiting=>beforeTimers，beforeTimers=>beforeSources 以及 beforeSources=>beforeWaiting 这三个阶段都有可能发生耗时操作。所以对于卡顿问题的监控原理大概分为下面几步：

1. 注册 runloop 生命周期事件的观察者。

2. 在 runloop 生命周期回调之间检测耗时，一旦检测到除休眠阶段之外的其他任意一个阶段耗时超过我们预先设定的卡顿阈值，则触发卡顿判定并且记录当时的调用栈。

3. 在合适的时机上报到后端平台分析。

整体流程如下图所示：

如何判定一次卡顿为一次卡死

---

其实通过上面的一些总结我们不难发现，长时间的卡顿最终无论是触发了系统的卡死崩溃，还是用户忍受不了主动结束进程或者退后台，他们的共同特征就是发生了长期时间卡顿且最终没有恢复，阻断了用户的正常使用流程。

基于这个理论的指导，我们就可以通过下面这个流程来判定某次卡顿到底是不是卡死：

1. 某次长时间的卡顿被检测到之后，记录当时所有线程的调用栈，存到数据库中作为卡死崩溃的怀疑对象。

2. 假如在当前 runloop 的循环中进入到了下一个活跃状态，那么该卡顿不是一次卡死，就从数据库中删除该条日志。本次使用周期内，下次长时间的卡顿触发时再重新写入一条日志作为怀疑对象，依此类推。

3. 在下次启动时检测上一次启动有没有卡死的日志（用户一次使用周期最多只会发生一次卡死），如果有，说明用户上一次使用期间最终遇到了一次长时间的卡顿，且最终 runloop 也没能进入下一个活跃状态，则标记为一次卡死崩溃上报。

通过这套流程分析下来，我们不仅可以检测到系统的卡死崩溃，也可以检测到用户忍受不了长时间卡顿最终杀掉应用或者退后台之后被系统杀死等行为，这些场景虽然并没有实际触发系统的卡死崩溃，但是严重程度其实是等同的。也就是说本文提到的卡死崩溃监控能力是系统卡死崩溃的超集。

卡死时间的阈值如何确定

---

系统的卡死崩溃日志格式截取部分如下：

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFYTermination

Reason: Namespace ASSERTIOND, Code 0x8badf00d

Triggered by Thread:  0

Termination Description: SPRINGBOARD, scene-create watchdog transgression: application<com.ss.iphone.article.News>:2135 exhausted real (wall clock) time allowance of 19.83 seconds

可以看到 iOS 系统的保护机制只有在 App 卡死时间超过一个异常阈值之后才会触发，那么这个卡死时间的阈值就是一个非常关键的参数。

遗憾的是，目前没有官方的文档或者 api，可以直接拿到系统判定卡死崩溃的阈值。这里 exhausted real (wall clock) time allowance of 19.83 seconds 其中的 19.83 并不是一个固定的数字，在不同的使用阶段，不同系统版本的实现里都可能有差异，在一些系统的崩溃日志中也遇到过 10s 的 case。

基于以上信息，为了覆盖到大部分用户可以感知到的场景，屏蔽不同系统版本实现的差异，我们认为系统触发卡死崩溃的时间阈值为 10s，实际上有相当一部分用户在遇到 App 长时间卡顿的时候会习惯性的手动结束进程重启而不是一直等待，因此这个阈值不宜过长。为了给触发卡死判定之后的抓栈，日志写入等操作预留足够的时间，所以最终本方案的卡死时间阈值确定为 8s。发生 8s 卡死的概率比发生几百 ms 卡顿的概率要低的多，因此该卡死监控方案并没有太大的性能损耗，也就可以在生产环境中对全量用户开放。

如何检测到用户一次卡死的时间

---

在卡死发生之后，实际上我们也会关注一次卡死最终到底卡住了多久，卡死时间越长，对用户使用体验的伤害也就越大，更应该被高优解决。

在触发卡死阈值之后我们可以再以一个时间间隔比较短的定时器（目前策略默认 1s，线上可调整），每隔 1s 就检测当前 runloop 有没有进入到下一个活跃状态，如果没有，则当前的卡死时间就累加 1s，用这种方式即使最终发生了闪退也可以逼近实际的卡死时间，误差不超过 1s，最终的卡死时间也会写入到日志中一起上报。

但是这种方案在上线后遇到了一些卡死时长特别长的 case，这种问题多发生在 App 切后台的场景。因为在后台情况下，App 的进程会被挂起(suspend)后，就可能被判定为持续很久的卡死状态。而我们在计算卡死时间的时候，采用的是现实世界的时间差，也就是说当前 App 在后台被挂起 10s 后又恢复时，我们会认为 App 卡死了 10s，轻易的超过了我们设定的卡死阈值，但其实 App 并没有真正卡死，而是操作系统的调度行为。这种误报常常是不符合我们的预期的。误报的场景如下图所示：

如何解决主线程调用栈可能有误报的问题

---

为了解决上面的问题，我们采用多段等待的方式来降低线程调度、挂起导致的程序运行时间与现实时间不匹配的问题，以下图为例。在 8s 的卡死阈值前，采用间隔等待的方式，每隔 1s 进行一次等待。等待超时后对当前卡死的时间进行累加 1s。如果在此过程中，App 被挂起，无论被挂起多久，再恢复时最多会造成 1s 的误差，这与之前的方案相比极大的增加了稳定性和准确性。

另外，待卡死时间超过了设定的卡死阈值后，会对全线程进行抓栈。但是仅凭这一时刻的线程调用栈并不保证能够准确定位问题。因为此时主线程执行的可能是一个非耗时任务，真正耗时的任务已经结束；或者在后续会发生一个更加耗时的任务，这个任务才是造成卡死的关键。因此，为了增加卡死调用栈的置信度，在超过卡死阈值后，每隔 1s 进行一次间隔等待的同时，对当前主线程的堆栈进行抓取。为了避免卡死时间过长造成的线程调用栈数量膨胀，最多会保留距离 App 异常退出前的最近 10 次主线程调用栈。经过多次间隔等待，我们可以获取在 App 异常退出前主线程随着时间变化的一组函数调用栈。通过这组函数调用栈，我们可以定位到主线程真正卡死的原因，并结合卡死时间超过阈值时获取的全线程调用栈进一步定位卡死原因。

最终的监控效果如下：

因为图片大小的限制，这里仅仅截了卡死崩溃之前最后一次的主线程调用栈，实际使用的时候可以查看崩溃之前一段时间内每一秒的调用栈，如果发现每一次主线程的调用栈都没有变化，那就能确认这个卡死问题不是误报，例如这里就是一次异常的跨进程通信导致的卡死。

卡死崩溃常见问题归类及最佳实践

===============

多线程死锁

---

问题描述

比较常见的就是在 dispatch_once 中子线程同步访问主线程，最终造成死锁的问题。如上图所示，这个死锁的复现步骤是：

1. 子线程先进入 dispatch_once 的 block 中并加锁。

2. 然后主线程再进入 dispatch_once 并等待子线程解锁。

3. 子线程初始化时触发了 CTTelephonyNetworkInfo 对象初始化抛出了一个通知却要求主线程同步响应，这就造成了主线程和子线程因为互相等待而死锁，最终触发了卡死崩溃。

这里的其实是踩到了 CTTelephonyNetworkInfo 一个潜在的坑。如果这里替换成一段 dispatch_sync 到 dispatch_get_main_queue()的代码，效果还是等同的，同样有卡死崩溃的风险。

最佳实践

1. dispatch_once 中不要有同步到主线程执行的方法。

2. CTTelephonyNetworkInfo 最好在 +load方法或者 main 方法之前的其他时机提前初始化一个共享的实例，避免踩到子线程懒加载时候要求主线程同步响应的坑。

主线程执行代码与子线程耗时操作存在锁竞争

---

问题描述

一个比较典型的问题是卡死在-[YYDiskCache containsObjectForKey:]，YYDiskCache 内部针对磁盘多线程读写操作，通过一个信号量锁保证互斥。通过分析卡死堆栈可以发现是子线程占用锁资源进行耗时的写操作或清理操作引发主线程卡死，问题发生时一般可以发现如下的子线程调用栈：

最佳实践

1. 有可能存在锁竞争的代码尽量不在主线程同步执行。

2. 如果主线程与子线程不可避免的存在竞争时，加锁的粒度要尽量小，操作要尽量轻。

磁盘 IO 过于密集

---

问题描述

此类问题，表现形式可能多种多样，但是归根结底都是因为磁盘 IO 过于密集最终导致主线程磁盘 IO 耗时过长。典型 case:

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

写在最后

由于本文罗列的知识点是根据我自身总结出来的，并且由于本人水平有限，无法全部提及，欢迎大神们能补充~

将来我会对上面的知识点一个一个深入学习，也希望有童鞋跟我一起学习，一起进阶。

提升架构认知不是一蹴而就的，它离不开刻意学习和思考。

**这里，笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家，**梳理了多年的架构经验，筹备近1个月最新录制的，相信这份视频能给你带来不一样的启发、收获。

最近还在整理并复习一些Android基础知识点，有问题希望大家够指出，谢谢。

希望读到这的您能转发分享和关注一下我，以后还会更新技术干货，谢谢您的支持！

转发+点赞+关注，第一时间获取最新知识点

Android架构师之路很漫长，一起共勉吧！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

提升架构认知不是一蹴而就的，它离不开刻意学习和思考。

**这里，笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家，**梳理了多年的架构经验，筹备近1个月最新录制的，相信这份视频能给你带来不一样的启发、收获。

[外链图片转存中…(img-4Wd6ox47-1712543453596)]

[外链图片转存中…(img-wry1ngUO-1712543453596)]

最近还在整理并复习一些Android基础知识点，有问题希望大家够指出，谢谢。

希望读到这的您能转发分享和关注一下我，以后还会更新技术干货，谢谢您的支持！

转发+点赞+关注，第一时间获取最新知识点

Android架构师之路很漫长，一起共勉吧！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！