前言（Preface）

先建立整书边界、读者假设与证据规则，再进入17章的引擎系统分解。完整覆盖1个权威目录坐标，并用依赖图、预算实验和证据轨迹复核。

为什么局部代码正确仍会造成整机失败

前言（Preface）承担 先建立整书边界、读者假设与证据规则，再进入17章的引擎系统分解。 本课程依据 Jason Gregory 的《Game Engine Architecture》第3版独立重构，不复制原书正文、图示或代码。页面逐项覆盖1个目录坐标：Preface。

游戏引擎是跨线程、跨时间域、跨处理器和跨工具链的实时系统。一个模块的单元测试通过，不代表它在整机里拥有正确的数据、在正确的时刻运行，也不代表它没有把等待、分配或带宽压力转移给下游。因此每节都同时回答五件事：输入从哪来，谁拥有状态，更新何时发生，成本落在哪里，失败如何被观察。

版次、目录与改编合同

本路径采用 Jason Gregory, Game Engine Architecture, Third Edition, A K Peters/CRC Press, 2019, ISBN 9781138035454, eBook ISBN 9781315267845。作者官网完整列出前言、5部、17章、107个编号小节、参考文献和索引，共132个正式目录节点；出版社页面确认第3版、2019年版权、1240页以及本版新增并发编程章。课程以20个正式单元逐项覆盖，另设学习地图与全书复核，共22页。

目录标题用于定位，公式、代码、图解、实验和练习均为独立教学重构。硬件性能、引擎产品和 API 会演进，所以实验必须记录目标平台、版本、构建配置和数据集；涉及真实产品时，以当前厂商文档和目标机测量覆盖示例中的历史实现。

五个贯穿全书的工程术语

、、、、。

帧预算约束最终体验，关键路径解释为什么线程都很忙仍然掉帧；资源身份让离线资产与运行时对象可以追踪；生命周期阻止半初始化和悬空状态；可观测性则决定问题能否从目标设备带回开发环境。五者必须一起使用，不能用单一平均耗时替代架构判断。

四个可复算的架构指标

一帧端到端时间由 CPU/GPU 主路径、同步和等待共同决定：

T_{frame} = max(T_{cpu}, T_{gpu}) + T_{sync} + T_{wait}

模块占用相对目标预算的比例为：

U_i = T_i / B_{frame}

并行任务的近似成本必须包含串行工作和同步：

P = W_{serial} + W_{parallel}/k + C_{sync}

证据覆盖率只计算能由轨迹、快照或可复现实验核验的关键主张：

E = N_{verified} / N_{material}

这些式子不是用平均数粉饰波动。应同时报告中位数、P95/P99、内存峰值、资源缺失、视觉或听觉质量以及输入到呈现延迟；当 CPU 与 GPU 流水重叠时，不能简单相加各模块耗时。

权威目录逐节坐标

Preface

目录节点 1/1。 前言说明本书以工业级游戏引擎为观察对象，把数学、硬件、工具、运行时和玩法系统放进同一张工程地图，并要求读者沿引用继续验证。

处理“Preface”时，先声明输入、输出、所有权、线程、生命周期、时间域和预算，再沿“确认版次 → 识别五部 → 建立系统边界 → 约定实验记录 → 规划迁移项目”追踪正常路径。重点检查版次合同：数据在哪里产生、由谁改变、何时可见、失败后怎样回收。只有接口名称而没有状态转换、成本和证据，不能算理解了这一目录节点。

为本节点保存一个正常轨迹、一个边界样本和一个故障样本。轨迹至少包含版本、目标平台、帧号或任务号、资源身份、线程、起止时间和最终状态；如果优化后平均值变好但尾延迟、内存峰值、画质或确定性恶化，就必须把结论缩小到真实适用条件。

最小实现骨架

struct ModuleTrace {
    const char* unit = "gea3-preface";
    uint64_t frameId;
    uint64_t resourceId;
    double beginMs;
    double endMs;
    uint32_t threadId;
    enum class State { Queued, Running, Ready, Failed } state;
};
 
bool updateModule(ModuleTrace& trace, double frameBudgetMs) {
    trace.state = ModuleTrace::State::Running;
    const double elapsed = trace.endMs - trace.beginMs;
    trace.state = elapsed <= frameBudgetMs
        ? ModuleTrace::State::Ready
        : ModuleTrace::State::Failed;
    return trace.state == ModuleTrace::State::Ready;
}

type Experiment = {
  workload: number;
  workers: number;
  syncMs: number;
  cpuMs: number;
  gpuMs: number;
};
 
function frameTime(sample: Experiment): number {
  const parallelWork = sample.workload / Math.max(1, sample.workers);
  return Math.max(sample.cpuMs + parallelWork, sample.gpuMs) + sample.syncMs;
}

{
  "unit": "gea3-preface",
  "edition": "third-2019",
  "target": "record-real-device",
  "build": "development-profiled",
  "evidence": ["timeline", "resource-snapshot", "failure-injection"]
}

代码骨架刻意不绑定某个商业引擎。迁移到 Unreal、Unity、自研引擎或主机平台时，替换采样 API 与资源句柄，但保留帧号、资源身份、线程、状态和时间区间，这些字段才是跨实现的调试合同。

本单元的验收工件

完成前言（Preface）时应提交三类工件。第一类是边界图：把确认版次、识别五部、建立系统边界、约定实验记录、规划迁移项目画成有方向的依赖图，在每条边标出数据格式、所有者、线程、时间域、失败返回和最大允许等待；图中任何“大家都能改”的状态都要改成单一写入者、消息或帧边界快照。边界图还要列出版次合同与工业语境的前置条件，防止接口在正常样例中看似成立、换到加载或关闭阶段就失效。

第二类是目标机轨迹：固定版本、构建配置、设备、场景、输入和随机种子，保存至少一次正常帧、一次P95附近帧和一次故障帧。轨迹必须能把CPU区间、GPU查询、I/O请求、资源身份、同步点和最终呈现关联起来，并附上采样开销。只截一张性能面板不能证明因果，因为看不到跨层依赖发生前的排队、缓存状态和跨帧依赖。

第三类是反例报告：主动让负载越过预算、让资源迟到、让对象在错误生命周期被访问，或让任务顺序改变，记录首个不变量破坏点。报告要说明故障是否被隔离、是否留下半更新状态、恢复路径是否泄漏资源，以及修复后怎样做同条件回归。只有正常路径、压力边界和失败恢复都能由另一位读者复算，前言（Preface）才从“读过”变成可迁移的工程能力。

先预测再运行

先写下三项预测：负载提高时哪个节点先超预算，并行度继续增加何时被同步成本抵消，缓冲缩小时哪类资源最先缺页。再运行三个实验视图；若结果与预测不同，优先检查时间域、统计口径、隐藏队列和跨帧流水，而不是修改解释迁就原判断。

本章回顾

前言（Preface）不是孤立 API 清单，而是“确认版次 → 识别五部 → 建立系统边界 → 约定实验记录 → 规划迁移项目”中的系统合同。掌握本页意味着能逐项定位1个权威目录节点，解释版次合同、工业语境、跨层依赖、证据记录、迁移路线的边界，计算帧与并行成本，复现正常和故障路径，并把结论交给目标机轨迹而非主观流畅感。