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

字节跳动技术团队

于 2020-10-19 10:00:00 发布

阅读量1.5w

点赞数 4

CC 4.0 BY-SA版权

文章标签：编程语言 java python 大数据人工智能

本文链接：https://blog.youkuaiyun.com/ByteDanceTech/article/details/109172777

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

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

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

OOM 崩溃背景介绍

OOM

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

Jetsam

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

Jetsam 日志解读

上图是截取一份Jetsam日志中最关键的一部分。关键信息解读：

pageSize:指的是当前设备物理内存页的大小，当前设备是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. 整个设备物理内存占用收到压力按照下面优先级完成清理：

1. 后台应用>前台应用
2. 内存占用高的应用>内存占用低的应用
3. 用户应用>系统应用

Jetsam的代码在开源的XNU代码中可以找到，这里篇幅原因就不具体展开了，具体的源码解析可以参考本文最后第 2 和第 3 篇参考文献。

为什么要监控 OOM 崩溃

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

答案是有而且非常有必要的！原因如下：

重度用户也就是使用时间更长的用户更容易发生FOOM，对这部分用户体验的伤害导致用户流失的话对业务损失更大。
头条，抖音等多个产品线上数据均显示FOOM量级比普通崩溃还要多，因为过去缺乏有效的监控和治理手段导致问题被长期忽视。
内存占用过高即使没导致FOOM也可能会导致其他应用BOOM的概率变大，一旦用户发现从微信切换到我们 App 使用，再切回微信没有停留在之前微信的聊天页面而是重新启动的话，对用户来说，体验是非常糟糕的。