内存预算与 Memory Profiling 方法

问题：怎样证明掌握的是官方单元 5，而不是记住几个工具名？

先预测：如果只看到最终帧率或一张截图，不知道设备、构建、场景、输入和采样方式，能否判断修改真的有效？不能。性能结果是测试上下文与程序行为共同产生的，脱离上下文的数字既不能复现，也不能指导下一步。

内存分析不能从找泄漏开始，而要先把物理RAM、操作系统保留、其他进程、图形内存和安全余量转成项目预算，再按团队和资源类别分配所有权。快照用于解释预算由谁消费。

官方目录边界

本页严格对应Unity Technologies的《Ultimate guide to profiling Unity games (Unity 6 edition)》第39—44页。以下目录项必须在实现、实验或证据中出现：

• Understand and define a memory budget
• Determine physical RAM limits
• Determine the lowest specification to support for each target platform
• Consider per-team budgets for larger teams
• In-depth analysis with the Memory Profiler package
• A few tips to keep in mind when memory profiling

本站以中文重新组织解释、代码和实验，不逐字复制原文。API示例以Unity 6思路为准；具体包版本和目标平台能力仍要在项目清单中固定。

核心模型与不可变条件

内存分析不能从找泄漏开始，而要先把物理RAM、操作系统保留、其他进程、图形内存和安全余量转成项目预算，再按团队和资源类别分配所有权。快照用于解释预算由谁消费。

本单元的不可变条件是：峰值常驻内存必须低于最低目标设备预算，并能按系统、资源类别和团队追溯；场景退出后的预期释放要通过稳定点快照证明。 只要输入条件、观测边界或结果合同有一项改变，就不能把两次测量直接相减。先解释变化来源，再决定是否建立新的基线。

五个必须落到证据的术语

它在本单元中不是孤立名词，而要落到“物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因”的数据链，并能由一次保存的采样或状态记录验证。

它在本单元中不是孤立名词，而要落到“物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因”的数据链，并能由一次保存的采样或状态记录验证。

它在本单元中不是孤立名词，而要落到“物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因”的数据链，并能由一次保存的采样或状态记录验证。

它在本单元中不是孤立名词，而要落到“物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因”的数据链，并能由一次保存的采样或状态记录验证。

它在本单元中不是孤立名词，而要落到“物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因”的数据链，并能由一次保存的采样或状态记录验证。

从输入到结论的诊断链

主链为：物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因。每个节点保存构建提交、设备ID、场景检查点、帧号或快照ID、当前预算、实际值和首个异常。下一节点只消费上一节点已验证的事实，不能用“感觉更流畅”跨过中间归因。

1. Understand and define a memory budget

物理RAM不是应用可独占空间。操作系统、驱动、后台服务和平台保留都会占用内存，某些平台还让CPU与GPU共享内存。预算应来自最低目标硬件实测和平台要求。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

2. Determine physical RAM limits

最低支持规格决定硬上限；高端设备只用于验证扩展质量。若最低设备无法容纳核心场景，就要调整资源规模、流式策略或支持范围，而不是把崩溃风险留到发布。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

3. Determine the lowest specification to support for each target platform

大团队需要按纹理、网格、音频、动画、托管堆、原生系统和缓冲区分账。每个账户有负责人、警戒线和峰值场景，防止所有团队都默认余量属于自己。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

4. Consider per-team budgets for larger teams

Memory Profiler快照会暂停并产生额外开销，采集点要可重复。进入场景、完成预热、等待异步加载和必要GC后再取稳定快照，并记录场景状态。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

5. In-depth analysis with the Memory Profiler package

比较快照时先确认总量，再按Native、Managed、Graphics和Unknown等类别下钻。实例数量增长、引用链和资源大小共同解释原因，单个差值不能直接证明泄漏。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

6. A few tips to keep in mind when memory profiling

峰值和稳态是不同合同。加载过渡可能允许短暂峰值，但不能越过平台杀进程线；稳态必须保留足够余量应对内容变化和系统波动。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

7. Understand and define a memory budget

预算门应进入内容导入、场景验收和发布候选流程。资源新增后自动更新分类账，超额必须由责任人解释并给出回收、压缩、流式或预算调整依据。

复现时把这一项写成“输入条件—观测位置—判断阈值—下一动作”四列记录。输入条件决定数据是否可比，观测位置说明要看哪个线程、模块、对象或平台计数器；阈值来自本项目预算，下一动作必须能指向一次单变量实验。

三步复现与分步观察

可执行实现骨架

下面的代码只承担本单元的数据所有权或测量边界。真正项目应把阈值放入版本化配置，并让证据文件引用同一个配置哈希。

public sealed record MemoryBudget(
    long ProcessLimit, long OsReserve, long SafetyMargin,
    long Textures, long Meshes, long Audio, long Managed);
 
public static long ProjectBudget(MemoryBudget b) =>
    b.ProcessLimit - b.OsReserve - b.SafetyMargin;
 
public static bool Balanced(MemoryBudget b) =>
    b.Textures + b.Meshes + b.Audio + b.Managed <= ProjectBudget(b);

每次采集都保存结构化元数据，避免报告与原始文件失联：

{
  "chapter": "prof-05-memory-budget-profiling",
  "officialPages": "第39—44页",
  "chain": [
    "物理上限",
    "平台余量",
    "项目预算",
    "团队分账",
    "稳定快照",
    "超额归因"
  ],
  "device": "target-low-tier-01",
  "build": "commit-and-unity-version",
  "scenario": "fixed-checkpoint",
  "baseline": "capture-before.data",
  "candidate": "capture-after.data",
  "normal": true,
  "boundary": true,
  "failureReplay": true
}

自动门输出必须同时保留通过值和拒绝原因，而不是只给一个绿色图标：

PASS context=device+build+scene+quality+input
PASS chain=物理上限 -> 平台余量 -> 项目预算 -> 团队分账 -> 稳定快照 -> 超额归因
PASS invariant=峰值常驻内存必须低于最低目标设备预算，并能按系统、资源类别和团队追溯；场景退出后的预期释放要通过稳定点快照证明。
REJECT missing-raw-data | changed-context | hidden-quality-loss | unreplayed-failure

两个必须主动制造的失败样本

证据矩阵与签发标准

练习：把官方单元 5变成可审计交付

小结

• 是否能逐项指出本页覆盖的官方目录项，而没有用通用性能建议替代？
• 是否沿“物理上限 → 平台余量 → 项目预算 → 团队分账 → 稳定快照 → 超额归因”保存了可追溯中间证据？
• 是否区分定位工具的干扰与发布构建的真实预算？
• 是否主动制造失败，并在相同输入下证明修复没有转移成本？

术语表

来源与改编边界