性能优化

IOS字节：卡死崩溃监控

2021-12-01  本文已影响0人  时光啊混蛋_97boy

原创：知识点总结性文章
创作不易，请珍惜，之后会持续更新，不断完善
个人比较喜欢做笔记和写总结，毕竟好记性不如烂笔头哈哈，这些文章记录了我的IOS成长历程，希望能与大家一起进步
温馨提示：由于简书不支持目录跳转，大家可通过command + F 输入目录标题后迅速寻找到你所需要的内容

目录

一、卡死崩溃背景介绍

不同于 Android 系统中的卡死（ANR）问题，目前业界对 iOS 系统中 App 发生的卡死崩溃问题并无成熟的解决方案，主要原因是：通常 App 卡死时间超过 20s 之后会触发操作系统的保护机制，发生崩溃，此时在用户的设备中能找到操作系统生成的卡死崩溃日志，但是因为 iOS 系统封闭生态的关系，App 层面没有权限拿到卡死崩溃的日志。一般而言用户遇到卡死问题的时候并没有耐心等待那么久的时间，可能在卡住 5s 时就已经失去耐心，直接手动关闭应用或者直接将应用退到后台，因此这两种场景下系统也就不会生成卡死崩溃日志。

由于上面提到的两个原因，目前业界 iOS 生产环境中的卡死监控方案其实主要是基于卡顿监控，即当用户在使用 App 的过程中页面响应时间超过一定的卡顿的阈值（一般是几百 ms）之后判定为一次卡顿，然后抓取到当时现场的调用栈并且上报到后台分析。这种方案的缺陷主要体现在：没有将比较轻微的卡顿问题和严重的卡死问题区分开，导致上报的问题数量太多，很难聚焦到重点。实际上这部分问题对用户体验的伤害其实是远远大于卡顿的。

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

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

基于上述的痛点，字节跳动 APM 中台团队自研了一套专门用于定位生产环境中的卡死崩溃的解决方案，本文将详细的介绍该方案的思路和具体实现，以及通过本方案上线后总结出来的一些典型问题和最佳实践，期望对大家有所启发。

目前，字节 APM 中台自研的卡死监控功能已对外开发，搭载于字节跳动火山引擎旗下的应用性能监控平台上，以供外部开发者及企业使用。应用性能监控平台所集成的相关技术，经今日头条、抖音、西瓜视频等众多 APP 的打磨，已沉淀出一套完整的解决方案，能够定位移动端、浏览器、小程序等多端问题，除了支持崩溃、错误、卡顿、网络等基础问题的分析，还提供关联到应用启动、页面浏览、内存优化的众多能力，目前 Demo 已开放，欢迎大家试用。值得注意的是，火山引擎近期针对中小企业及个人开发者推出了增长赋能计划——「火种计划」。符合条件的企业/开发者仅需于官网注册并提交相应申请，即可免费使用应用性能监控这一平台，有需要的同学抓紧申请吧～详情可点击传送门：https://zjsms.com/ed8ktbb/

1、什么是 watchdog

如果某一天我们的 App 在启动时卡住大概 20s 然后崩溃之后，从设备中导出的系统崩溃日志很可能是下面这种格式。下面就其中最重要的前 4 行信息逐一解释：

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace ASSERTIOND, Code 0x8badf00d
Triggered by Thread:  0
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 崩溃也就是本文所说的卡死崩溃。

2、为什么要监控卡死崩溃

大家都知道在客户端研发中，因为会阻断用户的正常使用，闪退已经是最严重的 bug，会直接影响留存，收入等各项最核心的业务指标。之前大家重点关注的都是诸如 unrecognized selector、EXC_BAD_ACCESS 等可以在 App 进程内被捕获的崩溃（下文中称之为普通崩溃），但是对于SIGKILL这类因为进程外的指令强制退出导致的异常，原有的监控原理是覆盖不到的，也导致此类崩溃在生产环境中被长期忽视。除此之外，还有如下理由：

