导言：把优化变成贯穿开发周期的工程合同

问题：怎样证明掌握的是官方单元 1，而不是背下一组技巧？

先预测：若只报告修改后FPS，没有设备、构建、场景、输入、热状态和画面合同，另一位开发者能否证明收益来自这次修改？不能。跨平台优化首先是受控实验，其次才是技巧选择。

官方导言把优化定义为贯穿开发生命周期的工程活动：先确定体验目标和设备边界，再持续测量；只有收益大于实现复杂度、维护成本和回归风险时，修改才值得进入产品。

导言的决策模型

1. 从体验目标反推预算

先写出交互响应、画面稳定、加载与舒适度目标，再按目标刷新率把一帧拆成 CPU、GPU 和系统余量；内存、包体、热量也要有最低规格设备可验证的上限。

2. 在开发周期内持续优化

原型期验证架构和平台风险，制作期把预算分配给系统与内容，集成期处理长尾和组合效应，发布后用真实设备遥测监控回归。优化不是末期的一次清扫。

3. 先测量再选择动作

Unity Profiler、Profile Analyzer、Memory Profiler、Frame Debugger 和平台工具回答不同问题。先定位首个越界节点，再选择最小修改，不能由工具名称或技巧热度替代归因。

4. 把复杂度作为成本

对象池、缓存、平台分支和多套质量资产都可能改善数字，也会增加状态、测试组合和维护责任。收益报告必须同时列出新增代码、所有者、失效模式和回滚路径。

5. 用失败样本保护结论

每个门至少保存正常、预算边界和主动失败三组数据。若故意改变设备热状态、画质或玩法输入后仍被判为可比，说明实验协议本身不可信。

6. 让预算成为团队合同

资产导入、代码、渲染、UI、音频、物理和发布各有责任人；自动检查拒绝超限内容，目标机回放负责证明局部收益没有把成本转移到别处。

7. 以可复验签发收尾

候选构建必须恢复同一设备、场景、输入、画质和热状态，保存原始采样与视觉行为对照。另一位开发者能独立复现，结论才进入发布门。

官方目录边界

本页严格对应Unity Technologies《Optimize your game performance for mobile, XR, and the web in Unity》Unity 6版第8页导言。以下目录项必须进入实现或证据：

• Introduction
• Optimize throughout development
• Balance performance gains against complexity and maintenance cost
• Profile before choosing an optimization

本站重新组织中文讲解、代码和实验，不逐字复制原文。平台API和包能力随Unity与设备版本变化，实际项目要固定版本并保存迁移差异。

核心模型与不可变条件

官方导言把优化定义为贯穿开发生命周期的工程活动：先确定体验目标和设备边界，再持续测量；只有收益大于实现复杂度、维护成本和回归风险时，修改才值得进入产品。

不可变条件是：优化目标、设备矩阵、帧与内存预算、同输入基线、复杂度成本和回归合同必须在开发早期建立并持续更新。 如果测试上下文、视觉或玩法结果发生变化，就不能把两次数字直接相减。先解释变化，再决定是否建立新基线。

五个必须落到证据的术语

它必须落到“体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发”的证据链，不能只作为术语记忆。

它必须落到“体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发”的证据链，不能只作为术语记忆。

它必须落到“体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发”的证据链，不能只作为术语记忆。

它必须落到“体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发”的证据链，不能只作为术语记忆。

它必须落到“体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发”的证据链，不能只作为术语记忆。

从输入到发布的证据链

主链为：体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发。每个节点保存平台、设备、浏览器或运行时、Unity与包版本、构建提交、场景检查点、预算、实际值和首个异常。后一节点只消费前一节点已验证事实。

1. 全书结构

前四个单元建立URP、测量、内存与热适应基础；中段按生产系统展开；末段处理Web发布、浏览器分析和XR立体渲染。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

2. 通用与专项

纹理、代码、UI和物理建议可跨平台复用，但阈值与收益取决于硬件；Web与XR单元补充浏览器和头显特有合同。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

3. 目标设备

编辑器只用于快速定位。最低规格证明可用性，最高规格验证增强质量，中间代表档用于默认设置与市场覆盖。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

4. 优化成本

官方导言提醒许多优化会增加复杂度、维护和缺陷风险；每项收益都要和劳动成本、回归面一起签发。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

5. 证据顺序

先定义预算并建立基线，再定位首个瓶颈；不能从技巧列表随机挑选修改，也不能用最终FPS替代中间归因。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

6. 内容所有权

资产导入、运行时代码、渲染、UI和物理分别有责任人和自动检查，避免优化只存在于个人经验。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

7. 最终交付

每个官方单元都要有正常、边界和失败样本，最终在移动、Web和XR至少各一个代表目标上完成同协议回放。

复现这一项时，记录输入条件、观测工具、预算阈值和下一动作。输入决定数据是否可比，工具说明在哪个线程、对象、资源或平台阶段观察；阈值来自本项目合同，下一动作必须是一轮可反证的单变量实验。

三步复现与分步观察

可执行实现骨架

public readonly record struct CrossPlatformEvidence(
    string Platform, string Device, string Build, string Scenario,
    double CpuMs, double GpuMs, long MemoryBytes,
    string VisualHash, bool FailureReplay);
 
bool CanShip(CrossPlatformEvidence e, double frameBudget, long memoryBudget) =>
    Math.Max(e.CpuMs, e.GpuMs) <= frameBudget &&
    e.MemoryBytes <= memoryBudget && e.FailureReplay;

每份采集都保存结构化上下文，报告与原始文件必须通过ID互相引用：

{
  "chapter": "mxrw-01-introduction",
  "officialPages": "第8页导言",
  "chain": [
    "体验目标",
    "设备矩阵",
    "性能预算",
    "基线采样",
    "单变量修改",
    "回归签发"
  ],
  "platform": "mobile-web-or-xr",
  "device": "representative-target",
  "build": "commit-unity-packages",
  "scenario": "fixed-checkpoint",
  "normal": true,
  "boundary": true,
  "failureReplay": true
}

自动门必须保留数值、结果合同和拒绝原因：

PASS context=platform+device+build+scene+quality+input
PASS chain=体验目标 -> 设备矩阵 -> 性能预算 -> 基线采样 -> 单变量修改 -> 回归签发
PASS invariant=优化目标、设备矩阵、帧与内存预算、同输入基线、复杂度成本和回归合同必须在开发早期建立并持续更新。
REJECT changed-context | hidden-quality-loss | shifted-cost | missing-failure-replay

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

证据矩阵与签发标准

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

小结

• 是否逐项覆盖本页官方目录，而没有用通用建议替代？
• 是否沿“体验目标 → 设备矩阵 → 性能预算 → 基线采样 → 单变量修改 → 回归签发”保存可追溯中间证据？
• 是否在真实移动、浏览器或XR目标中验证，而非只看Editor？
• 是否主动制造失败，并证明优化没有转移成本或破坏结果？

术语表

来源与改编边界