做iOS开发这些年OOM治理是我觉得最头疼的问题之一。用户一句“打开就闪退”崩溃平台却连堆栈都拿不到因为进程是被iOS系统直接杀掉的不是代码里抛了异常。iOS OOM治理说白了就是在监控、定位、优化、预防这几个环节上把App的峰值内存压到安全线以内避免被系统无情清理。这篇文章我想从实战角度把我在项目里踩过的坑、用过的工具、沉淀下来的治理流程完整梳理一遍适合正在被闪退率、卡死率折磨的iOS开发者参考。先说明白一个前提OOM治理不是一次性的“调参优化”而是一条需要长期运转的链路。你不可能只靠“少用内存”这种口号来解决问题必须先把现象量化、把根因定位、把措施落地最后还要靠线上数据验证效果。这篇文章会围绕这套思路展开尽量少讲理论多给能直接抄作业的方案。1. 先搞清楚OOM是什么为什么它比普通崩溃更难缠1.1 一个“没有堆栈”的崩溃现场有段时间我们App线上崩溃率一直不低但点开第三方崩溃平台发现大量错误类型是“EXC_RESOURCE_RESOURCE_TYPE_MEMORY”或者干脆只有一条“Terminated by Jetsam”。没有堆栈没有调用上下文没有用户操作路径只有设备的系统版本、内存剩余量和进程存活时间。我第一次看到这种日志时完全懵了明明代码里没有明显的崩溃点为什么用户会说“一进某页面就闪退”后来才明白这是iOS的JetSamber——系统级的内存看门狗——在内存紧张时把一个或多个进程强制终止了。它跟Objective-C异常、C异常、野指针访问完全不是一回事。普通崩溃是代码自己出了问题系统会生成一个包含现场寄存器和线程堆栈的崩溃报告而OOM是进程被系统“请出去”App本身根本来不及做任何处理自然也没有所谓的堆栈信息。这也是OOM治理最大的难点你连案发现场都看不到只能靠侧写。从运营视角来看OOM对用户体验的伤害非常大。用户对“闪退”的容忍度极低尤其是App用完相册、地图、扫码这类高内存场景就直接消失很容易被理解成“App质量差”。更麻烦的是如果你的App还申请了后台刷新OOM杀后台会带来一系列副作用比如用户切回来发现界面被重建、状态丢失这又会衍生出一堆“假异常”反馈。1.2 Jetsam机制iOS是怎么决定杀死App的Jetsam是苹果在Darwin内核里实现的一套内存管理策略。说人话它就像一个“宿舍管理员”每天盯着整栋宿舍楼的总电表和每个房间的用电量一旦发现用电紧张就会先挑几个耗电大户拉闸限电优先保证整栋楼不崩。在iOS里这个“房间”就是每个进程Jetsam会综合进程的内存使用量、内存压力、进程优先层级来排序。一旦系统的内存压力超过阈值或者某个进程的内存使用量突破了当前设备的上限Jetsam就会触发杀进程操作。值得注意的是前台App的优先级远高于后台App所以同等内存占用下后台进程更容易被杀。但如果你前台App使用内存过高照样会被杀而且这类杀进程对用户感知最明显。这里必须强调一个概念不同iPhone的内存限制不一样。内存阈值并不完全等于手机物理内存的一半苹果会根据设备型号动态调整。我在iPhone 14 Pro上跑满3GB多内存还可能没事但换到iPhone X上可能2GB就触发Jetsam了。所以测试OOM问题一定要准备老机型或者至少用System Trace去看设备实际的内存水位。别在最高配Pro上验证完就说“没问题”线上用户手里的机器千奇百怪。1.3 关键指标footprint、dirty memory与压缩内存很多开发者有个误区以为关注内存就是看CPU的Memory Report里的“Memory Used”。实际上系统Jetsam判断的核心是Memory Footprint尤其是dirty memory和compressed memory。clean memory页面可以从磁盘重新加载的内存比如图片文件映射到内存里的数据、可执行代码等。系统在压力大时可以悄悄丢弃所以它对Jetsam的影响相对较小。dirty memory进程自己修改过的内存比如对象堆、图像解码数据、缓存数据。这部分系统不能直接回收是导致OOM的主力。compressed memory当内存紧张时系统会把一部分不活跃的dirty memory压缩后放回内存池等再次访问时再解压。它能延缓OOM但压缩和解压都消耗CPU如果App频繁访问大块压缩内存系统会立即解压并把内存释放导致性能骤降。所以OOM治理的关键不是把Allocations里显示的总内存降到多低而是要特别关注“dirty memory”的峰值增长。比如加载一张2000x3000的JPEG原图解码后可能存在几十MB的bitmap这部分是dirty memory一旦图片显示在屏幕上缓存又没及时释放内存峰值就上去了。2. 数据先行OOM监控要覆盖到的四个层面2.1 客户端埋点内存水位与系统压力通知不管你是用崩溃平台还是自建监控OOM数据必须从App内部开始采集。以前我们只上传“用户在当前页面的停留时长”根本没法判断内存峰值发生在哪里。后来我在每个关键页面和关键业务动作上挂了监控点统一采集三类数据当前App的内存使用量footprint。系统的memory pressure状态。是否收到过didReceiveMemoryWarning。内存使用量可以借助mach_task_basic_info来获取代码大致是这样import UIKit import MachO func appFootprint() - UInt64 { var info mach_task_basic_info() var count mach_msg_type_number_t(MemoryLayoutmach_task_basic_info.size / MemoryLayoutinteger_t.size) let result withUnsafeMutablePointer(to: info) { $0.withMemoryRebound(to: integer_t.self, capacity: Int(count)) { task_info(mach_task_self_, task_flavor_t(MACH_TASK_BASIC_INFO), $0, count) } } return result KERN_SUCCESS ? UInt64(info.resident_size) : 0 }不过resident_size并不是系统判断OOM时使用的footprint它更偏向物理内存占用。如果你要更贴近Jetsam的判定建议用sysinfo或os_proc_available_memory()来反推剩余可用内存再结合系统底层的memorystatus接口做更精细的监控。生产环境里没有必要做到那么深但一定要能对比出不同机型的可用内存差异。低内存警告的监听也不能只靠applicationDidReceiveMemoryWarning。iOS 13之后系统会通过NSProcessInfo.processInfo.thermalState和NSProcessInfo.processInfo.pressureState反映内存压力最好同时监听这两个状态变化。收到警告就上报当前页面、当前内存、距上次释放缓存的时间点这些数据能帮我们在后台还原出一条内存增长的曲线。2.2 MetricKit苹果给的内存诊断接口如果你还在手工接内存上报那有点落后了。iOS 13之后苹果推出了MetricKit专门收集App的电源、性能、内存崩溃等指标。它有一个杀手级能力直接返回系统诊断到的OOM事件。用起来不算复杂import MetricKit class MetricsReporter: NSObject, MXMetricManagerSubscriber { override init() { super.init() MXMetricManager.shared.add(self) } func didReceive(_ payloads: [MXMetricPayload]) { for payload in payloads { // payload.memoryMetrics, payload.crashDiagnostics } } func didReceive(_ payloads: [MXDiagnosticPayload]) { for payload in payloads { // payload.crashDiagnostics 里能看到 OOM 相关诊断 } } }MetricKit的数据默认延迟到第二天不能用于实时报警但非常适合每周或每月做一次聚合分析。你可以在MXCrashDiagnostic的堆栈里看到被系统杀掉的进程主线程最后执行到了哪儿虽然不是完整stack trace但至少能定位到大致模块比完全黑盒强太多。注意MetricKit需要App有用户授权吗官方说明是默认不弹权限但有隐私要求实际使用中需要确认自己的合规流程。另外模拟器上不生效必须真机测试而且MetricKit拿到的数据只属于“系统认为需要上报”的样本不代表全部OOM事件。2.3 崩溃平台与Xcode里的OOM蛛丝马迹第三方崩溃平台一般在捕获到崩溃信号时生成一条日志它有没有能力识别OOM取决于SDK自己实现的采集逻辑。现在我们用的SDK会在启动时检查上次是否被Jetsam杀过如果是就补一条“内存OOM”事件但堆栈通常为空。这种情况下我会把崩溃平台的“无堆栈异常”单独拉一个分组看不要让它混在普通crash里否则结论会被带偏。在开发阶段Xcode本身也提供OOM记录。如果能从Xcode的Device窗口看到崩溃日志优先看JetsamEvent-*.ips文件。打开后能找到进程被杀时的内存占用量、设备物理内存、系统内存压力状态甚至能看到整个系统内的内存占用排名。这种日志一般是系统生成的真实度很高。Xcode Organizer里也有一个“Memory Resource Exceptions”栏目凡是跟内存资源有关的termination都会被列出来但只覆盖从TestFlight或App Store采集到的数据而且有上传延迟。所以线上问题的定性阶段我会把Xcode Organizer和MetricKit结合起来看数据互相印证。2.4 线上灰度对比用数据确认治理效果监控的最终目的是验证治理有没有效。我习惯在每次内存优化版本发灰度后选一组内存指标做对比每千用户OOM发生率、平均footprint峰值、低内存警告触发率。重点不是看绝对值而是看同版本在同号段设备上的环比变化。我遇到过一个很典型的场景某个版本用了更大的启动缓存首页启动快了不少但OOM率涨了30%。如果只看崩溃率根本发现不了因为你把一部分崩溃转移成了OOM对用户来说都是闪退。所以建议把“OOM率”和“无堆栈终止率”加到发布预警指标里跟崩溃率并列监控。3. 定位OOM根因从复现到取证3.1 Instruments Allocations抓住峰值瞬间当你拿到一条“某页面OOM频繁”的反馈后第一步不是急着改代码而是先在本地复现。Instruments里的Allocations工具是最常用的核心用法是连接真机选择Allocations模板。复现页面操作同时观察Persistent Memory和# Persistent的变化。在内存飙升前打一个Generation标记然后在页面退出后查看两个Generation之间的内存增量。按Persistent Memory倒序排序找到占用最大且一直没释放的对象。这里有一个容易被忽略的点Allocations只能看到通过malloc/retain等常规方式分配的内存它不直接显示ioSurface、ImageIO、Metal这类图形系统分配的部分。图片解码后的bitmap往往不在Allocations完全体现需要结合VM Tracker一起看。VM Tracker里能看到dirty_ranges、compressed等系统级内存分布这才是OOM最关心的维度。如果你的App重图片强烈建议把Allocations和VM Tracker同时打开。操作路径固定为“进入页面-上下滚动10次-退出页面-再进入”观察这个循环有没有让内存峰值抬升。如果反复操作后系统内存越来越高说明某个对象在持续累积没有释放。3.2 图像与缓存排查OOM大户往往在这里在我处理的OOM案例里八个里面有五个跟图片有关。具体表现各不相同但根源高度集中图片列表一次性加载原图没有做downsampling。图片内存cache没有上限导致缓存越积越多。后端下发的图片尺寸过大客户端直接解码全尺寸图。图片加载库比如SDWebImage的缓存策略设置得不合理decode后的大对象一直留在内存里。排查时首要从这些点入手。比如查看某个图片网络的回调里是否当着主线程直接UIImage(named:)加载大图。imageNamed会立刻解码并把图像数据放到缓存里如果图片是动态接口下发的甚至会造成缓存无限膨胀。另一个隐蔽的大户是UIScrollView里的离屏渲染和图层合成。复杂列表页的阴影、圆角、透明度叠加会产生大量CPU/GPU内存。遇到这类情况优先看Instruments里的Layer footprint若发现内存暴涨但Allocations里没有明显对象那多半是图层合成的锅。3.3 用低内存警告和压测脚本逼出问题OOM并不是每次都能稳定复现的。有些问题只在内存压力特别高的时候出现普通调试状态下根本碰不到。我常用的办法是先在模拟器里做系统级压力测试Xcode的Debug菜单里有Simulate Memory Warning能把系统内存低压力事件打给App用于验证清理逻辑有没有生效。在真机上可以通过后台脚本或者其他方式持续申请内存把系统内存压到危险线附近然后快速切回被测App观察它是否被Jetsam清理。但要注意Simulate Memory Warning只是模拟了一个低内存警告事件并不会真正触发Jetsam杀进程。它适合验证“收到警告后App是否清理缓存”但不适合验证“峰值过高是否被杀”。真正的Jetsam杀进程很难精确复现所以我们的验证目标是“让内存峰值稳定出现在某个水位”而不是精确复现“被系统杀死”那一刻。如果条件允许建议用Xcode的Metric Plotter或Instruments的Memory工具实时记录footprint曲线并在关键页面打点。这样你能对比出不同流程的内存峰值差异找到哪一步是“压垮骆驼的最后一根稻草”。3.4 特殊情况WebView和扩展进程的独立内存如果你的App里嵌了WKWebView就要注意一个特殊机制WKWebView的内容渲染不在App主进程里而是运行在独立的WebContent子进程。这个子进程的内存限制比主进程更严格很容易单独被Jetsam杀掉。很多人以为App主进程没崩就忽略WebView问题其实用户看到的却是“整个App白屏/闪退”。排查WebView OOM时常规的Allocations工具很难直接观测子进程Xcode的Debug Navigator会有一个“由WebContent进程占用”之类的条目但要打开多个进程的视图才能看到。更简单的方式是使用WKWebView的terminationHandler回调当WebContent进程被杀时会在主进程收到回调。收到回调后上报当前WebView地址、页面JS上下文大小、是否长时间驻留这些信息价值极高。扩展进程也一样。今天很多App都做了Widget、Share Extension进程独立于主App内存上限更小。如果你的OOM报告里出现了Extension名称不要在主App里找原因去检查扩展进程有没有加载大图、大数据模型、使用超大缓存。4. 治理落地把内存峰值压下来的实操方案4.1 图片Downsampling与解码优化图片是OOM的第一大来源所以第一个治理动作必须从图片开始。解决思路只有一个不要让App为了显示一张小图而解码整张大图。现代iOS开发里正确姿势是使用ImageIO生成缩略图也就是downsampling。下面是一段可以直接用的Swift降采样代码我通常在需要加载列表缩略图的地方调用它import ImageIO import UIKit func downsampleImage(at url: URL, to pointSize: CGSize, scale: CGFloat UIScreen.main.scale) - UIImage? { // 为了避免整图解码先让ImageIO知道我们只创建缩略图 let sourceOptions [kCGImageSourceShouldCache: false] as CFDictionary guard let source CGImageSourceCreateWithURL(url as CFURL, sourceOptions) else { return nil } let maxPixel max(pointSize.width, pointSize.height) * scale let options [ kCGImageSourceCreateThumbnailFromImageAlways: true, kCGImageSourceShouldCacheImmediately: true, kCGImageSourceCreateThumbnailWithTransform: true, kCGImageSourceThumbnailMaxPixelSize: maxPixel ] as CFDictionary guard let thumbnail CGImageSourceCreateThumbnailAtIndex(source, 0, options) else { return nil } return UIImage(cgImage: thumbnail) }关键点有两个kCGImageSourceThumbnailMaxPixelSize要按控件实际渲染尺寸去算而不是按逻辑宽高kCGImageSourceShouldCacheImmediately决定了缩略图生成后是否立即解码到内存。如果列表同时加载十几个缩略图适当把这几个参数设小能明显降低内存峰值。我记得有个运营活动页上线前图片过大同一屏加载了20多张全尺寸图导致内存瞬间涨到1.2GB。后来后端裁剪出750x750的缩略图客户端再用上面的downsample代码处理OOM率直接降了70%。所以优先从源头解决问题客户端只是兜底。4.2 NSCache的合理上限和主动清理策略NSCache是官方推荐的内存缓存但它有很多“反直觉”的坑。默认情况下它不限制缓存总量只依赖于系统内存压力来自动淘汰。问题是系统压力通知是滞后的有时候你已经缓存了几百MB系统才开始释放而OOM已经发生了。因此我强烈建议给NSCache设置totalCostLimit和countLimit。比如图片缓存可以按每张图片的像素尺寸作为costimageCache.totalCostLimit 60 * 1024 * 1024 // 60MB imageCache.countLimit 100同时在收到didReceiveMemoryWarning时不要只移除NSCache还要把临时生成的大数组、图片解码对象、页面持有的大Model全部清理。很多团队只在控制器中清空weak引用效果很差。正确的方式是建一个统一的内存缓存清理中心App内所有可重建对象都向它注册收到内存警告后批量清理。不过也要注意过度清理会影响性能。比如进入二级页面时刚刚构建的缓存被清空返回上一级页面又要重新加载反而造成CPU和I/O压力。所以把清理策略设计成“分级”可重建且代价低的对象第一个清可重建但代价高的对象最后清不可重建的完全不进缓存。4.3 集合与数据结构的懒加载、分批处理除了图片大数据集合也是OOM的重灾区。最典型的是翻开一个几万条数据的在线列表客户端一次性把所有数据拉下来存进数组同时创建了所有cell。虽然iOS的UITableView会自动复用cell但数据Model本身占用的内存不会自动下降。一个Model对象就算只有10个属性几万个Model也能轻松吃掉一两百MB。处理方案分三层数据层分页请求最多只保留当前页前后各几页的数据滑动出去就清理如果实在需要全量数据考虑落盘到SQLite或临时文件内存里只保留当前页模型。展示层列表页用estimatedRowHeight懒加载图片cell里只显示当前可见区域的详细信息。聚合层如果做数据聚合统计不要把所有Value都塞进数组用流式处理和增量计算。很多计算库支持分批输出结果没必要把全量中间结果留在内存。补充一个我们自己的例子之前举报列表页后台一次性返回了5000条数据客户端还做了全量搜索索引。结果用户一进入列表页内存增加300MB部分老机型直接OOM。后来把搜索索引改成在SQLite里完成列表数据改为50条一页加载问题就消失了。治理OOM很多时候不是写多精妙的代码而是砍掉那些“不必要留在内存里的数据”。4.4 单例、通知、闭包陷阱的清理这类问题属于“慢性中毒”不会瞬间让内存爆炸但日积月累会让App越来越臃肿最终在某次内存峰值时崩溃。常见的坑有单例对象里保存了所有页面的Model或ViewModel快照用来做统计上报根本不释放。通知中心的观察者在deinit里忘记移除导致回调闭包持有控制器。在闭包里捕获了self而这个闭包又被全局的某些单例或定时器持有形成引用环。在DispatchQueue的异步任务里持有大对象任务未完成前对象无法释放。排查这类问题需要结合Xcode的Memory Graph可视化工具。启动后进入某个页面做一系列操作然后返回上一级。在Debug Memory Graph里找到离开页面的控制器对象如果它还存在实例引用沿着引用链往上追就能看到被谁强持有。每次操作都检查一遍基本能清除90%的隐性持有问题。这里说个经验不要等到OOM治理时才做引用环清理。每次应用启动后在后台定时跑一个低优先级的“无主引用检测”任务用weak替换所有不必要的强引用能显著降低长期驻留内存。5. 常见问题与排查技巧实录5.1 为什么日志里找不到OOM记录很多同事问为什么我在崩溃平台里搜不到OOM这里需要明白一件事Jetsam是系统杀进程并不是App抛异常所以绝大多数异常捕获SDK根本不会收到信号。你的SDK甚至可能把OOM误判成“App正常退出”而完全不记录。要找到OOM记录可以从三条路入手设备本地的DiagnosticReports目录里查找JetsamEvent-*.ips文件里面记录了所有被杀进程的内存状态但前提是你有本机读写权限或者能用Xcode设备窗口导出。Xcode Organizer的Memory Resource Exceptions适合看线上用户聚合数据。自建监控在App启动时检查ProcessInfo.processInfo里的系统标志有些崩溃平台SDK实现了“上次退出是否异常”的检测。如果SDK没提供自己也可以写一个启动标记正常进入前台时记录“App在前台存活”如果上次启动后连一位都没跑到前台就再次启动那很可能是被Jetsam杀了。5.2 为什么Leaks检测没问题OOM还是发生这是新手最容易产生误解的地方。Leaks工具只能检测“永不再使用的对象是否被错误持有”也就是内存泄漏。但你OOM往往不是泄漏导致而是“峰值内存过高”。举个例子一次性加载1000张图片所有对象都正确释放但加载瞬间同时存在内存里这个瞬态峰值就已经超过Jetsam阈值了。所以OOM治理不等于内存泄漏治理。你更应该关注“瞬时分配峰值”和“dirty memory峰值”而不是纠结某个对象有没有被释放。Instruments里的Allocations只能看到内存泄漏如果要用它看峰值建议观察All Heap Allocations的Persistent值变化曲线。5.3 一张速查表定位高频OOM场景我整理了在实际项目中遇到的高频问题场景以及对应的优先排查方向可以直接存下来当参考场景现象可能根因优先排查列表页快速滚动后OOM图片全尺寸解码、cell瞬时创建图片downsampling、cell复用、预加载策略页面加载大型本地文件后OOM一次性读入Data/String改用FileHandle或mmap分批读取使用WKWebView后OOMWebContent子进程内存过高减少页面内容、清理Web缓存、复用WebView进入后台后杀死后台任务持大对象、单例缓存未清监听前后台切换清理缓存长时间连续打开多个页面OOM页面没有释放Model累积Memory Graph定位引用环定时器轮询内存上涨定时器循环持有大对象、循环创建对象检查Timer是否invalidate降低触发频率这张表不是万能的但可以帮你快速缩小范围。一般按“页面操作路径”去还原优先级是图片解码 缓存无限增长 WebView 大数据Model 引用环。5.4 我踩过的一个典型OOM坑最后讲一个真实案例。某个版本上线后我们崩溃平台里突然出现大量OOM报告集中在某个二级商品详情页。刚开始我以为是图片问题把页面里所有图片都做了downsampling但效果不明显。后来查了很久才发现问题出在UICollectionView的布局计算上。页面里有一个含有大量商品的横向瀑布流每个cell高度需要根据商品描述动态计算。我为了追求流畅提前把每个文本的boundingRect计算缓存到一个全局字典里。这本意是好的但商品量上线后这个字典里存了十几万条字符串尺寸数据每条数据还包括多个字体属性字符串。结果就是用户一进详情页内存立刻飙到600MB以上老机型直接OOM。解决方案也很简单给这个缓存字典只保留当前屏幕可见cell的数据滑动后立即清理同时把字体属性字符串做成共享常量而不是每次都新建。上线后OOM率从0.35%降到了0.06%。这次经历让我意识到OOM治理并不是一味地“加缓存”、“预计算”来提升性能有时候过度的“性能优化”本身就是OOM的根源。如果你也在做线上iOS OOM治理我建议从“监控埋点”和“图片解码”这两个环节起步。先把数据量起来再根据线上OOM的分布去锁定具体页面最后针对性地优化峰值内存。这个过程不会很快但每一步都是有迹可循的。记住OOM日志虽然没有堆栈但数据曲线和页面路径一样能帮你定位问题沉下心把监控做扎实问题迟早会水落石出。