《游戏引擎实现原理》工程与实战 目录

目录

欢迎来到《游戏引擎实现原理》卷四《工程与实战》——全套四卷的收官卷。

卷一《引擎内核》里，我们写出了一个能跑的 helio 内核：内存、句柄、容器、数学、数据导向、ECS、任务系统、反射与序列化。卷二《渲染引擎》里，我们给内核接上了 RHI 三后端与一整套渲染器，《微光岛》的小岛第一次被画到屏幕上。卷三《子系统与工具》里，我们让这个世界活了起来：资源管线与流式、动画与蒙皮、物理、音频、输入、脚本绑定，以及一个能编辑、能撤销、能存盘的最小编辑器。

但一个引擎「能跑」和「能交付」之间，还隔着很远的一段路：包体能不能压下去、首包能不能瘦下来、引擎自己有没有测试、帧预算超了怎么定位、低端设备上怎么降级、用不到的功能能不能裁掉、线上出了问题怎么查、最后怎么把游戏真正发出去。这一卷就干这些事。

为什么把这些放进同一卷？因为它们共享同一条工程规律：引擎的每一项能力，最终都要落在可测量的数字与可复现的命令上。 构建产物是字节数，测试是像素差与哈希，性能是分位数与 GC 次数，降级是能力位与档位表，裁剪是裁剪前后的体积差，调试是能回放的日志与快照。把这些讲透，你拿到的不是十个互不相干的操作手册，而是一套「怎么证明一个引擎真的能用」的工程方法。

市面上讲引擎工程的书，大多停在「配一下打包工具、开个性能面板」。本卷走另一条路：每一节都写代码，每一节的代码都在本机真跑过，跑出来的是真实产物——真实字节数、真实耗时、真实像素、真实哈希。 凡是给出「这样更好」的结论，背后都有一份能复现的测量；凡是命令行里做不到的事，正文会明确标注「需手动验证」。

这一卷写给谁

前置知识：读完前三卷，或至少了解句柄、ECS、RHI 与资源管线的基本概念；会写 TypeScript。不需要安装任何游戏引擎——本卷全部代码在 Node 26 与 headless Chromium 下运行。

三类读者，三类收获

下面把这四类人分别展开，你可以对照自己的处境挑一段读——它决定了你该走哪条阅读路径。

如果你读完了前三卷。 你手里有一个能跑的引擎和一个能玩的小岛，但它从来没有被打包分析过、没有一条自动化测试、没有一个帧预算表、没有在低端档位上验证过。这一卷正是补上这最后一段：第 1–3 章建立构建、测试与性能三根支柱，第 4–6 章处理适配与裁剪，第 7–8 章把《微光岛》真正做完并交付。读完你得到的不是一个 demo，而是一个有验收标准的工程。

如果你正在自研引擎。 你大概不缺功能，缺的是「怎么判断现在算不算及格」。这一卷给出的都是可执行的判据：黄金图像比对用逐像素差值加容差，确定性回放用状态哈希与首次分叉帧，性能用 p50 / p95 / p99 加 GC 次数，裁剪用体积差，上线用可勾选清单。这些判据都能在你自己的项目里原样搬过去。

如果你做前端或工具链。 你熟悉 webpack / vite 的产物分析、熟悉 Chrome DevTools 的 Performance 面板，但游戏引擎多出几层约束：一帧要同时压 CPU 与 GPU、GPU 侧拿不到精确计时、低端设备要能降级、用不到的特性必须从包里消失。这一卷把这些约束一条条落到代码上，让你看到「游戏引擎的工程化」比 Web 应用多做了哪些事。

如果你想横向了解引擎。 第 9 章用三条坐标轴把 helio 与 Godot、Bevy、Defold 摆在一起：内存里组件怎么排、一帧步序由谁定、句柄失效能否检测。同一条轴上的取舍差异，比任何「引擎排行榜」都更能说明一个引擎的性格。第 10 章则把四卷 60 章串成一张「一个引擎由哪些原理构成」的全景图。

与前三卷的关系

四卷不是「四本并列的书」，而是**「地基 / 楼 / 生活 / 交付」**。卷四里的每一项工作，几乎都能在前三卷里找到它要检验的那根桩：

四卷之间的接缝只有一句话：内核产出「数据 + 句柄」，渲染把数据变成像素，子系统让数据动起来并把数据暴露给工具，工程化让这一切可测量、可复现、可交付。 这条缝越清晰，四层越能各自演进——所以卷四做工程化时，前三卷的代码一行都不用改。

还没读前三卷的读者，建议先去卷一目录 、卷二目录 与卷三目录 过一遍；至少读完卷一第 1 章（分层）、第 4 章（内存布局）、第 10 章（确定性），卷二第 1 章（一帧发生了什么）、第 3 章（命令与队列）与第 5.3 章（NullRHI），再回来看卷四会轻松很多。

本卷的差异化

和「讲打包配置」或「讲某个引擎的工程实践」的书比，本卷有三条很硬的不同：