因为卡死崩溃最常见发生于 App 启动阶段，用户在开屏页面卡住 20s 后什么都做不了紧接着 App 就闪退了。这种体验对用户的伤害比普通的崩溃更加严重。

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

OOM 崩溃也是由 SIGKILL 异常信号最终触发的，目前 OOM 崩溃主流的监控原理还是排除法。不过传统方案在做排除法的时候漏掉了一类量级非常大的其他类型的崩溃就是这里的卡死崩溃。如果能准确的监控到卡死崩溃，也同样能大大提高 OOM 崩溃监控的准确性。关于 OOM 崩溃的具体监控原理和优化思路可以参考：iOS 性能优化实践：头条抖音如何实现 OOM 崩溃率下降 50%+。

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

3、卡死崩溃监控原理

卡顿监控原理

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

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

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

整体流程如下图所示：

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

其实通过上面的一些总结我们不难发现，长时间的卡顿最终无论是触发了系统的卡死崩溃，还是用户忍受不了主动结束进程或者退后台，他们的共同特征就是发生了长期时间卡顿且最终没有恢复，阻断了用户的正常使用流程。基于这个理论的指导，我们就可以通过下面这个流程来判定某次卡顿到底是不是卡死：

  1. 某次长时间的卡顿被检测到之后，记录当时所有线程的调用栈，存到数据库中作为卡死崩溃的怀疑对象。
  2. 假如在当前runloop的循环中进入到了下一个活跃状态，那么该卡顿不是一次卡死，就从数据库中删除该条日志。本次使用周期内，下次长时间的卡顿触发时再重新写入一条日志作为怀疑对象，依此类推。
  3. 在下次启动时检测上一次启动有没有卡死的日志（用户一次使用周期最多只会发生一次卡死），如果有，说明用户上一次使用期间最终遇到了一次长时间的卡顿，且最终 runloop 也没能进入下一个活跃状态，则标记为一次卡死崩溃上报。

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

5、卡死时间的阈值如何确定

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

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 卡顿的概率要低的多，因此该卡死监控方案并没有太大的性能损耗，也就可以在生产环境中对全量用户开放。

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

在卡死发生之后，实际上我们也会关注一次卡死最终到底卡住了多久，卡死时间越长，对用户使用体验的伤害也就越大，更应该被高优解决。在触发卡死阈值之后我们可以再以一个时间间隔比较短的定时器（目前策略默认 1s，线上可调整），每隔 1s 就检测当前 runloop 有没有进入到下一个活跃状态，如果没有，则当前的卡死时间就累加 1s，用这种方式即使最终发生了闪退也可以逼近实际的卡死时间，误差不超过 1s，最终的卡死时间也会写入到日志中一起上报。

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

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

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

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

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

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

1、多线程死锁

问题描述

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

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

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

最佳实践

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

问题描述

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

最佳实践

3、磁盘 IO 过于密集

问题描述

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

最佳实践

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

问题描述

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

最佳实践

废弃 OpenUDID 这个第三方库，一些依赖了 UIPaseteBoard 的第三方 SDK 推动维护者下掉对 UIPasteBoard的依赖并更新版本；或者将这些 SDK 的初始化统一放在非主线程，不过经验来看子线程初始化可能有 5%的卡死转化为闪退，因此最好加一个开关逐步放量观察。

对于 kv 类存储需求，如果重度的使用可以考虑 MMKV，如果轻度的使用可以参考 firebase 的实现自己重写一个更轻量的 UserDefaults 类。

iOS10 及以上的系统版本使用[[UIApplication sharedApplication] openURL:options:completionHandler:]这个接口替换，此接口可以异步调起，不会造成卡死。

5、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：

  1. dyld lock、selector lock 和OC runtime lock三个锁互相等待造成死锁的问题。三个锁互相等待的场景如下图所示：
