iOS性能优化实践：头条抖音如何实现OOM崩溃率下降50%+(1)

排除法判定OOM崩溃的流程

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

• App 更新了版本

• App 发生了崩溃

• 用户手动退出

• 操作系统更新了版本

• App 切换到后台之后进程终止

如果上一次启动进程终止的原因不是上述任何一个已知原因的话，就判定上次启动发生了一次FOOM崩溃。

曾经Facebook旗下的Fabric也是这样实现的。但是通过我们的测试和验证，上述这种方式至少将以下几种场景误判：

• WatchDog 崩溃

• 后台启动

• XCTest/UITest 等自动化测试框架驱动

• 应用 exit 主动退出

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

自研线上 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。这套方案具备的能力如下：

1. 完整还原用户当时的内存状态。

2. 量化线上用户的大内存占用和内存泄漏，可以精确的回答 App 内存到底大在哪里这个问题。

3. 通过内存节点符号和引用关系图回答内存节点为什么存活这个问题。

4. 严格控制性能损耗，只有当内存占用超过异常阈值的时候才会触发分析。没有运行时开销，只有采集时开销，对 99.9%正常使用的用户几乎没有任何影响。

5. 支持主要的编程语言，包括 OC，C/C++，Swift，Rust 等。

线上 Memory Graph 采集及上报流程示意图

内存快照采集

---

线上 Memory Graph 采