文档中心

应用性能监控全链路版

请输入

iOS 端监控

如何排查 OOM 问题

OOM 崩溃方案简介

应用性能监控全链路版使用的是排除法方案来判定 OOM 崩溃的，之前的一篇技术文章详细介绍了判定的原理，可以参考 iOS性能优化实践：头条抖音如何实现OOM崩溃率下降50%+ 中的OOM 线上监控章节了解

如何识别真正的 App OOM

如上述 OOM 判定原理所述，当前的排除法方案虽然尽可能确保准确性，但依然还是会有误报的场景，可以根据如下数据判断一个 OOM 崩溃是不是误报：

16 表示 app 的内存占用已超过系统允许的最大内存 80%，这种情况基本可以确认是 app 内存占用过高导致的 OOM 问题，同时可以在内存趋势图中看到内存增长趋势，现场数据中也能看到 app 内存峰值

2、4 表示系统当前内存压力较大，这种情况下 app 主进程的内存占用可能并不高，而是系统其他例如 web 进程占用内存较高导致的，这些系统进程可能也和 app 相关。大部分情况下，这种内存压力值也伴随着 app 的高内存占用。

0 默认值，误报的可能性比较高，这种情况下一般 app 的内存占用不会特别高，但应用实际上确实是由于未知原因发生了闪退，可能的原因是：app 内存激增 SDK 未能记录到数据、系统整体内存占用较高、系统 fd/磁盘等资源不足强杀、误报等。这种数据不作为优先排查对象，一般用来观察不同版本的数据来确认内存优劣变化，并根据版本差异定位数据增长原因。

当系统内存压力状态为 0 时，可以查看内存趋势图和现场数据中的 app 内存占用确认，如果内存占用确实不高，且数据上报趋势没有明显变化，则可以降低问题排查的优先级，优先查看系统内存压力状态为 2、4、16 的数据。

正常退出场景我们都会进行排除，但是可能由于一些业务逻辑会影响到 OOM 的判定，例如部分业务可能 mock 或者拦截系统生命周期的通知回调等，导致 SDK 无法正确识别前后台状态或者 terminate 通知。

OOM 问题如何排查

OOM 崩溃上报的数据较少，分析问题需要结合其他信息或者通过抓取 MemoryGraph 来辅助排查，可以参考如下流程：

查看内存趋势图和现场数据，尝试还原用户操作路径，确认 OOM 触发的场景或者页面。如下 case 可知用户是在切换了三个页面之后，最终在 APMInsightCrashViewController 触发了 OOM 崩溃。根据业务逻辑推测当前页面是否会产生较大的内存占用，优化大内存占用来降低 OOM 风险

接入 MemoryGraph 后，当 app 内存占用到达一定阈值后，可以捕获当时的所有内存节点以及节点间的引用链路，通过分析这个数据来定位到是哪些内存对象分配过多、或者发生了泄露，详细使用说明可以参考 MemoryGraph 使用文档：

最近更新时间：2025.11.12 11:24:54

这个页面对您有帮助吗？

有用

无用