图片
  1. 在某次迭代的过程中 APM SDK 内部判定设备是否越狱的实现改为依赖 fork 方法能否调用成功，但是 fork 方法会调用 _objc_atfork_prepare，这个函数会获取 objc 相关的 lock，之后会调用 dyld_initializer，内部又会获取 dyld lock，如果此时我们的某个线程已经持有了 dyld lock，在等待 OC runtime lock，就会引发死锁。
最佳实践
  1. 慎用_dyld_register_func_for_add_image 和 objc_copyClassNamesForImage 这两个方法，特别是与 OC 方法同步调用的场景。
  2. 越狱检测，不依赖 fork 方法的调用。

三、OOM 崩溃率下降 50%+

iOS OOM 崩溃在生产环境中的归因一直是困扰业界已久的疑难问题，字节跳动旗下的头条、抖音等产品也面临同样的问题。

在字节跳动性能与稳定性保障团队的研发实践中，我们自研了一款基于内存快照技术并且可应用于生产环境中的OOM归因方案——线上 Memory Graph。基于此方案，3 个月内头条抖音OOM崩溃率下降 50%+。

本文主要分享下该解决方案的技术背景，技术原理以及使用方式，旨在为这个疑难问题提供一种新的解决思路。

1、OOM 崩溃背景介绍

OOM

OOM 其实是Out Of Memory的简称，指的是在 iOS 设备上当前应用因为内存占用过高而被操作系统强制终止，在用户侧的感知就是 App 一瞬间的闪退，与普通的Crash没有明显差异。但是当我们在调试阶段遇到这种崩溃的时候，从设备设置->隐私->分析与改进中是找不到普通类型的崩溃日志，只能够找到Jetsam开头的日志，这种形式的日志其实就是 OOM 崩溃之后系统生成的一种专门反映内存异常问题的日志。那么下一个问题就来了，什么是Jetsam？

Jetsam

Jetsam是 iOS 操作系统为了控制内存资源过度使用而采用的一种资源管控机制。不同于MacOS，Linux，Windows等桌面操作系统，出于性能方面的考虑，iOS 系统并没有设计内存交换空间的机制，所以在 iOS 中，如果设备整体内存紧张的话，系统只能将一些优先级不高或占用内存过大的进程直接终止掉。下图是截取一份Jetsam日志中最关键的一部分。关键信息解读：

ageSize：指的是当前设备物理内存页的大小，当前设备是iPhoneXs Max，大小是 16KB，苹果 A7 芯片之前的设备物理内存页大小则是 4KB。
states：当前应用的运行状态，对于Heimdallr-Example这个应用而言是正在前台运行的状态，这类崩溃我们称之为FOOM(Foreground Out Of Memory)；与此相对应的也有应用程序在后台发生的 OOM 崩溃，这类崩溃我们称之为BOOM(Background Out Of Memory)。
rpages：是resident pages的缩写，表明进程当前占用的内存页数量，Heimdallr-Example 这个应用占用的内存页数量是 92800，基于 pageSize 和rpages可以计算出应用崩溃时占用的内存大小:16384 * 92800 / 1024 /1024 = 1.4GB。
reason：表明进程被终止的的原因，Heimdallr-Example这个应用被终止的原因是超过了操作系统允许的单个进程物理内存占用的上限。

Jetsam机制清理策略可以总结为下面两点：
  1. 单个 App 物理内存占用超过上限
  2. 整个设备物理内存占用收到压力按照下面优先级完成清理：
为什么要监控 OOM 崩溃

前面我们已经了解到，OOM 分为FOOM和BOOM两种类型，显然前者因为用户的感知更明显，所以对用户的体验的伤害更大，下文中提到的OOM崩溃仅指的是FOOM。那么针对 OOM 崩溃问题有必要建立线上的监控手段吗？答案是有而且非常有必要的！原因如下：

重度用户也就是使用时间更长的用户更容易发生FOOM，对这部分用户体验的伤害导致用户流失的话对业务损失更大。

