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

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

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

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

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

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

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

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

基于上述的痛点，字节跳动 APM 中台团队自研了一套专门用于定位生产环境中的卡死崩溃的解决方案，
卡死崩溃背景介绍什么是 watchdog
如果某一天我们的 App 在启动时卡住大概 20s 然后崩溃之后，从设备中导出的系统崩溃日志很可能是下面这种格式：
ExceptionType:EXC_CRASH(SIGKILL)
ExceptionCodes:0x0000000000000000,0x0000000000000000
ExceptionNote:EXC_CORPSE_NOTIFY
TerminationReason:NamespaceASSERTIOND,Code0x8badf00d
TriggeredbyThread:0
下面就其中最重要的前 4 行信息逐一解释：

Exception Type

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

Exception Codes

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

Exception Note

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

Termination Reason

这里主要关注 Code 0x8badf00d ，可以在苹果的官方文档中查看到 0x8badf00d 意味着 App ate bad food，表示进程因为 watchdog 超时而被操作系统结束进程。通过上述已经信息可以得出 watchdog 崩溃的定义：
在iOS平台上，App如果在启动、退出或者响应系统事件时因为耗时过长触发系统保护机制，最终导致进程被强制结束的这种异常定义为watchdog类型的崩溃。
所谓的 watchdog 崩溃也就是
【iOS 稳定性问题治理：卡死崩溃监控原理及最佳实践】为什么要监控卡死崩溃
大家都知道在客户端研发中，因为会阻断用户的正常使用，闪退已经是最严重的 bug，会直接影响留存，收入等各项最核心的业务指标。之前大家重点关注的都是诸如 unrecognized selector、EXC_BAD_ACCESS 等可以在 App 进程内被捕获的崩溃（下文中称之为普通崩溃），但是
值得注意的是，火山引擎近期针对中小企业及个人开发者推出了增长赋能计划——「火种计划」。符合条件的企业/开发者仅需于官网注册并提交相应申请，即可免费使用应用性能监控这一平台，有需要的同学抓紧申请吧～
详情可点击传送门：https://zjsms.com/ed8ktbb/
加入我们
本技术方案由字节跳动 APM 中台设计研发，欢迎对我们团队感兴趣的同学加入。
字节跳动 APM 中台目前致力于提升整个集团内全系产品的性能和稳定性表现，技术栈覆盖 iOS/Android/Flutter/Web/Hybrid/PC/游戏/小程序等，工作内容包括但不限于线上监控，线上运维，深度优化，线下防劣化等。长期期望为业界输出更多更有建设性的问题发现和深度优化手段。
欢迎各位有识之士加入我们，一起为了“更快，更稳，更省，更有品质”的极致目标携手前行。我们在北京，深圳两地均有招聘需求，简历投递邮箱：tech@bytedance.com ；邮件标题：姓名 – 工作年限 – 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/
以上就是朝夕生活（www.30zx.com）关于“iOS 稳定性问题治理：卡死崩溃监控原理及最佳实践”的详细内容，希望对大家有所帮助！

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

猜你喜欢