# OOM 崩溃方案简介应用性能监控全链路版使用的是排除法方案来判定 OOM 崩溃的，之前的一篇技术文章详细介绍了判定的原理，可以参考 [iOS性能优化实践：头条抖音如何实现OOM崩溃率下降50%+](https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==&mid=2247486858&idx=1&sn=ec5964b0248b3526836712b26ef1b077&chksm=e9d0c668dea74f7e1e16cd5d65d1436c28c18e80e32bbf9703771bd4e0563f64723294ba1324&token=1483621236&lang=zh_CN&scene=21#wechat_redirect) 中的**OOM 线上监控**章节了解 # 如何识别真正的 App OOM 如上述 OOM 判定原理所述，当前的排除法方案虽然尽可能确保准确性，但依然还是会有误报的场景，可以根据如下数据判断一个 OOM 崩溃是不是误报： 1. 根据「系统内存压力状态」筛选，取值一般有四种： ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_fe774381cdc3a8e3985e755659f4f627.png =795x) 1. 16 表示 app 的内存占用已超过系统允许的最大内存 80%，这种情况基本可以确认是 app 内存占用过高导致的 OOM 问题，同时可以在内存趋势图中看到内存增长趋势，现场数据中也能看到 app 内存峰值 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_ca55074a6cba8ce42829d4af1ba56ba1.png =703x) ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_ae7fc8b62e6970d3c85e852997479a77.png =675x) 2. 2、4 表示系统当前内存压力较大，这种情况下 app 主进程的内存占用可能并不高，而是系统其他例如 web 进程占用内存较高导致的，这些系统进程可能也和 app 相关。大部分情况下，这种内存压力值也伴随着 app 的高内存占用。 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_0b99dc2a434af6bbd504c8403fe9c00b.png =846x) 3. 0 默认值，误报的可能性比较高，这种情况下一般 app 的内存占用不会特别高，但应用实际上确实是由于未知原因发生了闪退，可能的原因是：app 内存激增 SDK 未能记录到数据、系统整体内存占用较高、系统 fd/磁盘等资源不足强杀、误报等。这种数据不作为优先排查对象，一般用来观察不同版本的数据来确认内存优劣变化，并根据版本差异定位数据增长原因。 2. 当系统内存压力状态为 0 时，可以查看内存趋势图和现场数据中的 app 内存占用确认，如果内存占用确实不高，且数据上报趋势没有明显变化，则可以降低问题排查的优先级，优先查看系统内存压力状态为 2、4、16 的数据。 3. 除此之外，还可以结合业务数据来辅助问题确认，查看上报的用户是否进行了反馈、或者根据业务日志或者埋点查看是否是正常退出的场景被误报为了 OOM： 1. 正常退出场景我们都会进行排除，但是可能由于一些业务逻辑会影响到 OOM 的判定，例如部分业务可能 mock 或者拦截系统生命周期的通知回调等，导致 SDK 无法正确识别前后台状态或者 terminate 通知。 2. 部分业务自建的自动化测试流程 SDK 无法完全覆盖到，可能会被误报为 OOM，可以参考[如何屏蔽自动化任务中产生的 OOM 问题](https://www.volcengine.com/docs/6431/1343909)处理 3. 其他场景可以在线下尝试复现一下，如果确认是由于某种场景导致的误报，可以提工单反馈 # OOM 问题如何排查 OOM 崩溃上报的数据较少，分析问题需要结合其他信息或者通过抓取 MemoryGraph 来辅助排查，可以参考如下流程： 1. 查看内存趋势图和现场数据，尝试还原用户操作路径，确认 OOM 触发的场景或者页面。如下 case 可知用户是在切换了三个页面之后，最终在 APMInsightCrashViewController 触发了 OOM 崩溃。根据业务逻辑推测当前页面是否会产生较大的内存占用，优化大内存占用来降低 OOM 风险 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_12375d0a76e861f6da6c45cd9cb98e35.png =708x) ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_7fa7a0fb7d1f292d1546a2b6f6438062.png =705x) 2. 点击追查可以查看某个用户的事件流，分析用户发生 OOM 崩溃之前发生了哪些事件：加载了某个页面、发起了某个网络请求等 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_d18928d6f5f7a44fcffde0d10677a961.png =982x) ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_b9891a9908d120b4f211087a2132be45.png =978x) 3. 应用性能监控全链路版也提供了自定义事件和自定义日志，可以接入业务中，用来记录一些重要事件或者日志流，在发生问题时辅助问题排查： * 自定义事件：[接入](https://www.volcengine.com/docs/6431/1175759#58cb19df) [使用](https://www.volcengine.com/docs/6431/68855) 支持聚合分析，一般用于分析群体数据或者单点问题排查，例如统计方法耗时、业务流程埋点等。 * 自定义日志：[接入](https://www.volcengine.com/docs/6431/1175759#5e60c23f) [使用](https://www.volcengine.com/docs/6431/1175760#37eb91fa) 高性能流式日志，一般用于单点问题排查 4. [接入 MemoryGraph](https://www.volcengine.com/docs/6431/1175759#faa07592) 后，当 app 内存占用到达一定阈值后，可以捕获当时的所有内存节点以及节点间的引用链路，通过分析这个数据来定位到是哪些内存对象分配过多、或者发生了泄露，详细使用说明可以参考 [MemoryGraph 使用文档](https://www.volcengine.com/docs/6431/68858#.aU9T55WM6Z2i5qaC6KeI)： 1. 单独分析 MemoryGraph 问题 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_2af69d53d552398a5794ac7d332cf710.png =479x) ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_c304cf8495856edc4585c8d93d7b5003.png =851x) 2. 分析和 OOM 崩溃关联的问题 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_92a6c8c93cceb563f4775ad86a6c2e9f.png =922x) ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_eebfd5048d050df69c1bf1e7ec16c604.png =919x)