头条，抖音等多个产品线上数据均显示FOOM量级比普通崩溃还要多，因为过去缺乏有效的监控和治理手段导致问题被长期忽视。

内存占用过高即使没导致FOOM也可能会导致其他应用BOOM的概率变大，一旦用户发现从微信切换到我们 App 使用，再切回微信没有停留在之前微信的聊天页面而是重新启动的话，对用户来说，体验是非常糟糕的。

OOM 线上监控
#define SIGKILL 9 kill (cannot be caught or ignored)

翻阅XNU源码的时候我们可以看到在Jetsam机制终止进程的时候最终是通过发送SIGKILL异常信号来完成的。从系统库 signal.h 文件中我们可以找到SIGKILL这个异常信号的解释，它不可以在当前进程被忽略或者被捕获，我们之前监听异常信号的常规 Crash 捕获方案肯定也就不适用了。那我们应该如何监控 OOM 崩溃呢？正面监控这条路行不通，Facebook提出了另外一种思路，简而言之就是排除法。具体流程可以参考下面这张流程图：

我们在每次 App 启动的时候判断上一次启动进程终止的原因，那么已知的原因有：

如果上一次启动进程终止的原因不是上述任何一个已知原因的话，就判定上次启动发生了一次FOOM崩溃。曾经Facebook旗下的Fabric也是这样实现的。但是通过我们的测试和验证，上述这种方式至少将以下几种场景误判：

在字节跳动 OOM 崩溃监控上线之前，我们已经排除了上面已知的所有误判场景。需要说明的是，因为排除法毕竟没有直接的监控来的那么精准，或多或少总有一些 bad case，但是我们会保证尽量的准确。

2、自研线上 Memory Graph，OOM 崩溃率下降 50%+

OOM 生产环境归因

目前在 iOS 端排查内存问题的工具主要包括 Xcode 提供的 Memory Graph 和 Instruments 相关的工具集，它们能够提供相对完备的内存信息，但是应用场景仅限于开发环境，无法在生产环境使用。由于内存问题往往发生在一些极端的使用场景，线下开发测试一般无法覆盖对应的问题，Xcode 提供的工具无法分析处理大多数偶现的疑难问题。对此，各大公司都提出了自己的线上解决方案，并开源了例如MLeaksFinder、OOMDetector、FBRetainCycleDetector等优秀的解决方案。

在字节跳动内部的使用过程中，我们发现现有工具各有侧重，无法完全满足我们的需求。主要的问题集中在以下两点：

基于 Objective-C 对象引用关系找循环引用的方案，适用范围比较小，只能处理部分循环引用问题，而内存问题通常是复杂的，类似于内存堆积，Root Leak，C/C++层问题都无法解决。

基于分配堆栈信息聚类的方案需要常驻运行，对内存、CPU 等资源存在较大消耗，无法针对有内存问题的用户进行监控，只能广撒网，用户体验影响较大。同时，通过某些比较通用的堆栈分配的内存无法定位出实际的内存使用场景，对于循环引用等常见泄漏也无法分析。

为了解决头条，抖音等各产品日益严峻的内存问题，我们自行研发了一款基于内存快照技术的线上方案，我们称之为——线上 Memory Graph。上线后接入了集团内几乎所有的产品，帮助各产品修复了多年的历史问题，OOM 率降低一个数量级，3 个月之内抖音最新版本 OOM率下降了 50%，头条下降了 60%。线上突发 OOM 问题定位效率大大提升，彻底告别了线上 OOM 问题归因“两眼一抹黑”的时代。

线上 Memory Graph 核心的原理是扫描进程中所有 Dirty 内存，通过内存节点中保存的其他内存节点的地址值建立起内存节点之间的引用关系的有向图，用于内存问题的分析定位，整个过程不使用任何私有 API。这套方案具备的能力如下：

线上 Memory Graph 采集内存快照主要是为了获取当前运行状态下所有内存对象以及对象之间的引用关系，用于后续的问题分析。主要需要获取的信息如下：

