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

2401_84123005

于 2024-04-09 17:51:12 发布

阅读量646

点赞数 7

分类专栏：程序员文章标签： ios cocoa macos

本文链接：https://blog.csdn.net/2401_84123005/article/details/137561603

版权

程序员专栏收录该内容

185 篇文章 0 订阅

订阅专栏

本文介绍了在iOS应用中如何通过runloop检测卡顿，定义卡死判定规则，确定卡死时间阈值，处理多线程死锁问题，以及最佳实践，旨在提升应用的稳定性和用户体验。文章重点讲解了监控方案、常见问题及其解决方案，包括Objective-CRuntimeLock死锁的处理和应用性能监控平台的使用。

摘要由CSDN通过智能技术生成

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

整体流程如下图所示：

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

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

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

某次长时间的卡顿被检测到之后，记录当时所有线程的调用栈，存到数据库中作为卡死崩溃的怀疑对象。
假如在当前 runloop 的循环中进入到了下一个活跃状态，那么该卡顿不是一次卡死，就从数据库中删除该条日志。本次使用周期内，下次长时间的卡顿触发时再重新写入一条日志作为怀疑对象，依此类推。
在下次启动时检测上一次启动有没有卡死的日志（用户一次使用周期最多只会发生一次卡死），如果有，说明用户上一次使用期间最终遇到了一次长时间的卡顿，且最终 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 中子线程同步访问主线程，最终造成死锁的问题。如上图所示，这个死锁的复现步骤是：

子线程先进入 dispatch_once 的 block 中并加锁。
然后主线程再进入 dispatch_once 并等待子线程解锁。
子线程初始化时触发了 CTTelephonyNetworkInfo 对象初始化抛出了一个通知却要求主线程同步响应，这就造成了主线程和子线程因为互相等待而死锁，最终触发了卡死崩溃。

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

最佳实践

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

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

问题描述

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

最佳实践

有可能存在锁竞争的代码尽量不在主线程同步执行。
如果主线程与子线程不可避免的存在竞争时，加锁的粒度要尽量小，操作要尽量轻。

磁盘 IO 过于密集

问题描述

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

主线程压缩/解压缩。
主线程同步写入数据库，或者与子线程可能的耗时操作（例如 sqlite 的 vaccum 或者 checkpoint 等）复用同一个串行队列同步写入。
主线程磁盘 IO 比较轻量，但是子线程 IO 过于密集，常发生于一些低端设备。

最佳实践

数据库读写，文件压缩/解压缩等磁盘 IO 行为不放在主线程执行。
如果存在主线程将任务同步到串行队列中执行的场景，确保这些任务不与子线程可能存在的耗时操作复用同一个串行队列。
对于一些启动阶段非必要同步加载并且有比较密集磁盘 IO 行为的 SDK，如各种支付分享等第三方 SDK 都可以延迟，错开加载。

系统 api 底层实现存在跨进程通信

问题描述

因为跨进程通信需要与其他进程同步，一旦其他进程发生异常或者挂起，很有可能造成当前 App 卡死。典型 case：

UIPasteBoard，特别是 OpenUDID。因为 OpenUDID 这个库为了跨 App 可以访问到相同的 UDID，通过创建剪切板和读取剪切板的方式来实现的跨 App 通信，外部每次调用 OpenUDID 来获取一次 UDID，OpenUDID 内部都会循环 100 次，从剪切板获取 UDID，并通过排序获得出现频率最高的那个 UDID，也就是这个流程可能最终会导致访问剪切板卡死。
NSUserDefaults 底层实现中存在直接或者间接的跨进程通信，在主线程同步调用容易发生卡死。
[[UIApplication sharedApplication] openURL]接口，内部实现也存在同步的跨进程通信。

最佳实践

废弃 OpenUDID 这个第三方库，一些依赖了 UIPaseteBoard 的第三方 SDK 推动维护者下掉对 UIPasteBoard 的依赖并更新版本；或者将这些 SDK 的初始化统一放在非主线程，不过经验来看子线程初始化可能有 5%的卡死转化为闪退，因此最好加一个开关逐步放量观察。
对于 kv 类存储需求，如果重度的使用可以考虑 MMKV，如果轻度的使用可以参考 firebase 的实现自己重写一个更轻量的 UserDefaults 类。
iOS10 及以上的系统版本使用[[UIApplication sharedApplication] openURL:options:completionHandler:]这个接口替换，此接口可以异步调起，不会造成卡死。

Objective-C Runtime Lock 死锁

问题描述

此类问题虽然出现概率不大，但是在一些复杂场景下也是时有发生。主线程的调用栈一般都会卡死在一个看似很普通的 OC 方法调用，非常隐晦，因此想要发现这类问题，卡死监控模块本身就不能用 OC 语言实现，而应该改为 C/C++。此问题一般多发于_dyld_register_func_for_add_image 回调方法中同步调用 OC 方法（先持有 dyld lock 后持有 OC runtime lock），以及 OC 方法同步调用 objc_copyClassNamesForImage 方法（先持有 OC runtime lock 后持有 dyld lock）。典型 case：

dyld lock、 selector lock 和 OC runtime lock 三个锁互相等待造成死锁的问题。三个锁互相等待的场景如下图所示：

在某次迭代的过程中 APM SDK 内部判定设备是否越狱的实现改为依赖 fork 方法能否调用成功，但是 fork 方法会调用 _objc_atfork_prepare，这个函数会获取 objc 相关的 lock，之后会调用 dyld_initializer，内部又会获取 dyld lock，如果此时我们的某个线程已经持有了 dyld lock，在等待 OC runtime lock，就会引发死锁。