不同于 Android 系统中的卡死(ANR)问题,目前业界对 iOS 系统中 App 发生的卡死崩溃问题并无成熟的解决方案,主要原因是:
由于上面提到的两个原因,目前业界 iOS 生产环境中的卡死监控方案其实主要是基于卡顿监控,即当用户在使用 App 的过程中页面响应时间超过一定的卡顿的阈值(一般是几百 ms)之后判定为一次卡顿,然后抓取到当时现场的调用栈并且上报到后台分析。这种方案的缺陷主要体现在:
基于上述的痛点,字节跳动 APM 中台团队自研了一套专门用于定位生产环境中的卡死崩溃的解决方案,本文将详细地介绍该方案的思路和具体实现,以及通过本方案上线后总结出来的一些典型问题和最佳实践,期望对大家有所启发。
如果某一天我们的 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 行信息逐一解释:
EXC_CRASH:Mach 层的异常类型,表示进程异常退出。
SIGKILL:BSD 层的信号,表示进程被系统终止,而且这个信号不能被阻塞、处理和忽略。这时可以查看 Termination Reason 字段了解终止的原因。
这个字段一般用不上,当崩溃报告包含一个未命名的异常类型时,这个异常类型将用这个字段表示,形式是十六进制数字。
EXC_CORPSE_NOTIFY 和 EXC_CRASH 定义在同一个文件中,意思是进程异常进入 CORPSE 状态。
这里主要关注 Code 0x8badf00d,可以在苹果的官方文档中查看到 0x8badf00d 意味着 App ate bad food,表示进程因为 watchdog 超时而被操作系统结束进程。通过上述已经信息可以得出 watchdog 崩溃的定义:
在iOS平台上,App如果在启动、退出或者响应系统事件时因为耗时过长触发系统保护机制,最终导致进程被强制结束的这种异常定义为watchdog类型的崩溃。
所谓的 watchdog 崩溃也就是本文所说的卡死崩溃。
大家都知道在客户端研发中,因为会阻断用户的正常使用,闪退已经是最严重的 bug,会直接影响留存,收入等各项最核心的业务指标。之前大家重点关注的都是诸如 unrecognized selector、EXC_BAD_ACCESS 等可以在 App 进程内被捕获的崩溃(下文中称之为普通崩溃),但是对于 SIGKILL 这类因为进程外的指令强制退出导致的异常,原有的监控原理是覆盖不到的,也导致此类崩溃在生产环境中被长期忽视。除此之外,还有如下理由:
因此,基于以上信息我们可以得出结论:卡死崩溃的监控和治理是非常有必要的。经过近 2 年的监控和治理,目前今日头条 App 卡死崩溃每天发生的量级大致和普通崩溃持平。
其实从用户体验出发的话,卡死的定义就是长时间卡住并且最终也没有恢复的那部分卡顿,那么下面我们就先回顾一下卡顿监控的原理。我们知道在 iOS 系统中,主线程绝大部分计算或者绘制任务都是以 runloop 为单位周期性被执行的。单次 runloop 循环如果时长超过 16ms,就会导致 UI 体验的卡顿。那如何检测单次 runloop 的耗时呢?
通过上图可以看到,如果我们注册一个 runloop 生命周期事件的观察者,那么在 afterWaiting=>beforeTimers,beforeTimers=>beforeSources 以及 beforeSources=>beforeWaiting 这三个阶段都有可能发生耗时操作。所以对于卡顿问题的监控原理大概分为下面几步:
整体流程如下图所示:
其实通过上面的一些总结我们不难发现,长时间的卡顿最终无论是触发了系统的卡死崩溃,还是用户忍受不了主动结束进程或者退后台,他们的共同特征就是发生了长期时间卡顿且最终没有恢复,阻断了用户的正常使用流程。
基于这个理论的指导,我们就可以通过下面这个流程来判定某次卡顿到底是不是卡死:
通过这套流程分析下来,我们不仅可以检测到系统的卡死崩溃,也可以检测到用户忍受不了长时间卡顿最终杀掉应用或者退后台之后被系统杀死等行为,这些场景虽然并没有实际触发系统的卡死崩溃,但是严重程度其实是等同的。也就是说本文提到的卡死崩溃监控能力是系统卡死崩溃的超集。
系统的卡死崩溃日志格式截取部分如下:
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: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 中子线程同步访问主线程,最终造成死锁的问题。如上图所示,这个死锁的复现步骤是:
这里的其实是踩到了 CTTelephonyNetworkInfo 一个潜在的坑。如果这里替换成一段 dispatch_sync 到 dispatch_get_main_queue()的代码,效果还是等同的,同样有卡死崩溃的风险。
一个比较典型的问题是卡死在-[YYDiskCache containsObjectForKey:],YYDiskCache 内部针对磁盘多线程读写操作,通过一个信号量锁保证互斥。通过分析卡死堆栈可以发现是子线程占用锁资源进行耗时的写操作或清理操作引发主线程卡死,问题发生时一般可以发现如下的子线程调用栈:
此类问题,表现形式可能多种多样,但是归根结底都是因为磁盘 IO 过于密集最终导致主线程磁盘 IO 耗时过长。典型 case:
因为跨进程通信需要与其他进程同步,一旦其他进程发生异常或者挂起,很有可能造成当前 App 卡死。典型 case:
此类问题虽然出现概率不大,但是在一些复杂场景下也是时有发生。主线程的调用栈一般都会卡死在一个看似很普通的 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:
目前,字节 APM 中台自研的卡死监控功能已对外开发,搭载于字节跳动火山引擎旗下的应用性能监控平台上,以供外部开发者及企业使用。
应用性能监控平台所集成的相关技术,经今日头条、抖音、西瓜视频等众多 APP 的打磨,已沉淀出一套完整的解决方案,能够定位移动端、浏览器、小程序等多端问题,除了支持崩溃、错误、卡顿、网络等基础问题的分析,还提供关联到应用启动、页面浏览、内存优化的众多能力,目前 Demo 已开放,欢迎大家试用。
值得注意的是,火山引擎近期针对中小企业及个人开发者推出了增长赋能计划——「火种计划」。符合条件的企业/开发者仅需于官网注册并提交相应申请,即可免费使用应用性能监控这一平台,有需要的同学抓紧申请吧~
详情可点击传送门:https://zjsms.com/ed8ktbb/
本技术方案由字节跳动 APM 中台设计研发,欢迎对我们团队感兴趣的同学加入。
字节跳动 APM 中台目前致力于提升整个集团内全系产品的性能和稳定性表现,技术栈覆盖 iOS/Android/Flutter/Web/Hybrid/PC/游戏/小程序等,工作内容包括但不限于线上监控,线上运维,深度优化,线下防劣化等。长期期望为业界输出更多更有建设性的问题发现和深度优化手段。
欢迎各位有识之士加入我们,一起为了“更快,更稳,更省,更有品质”的极致目标携手前行。我们在北京,深圳两地均有招聘需求,简历投递邮箱:[email protected] ;邮件标题:姓名 - 工作年限 - APM 中台 - 技术栈方向(如 iOS/Android/Web/后端)。
[1] https://developer.apple.com/documentation/xcode/diagnosing_issues_using_crash_reports_and_device_logs/identifying_the_cause_of_common_crashes/addressing_watchdog_terminations
[2] https://geek-is-stupid.github.io/2018-10-15-0x8badf00d-ate-bad-food/
[3] https://honchwong.github.io/2018/05/05/Crash%E5%88%86%E6%9E%90%E7%B3%BB%E5%88%97%E4%B9%8B%E4%B8%80%EF%BC%9ALaunchDaemons%E4%B8%AD%E7%9A%84ReportCrash/
[4] https://zhuanlan.zhihu.com/p/37652140
[5] http://openfibers.github.io/blog/2016/10/22/deadlock-caused-by-dispatch-once/