由于采集的过程发生在程序正常运行的过程中，为了保证不会因为采集内存快照导致程序运行异常，整个采集过程需要在一个相对静止的运行环境下完成。因此，整个快照采集的过程大致分为以下几个步骤：

下面会分别介绍整个采集过程中一些实现细节上的考量以及收集信息的取舍。

内存节点的获取

程序的内存都是由虚拟内存组成的，每一块单独的虚拟内存被称之为VM Region，通过 mach 内核的vm_region_recurse/vm_region_recurse64函数我们可以遍历进程内所有VM Region，并通过vm_region_submap_info_64结构体获取以下信息：

大多数 VM Region 作为一个单独的内存节点，仅记录起始地址和 Dirty、Swapped 内存作为大小，以及与其他节点之间的引用关系；而 libmalloc 维护的堆内存所在的 VM Region 则由于往往包含大多数业务逻辑中的 Objective-C 对象、C/C++对象、buffer 等，可以获取更详细的引用信息，因此需要单独处理其内部节点、引用关系。

在 iOS 系统中为了避免所有的内存分配都使用系统调用产生性能问题，相关的库负责一次申请大块内存，再在其之上进行二次分配并进行管理，提供给小块需要动态分配的内存对象使用，称之为堆内存。程序中使用到绝大多数的动态内存都通过堆进行管理，在 iOS 操作系统上，主要的业务逻辑分配的内存都通过libmalloc进行管理，部分系统库为了性能也会使用自己的单独的堆管理，例如WebKit内核使用bmalloc，CFNetwork也使用自己独立的堆，在这里我们只关注libmalloc内部的内存管理状态，而不关心其它可能的堆（即这部分特殊内存会以VM Region的粒度存在，不分析其内部的节点引用关系）。

我们可以通过malloc_get_all_zones获取libmalloc内部所有的zone，并遍历每个zone中管理的内存节点，获取libmalloc管理的存活的所有内存节点的指针和大小。

符号化

获取所有内存节点之后，我们需要为每个节点找到更加详细的类型名称，用于后续的分析。其中，对于 VM Region 内存节点，我们可以通过 user_tag 赋予它有意义的符号信息；而堆内存对象包含 raw buffer，Objective-C/Swift、C++等对象。对于 Objective-C/Swift、C++这部分，我们通过内存中的一些运行时信息，尝试符号化获取更加详细的信息。

Objective/Swift 对象的符号化相对比较简单，很多三方库都有类似实现，Swift在内存布局上兼容了Objective-C，也有isa指针，objc相关方法可以作用于两种语言的对象上。只要保证 isa 指针合法，对象实例大小满足条件即可认为正确。C++对象根据是否包含虚表可以分成两类。对于不包含虚表的对象，因为缺乏运行时数据，无法进行处理。对于对于包含虚表的对象，在调研 mach-o 和 C++的 ABI 文档后，可以通过 std::type_info 和以下几个 section 的信息获取对应的类型信息。

C++实例以及 vtable 的引用关系示意图

在 iOS 系统内，还有一类特殊的对象，即CoreFoundation。除了我们熟知的CFString、CFDictionary外等，很多很多系统库也使用 CF 对象，比如CGImage、CVObject等。从它们的 isa 指针获取的Objective-C类型被统一成__NSCFType。由于CoreFoundation 类型支持实时的注册、注销类型，为了细化这部分的类型，我们通过逆向拿到 CoreFoundation 维护的类型 slot 数组的位置并读取其数据，保证能够安全的获取准确的类型。

CoreFoundation 类型获取
引用关系的构建

整个内存快照的核心在于重新构建内存节点之间的引用关系。在虚拟内存中，如果一个内存节点引用了其它内存节点，则对应的内存地址中会存储指向对方的指针值。基于这个事实我们设计了以下方案：