• 从零实现，不调框架。 我们不接现成的性能监控 SDK、测试框架封装或部署平台 CLI，而是自己写模块依赖扫描器、产物分析器、纹理管线、黄金图像比对器、帧剖析器、分配追踪器、能力探测与档位决策、依赖方向检查器、特性裁剪脚本、控制台与遥测。你看到的是「引擎作者怎么做工程化」，不是「怎么用某个工具」。
• 每节可跑出真实产物。 每一节都产出一份能在本机运行、能读到数字的东西：一份逐模块的字节构成、一张逐像素比对的差异图、一份帧时间分位数、一次裁剪前后的体积对照、一段可回放的确定性哈希序列、一张能力探测表。结论不是「理论上会更快」，而是「本机实测快了这么多」。
• 真实字节、耗时与像素。 凡是给出「这样更好」的结论，背后都有一份真实测量。看到数字时，请连着它的测量条件一起看，而不是只记那个倍数。

本卷的可运行性口径

本套书的每一节都标注它属于哪一层，你据此知道「这一节的东西能不能在你机器上跑起来」：

这五层各自意味着什么，值得展开说清楚：

• L1——能真跑。 模块依赖图、产物分析与 tree-shaking 判据、纹理压缩与 PSNR、分包与体积统计、假对象与内核单测、确定性回放与状态哈希、帧剖析与分位数、分配追踪与对象池、能力探测与档位决策、依赖方向检查、特性裁剪、控制台命令解析、遥测与断言分级、预算表判定、产物清单校验——这些都是纯 TypeScript，node src/xxx.ts 就能跑，配 vitest 就能断言。你看到的每一段 L1 代码，都是在本机跑过、被单测盯过的。
• L2——需要 GPU / 浏览器。 凡是碰 GPU 或浏览器的代码——黄金图像渲染、调试绘制、玩法与表现的像素核对、GPU 计时——都得靠 headless Chromium 跑起来验证。本卷会给出统一的跑法，让你在本机也能复现每一张图与每一组像素。
• L3——只能类型检查。 桌面打包配置、部分平台胶水与托管脚本依赖只在真实工程里存在的形状，能通过 tsc --noEmit 或结构校验但无法直接执行。这类代码会被明确标注，正文会说明「为什么它跑不了」。
• L4——命令行不可复现。 涉及真实硬件、真实平台或真实网络的行为（真机帧率与发热、真实 GPU 驱动的数值差异、平台 SDK 打包与签名、CDN 上传与缓存头、真实浏览器里的黄金图像基线）命令行里复现不了。正文会标「需手动验证」，并给出你该观察什么。
• B——性能基准。 凡是给出「快了 N 倍」的结论，背后都有一份 B 级基准：它跑出计时 JSON，原始数字写进对照表。看到 B 级结论时，请连着原始数据一起看。

卷四的 L4 占比是全套书里最高的一卷：跨端与降级（第 4 章）、构建与部署（第 8.2 节）、上线清单（第 8.3 节）里有相当一部分只能手动验证。这不是偷懒——引擎工程化的最后一公里本来就在真实设备上。本卷的处理方式是：把能自动化的部分全部抽成可跑的 L1 / L2（能力探测逻辑、档位决策表、产物清单与校验、检查清单的自动项），把剩下的部分明确标成 L4 并写清「该看什么」。

贯穿项目：《微光岛》从「能跑」到「能交付」

前三卷里，《微光岛》从「一个能走动的方块」长成了一个能跑、能画、能交互的小岛。这一卷要做的，是把它交付出去：

范围红线：《微光岛》是引擎的垂直切片测试床，不是可发行产品。范围钉死在「一个小岛场景 + 少量机制」，产出截图 / 回放 / 构建产物即验收，避免在 180 篇之外再压一座内容山。

关于基准数字的诚实声明

本卷会出现不少性能数字——包体字节、压缩比与 PSNR、帧时间分位数、GC 次数与停顿、提交吞吐、裁剪前后的体积差。它们都来自作者本机实测，并附带测量条件。但它们有一个必须说清楚的边界：

这些数字是同机相对量级，绝对数值不可移植。 Node 版本、CPU 调频、后台负载都会影响结果；同一段代码，换个并发上限、换个批处理粒度，耗时可能差出一截。本卷正文里出现的几处实测就明确标了抖动区间（例如同一个小场景的池化收益在不同重跑中会摆动），我们没有挑好看的那一次。

真正稳定的结论是那些量级差异，比如「朴素分配在放大工作集后 GC 次数从个位数涨到近千次，而对象池仍是个位数」——这种结论不会因为环境微调而翻转。本卷会刻意把「方向性结论」和「具体倍数」分开表述：前者你可以直接采信，后者请当作「作者机器上的参考值」，并鼓励你在自己的机器上复现一遍。

四条阅读路径

本卷 10 章 29 节，一次读完大约 3 周（每天一小时），但不是每个人都该按同一种顺序读。下面四条路径覆盖了绝大多数人的需求。

路径 A：系统通读（约 3 周）

最完整的一条。按顺序走完 10 章，每章的代码都亲手敲一遍。

