症状：点击模拟内存警告后，界面没变化，你不确定 App 有没有收到通知。
最快解法：先在 Xcode 27.2 RC 的目标模拟器上验证入口，再用日志确认回调、清理资源；真实低内存和后台终止恢复仍要靠实体 iPhone 验收。
维护图片、媒体或大型数据缓存的 iOS 独立开发者，可用本文核对警告后的清理行为。
正在测试 Xcode 27.2 RC 的开发者，可判断模拟入口能否承担当前验收任务。
负责远程 Mac 或构建环境的开发者，可据此划清远程执行、模拟器测试与实体设备验证的边界。
最后更新于 2026 年 10 月 28 日；版本与功能状态核对自 Apple Xcode 发布记录、Xcode 系统要求及 Xcode 27.2 RC 发布说明。
Xcode 27.2 RC iOS 内存警告测试，入口有效才算开始
截至 2026 年 10 月 28 日，Apple 的系统要求页面列出 Xcode 27.2 RC：需要 macOS Tahoe 26.6 或更新版本，包含 iOS 27.2 SDK，Swift 编译器为 6.4。Apple 的发布记录将 RC 标为 2026 年 10 月 19 日发布；这些信息能帮助你确认测试环境版本，但不能证明某台 Mac 上的菜单操作已经成功触发 App。
在 Beta 2 发布说明中，Apple 曾记录 Device Hub 的 “Simulate Memory Warning” 菜单项无法工作；RC 发布说明将该问题列为已修复。不过，版本说明不能代替你对目标环境的复测：模拟器运行时、菜单显示状态或应用日志缺一项，都可能让“点过菜单”被误记成“警告测试通过”。
Device Hub 是管理模拟设备和实体设备的入口，但它提供的模拟器操作并不等同于真实 iPhone 的内存状态。按 Apple 的 Device Hub 文档，模拟设备与实体设备都可以作为运行目标；因此，验收记录应写明测试对象，而不是只写“在 Xcode 测过”。
先按这组条件决定测试结论：
- ✅ 若菜单可见，操作后 App 记录到预期回调，且日志能对应到本次操作：将此项记为“模拟警告入口与回调已验证”。
- ⚠️ 若菜单可见，但无回调日志或状态变化：先查入口是否真正触达 App；证据不足时，不要记为通过。
- ❌ 若目标是证明实体设备真实低内存下的系统行为，或后台进程会不会被终止：模拟器结果不够，补做实体设备验收。
回调指标：怎样确认 iOS 内存警告回调已到达 App？
不要用模拟器卡顿、画面停住或菜单点击成功来代替回调证据。Apple 列出的低内存警告接收方式包括应用委托的 applicationDidReceiveMemoryWarning(_:)、活动视图控制器的 didReceiveMemoryWarning()、didReceiveMemoryWarningNotification 通知，以及内存压力 Dispatch Source；你的项目应按实际架构检查相应入口。可参阅 Apple 的低内存警告响应文档。
建议把测试操作和应用日志配成一条可追踪记录：操作前写入当前页面、任务阶段和关键数据状态；收到警告时记录统一事件标记；操作后再记录清理动作及页面响应。日志不必记录用户内容或隐私数据，重点是能分辨“按钮操作发生”“回调进入”和“清理代码运行”这几件不同的事。
如果同一清理逻辑可能从多个入口触发，避免每个回调重复执行破坏性操作。把处理收敛到可重复调用、结果可观察的清理函数，再检查界面是否仍可交互、正在执行的任务是否按产品逻辑暂停或继续。对回调做单元测试可以覆盖代码路径，但不能证明系统在真实压力下必定及时发送警告。
释放指标：收到警告后，缓存清理是否有效且可恢复？
收到警告后，应优先释放能够重建、已有磁盘副本或暂时不需要的对象，例如已显示完毕且可重新解码的图片、非当前播放所需的媒体数据，以及可重新生成的临时结果。Apple 建议尽快释放不再需要的图片、媒体和临时对象；若高内存任务仍在运行，也可按应用逻辑暂停队列或限制并行工作。
不要只看“清理函数执行了”。你还要确认清理后原页面能继续工作：图片是否可重新载入，媒体播放是否能恢复，用户输入是否保留，临时任务是否有明确的继续或取消状态。可在相同操作路径下记录警告前后的 Xcode 内存报告或内存图；没有实际测量记录，就不要声称释放了某个具体容量或达到了某个阈值。
Apple 还提醒，不要收到警告后遍历整个对象图寻找可释放对象；这种扫描本身可能增加系统内存需求。若产品依赖可丢弃、可再生成的数据，可评估 NSPurgeableData 的适用性，并确认内容访问期间的引用管理正确；不要把它与 NSCache 组合后，误以为系统会替你处理所有缓存生命周期。
| 验收对象 | 模拟器可以提供的证据 | 仍需补充的证据 |
|---|---|---|
| 菜单入口与回调 | 操作可触发、应用日志出现预期回调 | 目标设备上的实际低内存触发情况 |
| 缓存与可重建数据 | 清理代码运行、页面仍能继续使用 | 真实设备压力下的内存变化与功能稳定性 |
| 后台终止与恢复 | 可检查应用自身保存和恢复逻辑 | jetsam 诊断记录及实体设备上的恢复结果 |
终止与恢复指标：模拟警告能否复现系统后台终止？
不能。低内存警告是系统向运行中应用发出的通知；若系统内存需求仍未缓解，iOS 可能终止应用以回收内存。两者有关联，却不是同一个事件：收到警告不等于进程已被终止，模拟警告也不能证明系统在某个真实内存状态下会做出何种处置。
如果验收目标包含后台终止后的恢复，分别检查“收到警告后自行清理”和“进程被系统结束后重新启动”两条路径。前者关注缓存释放及当前页面状态，后者关注关键数据是否已持久化、重新启动后能否恢复到合理状态。一次测试中没有崩溃，并不意味着这两条路径都已通过。
需要判定是否确属内存压力终止时，查看设备诊断材料，而不是仅根据界面消失猜原因。Apple 说明，jetsam 事件报告描述系统因内存条件终止应用的情况；它与普通崩溃报告不同，报告中可检查被终止进程及原因字段。若收集到的是普通崩溃报告，不能只凭“发生在后台”就归因为内存不足。
⚠️ 若测试机器没有实体 iPhone，结论应限定为“模拟入口、回调和应用自身恢复逻辑已检查”。不要把它扩写成“真实低内存终止已通过”。
设备证据指标：没有实体 iPhone 时，还缺哪些验收材料？
把每项结论和对应证据一起归档，避免把远程桌面可访问、模拟器可启动或构建成功当成设备验收。Apple 将模拟设备用于快速评估和调试，也指出实体设备适用于依赖硬件的功能及性能调查；两者的证据范围不同。
执行时，可按下面的顺序留档：
- 记录 Xcode 版本与构建号、macOS 版本、模拟器设备和 iOS runtime；确认环境满足 Xcode 系统要求。
- 在 Device Hub 启动目标模拟器，确认应用运行后再检查内存警告菜单；菜单缺失或操作无效时，先记录现象，不用其他界面变化推断成功。
- 操作前记录页面和关键数据状态，触发模拟警告后检查应用回调日志；没有回调证据，就停止将本轮记为通过。
- 检查缓存清理、任务暂停或恢复及页面继续使用的结果；用同一条操作路径比较可观察的内存报告，不填入未测得的释放量。
- 切后台再返回，分别记录应用主动清理、状态保存和恢复结果；若验收还包括系统终止，另外收集诊断日志与 jetsam 报告。
- 有条件时在实体 iPhone 复测关键场景，将设备型号、系统版本、触发步骤、日志和恢复结果与模拟器记录分开保存。
Apple 的内存使用信息收集指南说明，模拟器的内存仪表不能单独证明应用在真实设备上处于安全范围；查看内存图或内存报告可以帮助定位分配情况，但仍要结合实际设备和目标场景解释。对于没有实体设备的团队，缺项应明确标成待验收，而不是用模拟结果填补。
若你在远程 Mac 上执行这套流程，可以先确认所用 Xcode 版本和模拟器是否实际可用，再确认测试目标是否要求连接实体设备。远程 Mac 能提供 macOS 工具链与持续运行环境，但不能凭远程桌面本身替代 iPhone 的真实内存压力证据。需要比较远程开发环境适用场景时，可先看 远程 Mac 的使用场景；若还要权衡租赁和自备设备，再核对 KVMFLUX 的方案与计费信息。像 Xcode Cloud 依赖安装排查这类构建环境问题，也应与内存警告验收分开记录。
对这项测试，关键不是“能否在远程 Mac 上点到菜单”，而是你能否留下入口、回调、资源释放和恢复各自对应的证据。若手头没有可用于 Xcode 验证的 Mac，临时租用 KVMFLUX 可省去专为 RC 测试购买 Mac 的前期投入，也便于保留独立的 macOS 测试环境；但若验收必须连接实体 iPhone，租赁前仍需确认设备接入条件。长期、稳定的重负载环境或依赖本地物理接口的项目，则应优先评估自购 Mac 或本地设备方案。