对于一些特定的内存区域，为了获取更详细的信息用于排查问题，我们对栈内存以及 Objective-C/Swift 的堆内存进行了一些额外的处理。其中，栈内存也以VM Region的形式存在，栈上保存了临时变量和TLS 等数据，获取相应的引用信息可以帮助排查诸如 autoreleasepool 造成的内存问题。由于栈并不会使用整个栈内存，为了获取 Stack 的引用关系，我们根据寄存器以及栈内存获取当前的栈可用范围，排除未使用的栈内存造成的无效引用。

而对于Objective-C/Swift对象，由于运行时包含额外的信息，我们可以获得Ivar的强弱引用关系以及Ivar的名字，带上这些信息有助于我们分析问题。通过获得Ivar的偏移，如果找到的引用关系的偏移和Ivar的偏移一致，则认为这个引用关系就是这个Ivar，可以将Ivar相关的信息附加上去。

数据上报策略

我们在 App 内存到达设定值后采集 App 当时的内存节点和引用关系，然后上传至远端进行分析，可以精准的反映 App 当时的内存状态，从而定位问题，总的流程如下：

整个线上 Memory Graph 模块工作的完整流程如上图所示，主要包括：

后台分析

这是字节监控平台 Memory Graph 单点详情页的一个 case：

线上 Memory Graph 详情页概览

我们可以看到这个用户的内存占用已经将近 900MB，我们分析时候的思路一般是：

当前引用路径在同类型对象中出现频率统计

通过上图中引用路径的分析我们发现，所有的图片最终都被TTImagePickController这个类持有，最终排查到是图片选择器模块一次性把用户相册中的所有图片都加载到内存里，极端情况下会发生这个问题。

3、整体性能和稳定性

采集侧优化策略

由于整个内存空间一般包含的内存节点从几十万到几千万不等，同时程序的运行状态瞬息万变，采集过程有着很大的性能和稳定性的压力。

我们在前面的基础上还进行了一些性能优化：

对于稳定性部分，我们着重考虑了下面几点：

死锁

由于无法保证 Objective-C 运行时锁的状态，我们将需要通过运行时 api 获取的信息在挂起线程前提前缓存。同时，为了保证libmalloc锁的状态安全，在挂起线程后我们对 libmalloc 的锁状态进行了判断，如果已经锁住则恢复线程重新尝试挂起，避免堆死锁。

非法内存访问

在挂起所有其他线程后，为了减少采集本身分配的内存对采集的影响，我们使用了一个单独的malloc_zone管理采集模块的内存使用。

性能损耗

因为在数据采集的时候需要挂起所有线程，会导致用户感知到卡顿，所以字节模块还是有一定性能损耗的，经过我们测试，在iPhone8 Plus设备上，App 占用 1G 内存时，采集用时 1.5-2 秒，采集时额外内存消耗 10-20MB，生成的文件zip后大小在 5-20MB。
为了严格控制性能损耗，线上Memory Graph模块会应用以下策略，避免太频繁的触发打扰用户正常使用，避免自身内存和磁盘等资源过多的占用：

性能损耗控制策略
稳定性

该方案已经在字节全系产品线上稳定运行了 6 个月以上，稳定性和成功率得到了验证，目前单次采集成功率可以达到 99.5%，剩下的失败基本都是由于内存紧张提前 OOM，考虑到大多数应用只有不到千分之一的用户会触发采集，这种情况属于极低概率事件。

试用路径

目前，线上 Memory Graph 已搭载在字节跳动火山引擎旗下应用性能管理平台（APMInsight）上赋能给外部开发者使用。APMInsight 的相关技术经过今日头条、抖音、西瓜视频等众多应用的打磨，已沉淀出一套完整的解决方案，能够定位移动端、浏览器、小程序等多端问题，除了支持崩溃、错误、卡顿、网络等基础问题的分析，还提供关联到应用启动、页面浏览、内存优化的众多功能。目前 Demo 已开放大部分能力，欢迎各位注册账号试用：https://www.volcengine.cn/product/apminsight

参考文献

上一篇 下一篇

猜你喜欢

热点阅读