外观
iOS 内存拓扑与 Jetsam OOM 压力诊断指南：物理限制与泄漏排查
iOS 内存问题既会影响响应速度与缓存行为，也可能在系统内存压力升高时影响进程生存。Jetsam / memorystatus 终止并不等同于普通 Crash，很多场景也不会留下应用自身的异常堆栈，因此测试需要同时保留进程内存趋势、设备内存环境与系统终止证据。
本指南解释 iOS 内存拓扑、Jetsam 证据边界，并给出一套可复现、可按项目历史分布校准的内存增长与峰值测试方法。
图：Virtual、Resident、Physical Footprint 描述目标进程不同层面；Available / Free 描述整机环境，不能互换。
1. iOS 内存管理的物理铁律
1.1 iOS 的内存压力与回收边界
移动端的内存压力处理不能简单套用桌面系统“RAM 不够就无限写 Swap”的模型。iOS 会回收 clean/file-backed、purgeable 等可回收资源，并通过 memorystatus / Jetsam 管理高压情况下的进程生存优先级。测试时应同时区分目标 App 自身 footprint 与整机 Available / Free 环境，而不是从单个数值推断系统必然行为。
1.2 Jetsam / memorystatus：不是单指标裁决
iOS 的内存终止决策与系统可用页、进程优先级、进程内存限制及其它内核状态有关。Physical Footprint 是分析目标 App 内存压力的关键指标之一，但不是可以脱离上下文使用的唯一 Jetsam 判据。
正确看待三类数字
- Memory / Physical Footprint：适合观察目标 App 自身内存压力、版本回归和长期增长趋势。
- Real Memory：Perfowl 当前映射
memResidentSize，包含当前驻留页语义，与 Footprint 不同。 - Virtual Memory：描述虚拟地址空间映射，数百 GiB 不代表实际消耗同等物理 RAM。
- Available / Free：是设备级环境指标；Free 只是完全空闲页，不等于 Available。
2. 三类常见内存波形：先识别形态，再升级证据
Physical Footprint 的时间趋势可以帮助识别异常形态，但曲线本身不能证明对象持有关系，也不能单独证明 Jetsam 原因。
| 观察到的形态 | 候选方向 | 还需要什么证据 | 不能直接下的结论 |
|---|---|---|---|
| 重复操作后阶梯式增长 | 生命周期未结束的资源、强引用环、缓存策略等 | Allocations / Memory Graph / 引用链；重复实验能否稳定复现 | 不能只凭曲线宣布“已确诊泄漏” |
| 短时间明显峰值 | 大图解码、大文件一次性加载、批量对象创建等 | 业务输入规模、调用栈、Available Memory 与系统终止证据 | 不能把某个 MB 数字写成所有设备的 Jetsam 红线 |
| 长时间持续抬升 | 缓存容量策略、后台资源生命周期、持续输入等 | 缓存命中收益、容量/成本策略、内存警告处理与长稳复测 | 不能仅凭上升趋势认定具体容器或代码实现错误 |
3. 可复现的内存增长测试模板
一次页面进出很容易被首次加载、图片缓存、字体缓存或网络会话池影响，因此回归测试应采用重复循环 + 稳定点比较，但循环次数、停留时间和沉降时间必须由业务场景和历史数据决定，而不是写成 iOS 通用常数。
3.1 推荐执行步骤
- 预热：至少完成一次完整业务操作，让首次初始化、资源加载和必要缓存建立起来；是否剔除更多预热轮次，应由曲线是否进入稳定状态决定。
- 建立基线：回到可重复的同一页面或状态，等待到业务活动基本结束，记录 Physical Footprint、Real Memory 及设备 Available / Free 的基线窗口。
- 重复 N 轮：固定操作脚本并重复执行。N 应足以观察是否存在稳定斜率或阶梯增长，同时避免为了追求固定次数把测试拖入热状态或其它干扰。
- 沉降窗口：每轮或最终轮结束后给相同的业务沉降条件，观察内存是否回到历史分布附近。沉降时间应由该场景的异步任务、图片解码和缓存回收特性确定。
- 证据升级：如果多轮都出现稳定增长斜率，再用 Allocations、Memory Graph、引用链或代码级证据确认对象为什么没有释放。
3.2 结果怎样判定
不要使用固定 5 MB / 15 MB 作为所有 App 的泄漏线。更可靠的比较对象包括：
- 相同设备、iOS、构建类型和业务脚本下的历史 P50 / P95 与最终稳定点；
- 每一轮结束后的增量是否持续同方向增长，以及增长斜率能否在独立重复实验中复现；
- 峰值之后能否在相同沉降条件下回到历史分布；
- 同窗 Available / Free、Thermal 与业务输入规模是否发生变化；
- 是否存在 Allocations / Memory Graph / Jetsam 日志等更高层证据。
可以记录 DeltaMemory = M_end - M_baseline 作为项目回归量，但它只有在测试条件和沉降条件固定时才可比较；正式 SLA 应来自项目自己的历史分布与事故数据，并注明适用设备、系统和场景。
4. 不使用固定机型 OOM 红线
Perfowl 不提供按“3/4/6/8 GB RAM”硬编码的通用 Jetsam 阈值表。真实限制会受到系统版本、设备状态、进程优先级、 entitlement / 场景与动态内存压力影响；把一个经验 MB 数字写成“强杀红线”会制造错误结论。
更可靠的回归方法是：在同设备、同系统、同操作场景下比较 Memory / Real / Virtual 的趋势，并同时记录 Available / Free 与最终 Jetsam .ips 证据。团队如果有自己的产品基线，应来自本产品的历史分布和事故数据，而不是当作苹果固定阈值。
5. Bug 提单示例：把观察、候选与确认分开
下面只是证据结构示例，不提供通用数字阈值：
【性能异常】商品详情页重复进出后 Physical Footprint 出现可复现阶梯增长
- 被测条件：设备 A / 固定 iOS / Release / 同一业务脚本
- 历史基线：同条件稳定版本的 P50 / P95 与沉降后分布
- 实测表现：多轮重复后最终稳定点持续高于历史分布，且每轮增量方向一致
- 同窗环境：记录 Available / Free、Thermal、业务输入规模与网络状态
- 当前结论：内存持续增长候选；仅凭 Perfowl 曲线不写“已确诊泄漏”
- 证据升级：使用 Allocations / Memory Graph 或引用链确认未释放对象与持有关系
- 附件：Perfowl Session、关键时间窗截图、代码级证据