第 1–3 章（构建、测试、性能）→ 第 4–6 章（跨端、裁剪、调试）
→ 第 7–8 章（综合项目与交付）→ 第 9–10 章（对照与收官）

适合谁：想把 helio 与《微光岛》真正做完、或打算把这一套工程方法搬到自己项目里的读者。第 8 章会把前面所有零件收敛成一份可执行的上线清单，不要跳过。

路径 B：只关心交付（第 1、7、8 章，约 1 周）

已经有能跑的引擎与能玩的游戏，只想把它发出去：

1.1 → 1.2 → 1.3 → 7.1 → 7.2 → 7.3 → 8.1 → 8.2 → 8.3

适合谁：时间有限、目标是「让游戏上线」的读者。这条路径把构建、内容收口与交付串成一条自洽的线。建议至少把第 8.1 节（性能预算达标）完整读——它决定了你是「感觉还行」还是「知道哪里不行」。

路径 C：只关心适配与裁剪（第 4–6 章，约 1 周）

已经有包体与性能意识，想知道「怎么让引擎在别人的机器上也能跑」：

4.1 → 4.2 → 4.3 → 5.1 → 5.2 → 5.3 → 6.1 → 6.2 → 6.3

适合谁：要做跨端或想把引擎做小的读者。这条路径最独立，但会牺牲「构建与性能测量」的铺垫。建议把 3.1 帧预算与性能剖析 当作前置先读，它给了「什么样的数字才算达标」的全貌。

路径 D：按问题查（随时）

不打算通读，只在遇到具体问题时翻对应章节。

包太大不知道大在哪 → 1.1；贴图太占体积 → 1.2；首包太慢 → 1.3
引擎没人测、改了就崩 → 2.1；画面悄悄变了没人发现 → 2.2；偶发 bug 复现不了 → 2.3
帧时间超了不知道超在哪 → 3.1；卡顿来自 GC → 3.2；GPU 侧不知道慢在哪 → 3.3
低端机跑不动 → 4.1 / 4.2；想上桌面 → 4.3
模块互相 import 乱成一团 → 5.1；用不到的功能也进包 → 5.2；插件版本对不上 → 5.3
看不见碰撞体在哪 → 6.1；调参要改代码重跑 → 6.2；线上报错查不到现场 → 6.3
玩法接不起来 → 7.1；关卡数据管不住 → 7.2；手感差一口气 → 7.3
不知道算不算达标 → 8.1；发不出去 → 8.2；上线前不知道还差什么 → 8.3
想知道别的引擎怎么做 → 9.1 / 9.2；该不该自研 → 9.3

适合谁：已经有一个能跑的游戏、正被某个具体问题卡住的读者。下节「常见问题速查」就是为这条路准备的——它把「你想解决的问题」直接映射到「去看哪一节」。

29 节完整索引

下面把 29 节按四个部分分组，每节链到它的正文。想跳读时，从这里直接进。

第一部分：工程化的三根支柱（第 1–3 章）

让引擎「包得住、测得准、量得清」——从构建与资产管线起步，经引擎自己的测试，最后落到性能工程。

第二部分：适配、裁剪与调试（第 4–6 章）

让引擎「上得了别人的机器、丢得掉不要的部分、查得出线上的问题」——跨端降级、模块化裁剪、调试工具。

第三部分：把《微光岛》做完（第 7–8 章）

让《微光岛》「玩得起来、发得出去」——玩法装配与内容管线、性能预算达标与构建部署。

第四部分：对照与收官（第 9–10 章）

让这套书「接得上别人、走得下去」——跨引擎对照、选型判断与全书回顾。

周计划表

按路径 A 的顺序通读，可以照下面这张表安排节奏（每天约一小时）：

如果只有零散时间，可以只挑第 1 章（构建与资产管线）或第 4–5 章（跨端与裁剪）这两段——它们各自成篇，是整卷最容易被单独拿走的两块。

常见问题速查

怎么用这份索引

• 想系统学：走路径 A，从第 1 章 1.1 开始。
• 想把游戏发出去：走路径 B，从第 1 章 1.1 跳到第 7 章 7.1 。
• 想做跨端与裁剪：走路径 C，从第 4 章 4.1 开始。
• 想查问题：直接用上面的「常见问题速查」，或跳到对应小节。
• 想配代码：每一节的代码块都标了层级与来源文件，L1 的可以直接复制出来在 Node 26 上跑，L2 的按正文给的 headless Chromium 跑法复现。
• 每篇正文末行都有「上一节 / 下一节」导航，也可以随时回到本页或卷索引 。

相关阅读

• 卷一《引擎内核》目录 ：本卷的地基，从零写引擎内核
• 卷二《渲染引擎》目录 ：本卷的画面来源，从零接出渲染引擎
• 卷三《子系统与工具》目录 ：本卷的内容来源，让世界活起来并做编辑器
• 游戏引擎专题导航 ：Unity、Unreal 与 Defold 的选型与入门
• 图形学专题 ：渲染管线、着色器与 GPU 的深度文章
• TypeScript 专题 ：语言与工程实践
• 书稿书架 ：全部电子书与创作手记