1. Architecture, Performance, and Games
1. Architecture, Performance, and Games：在可修改性、运行性能和交付速度之间做阶段性取舍，通过可复位因果实验和反 例证据验收。
1. Architecture, Performance, and Games
学习目标
- 能说明架构与性能的阶段性取舍
- 能解释解耦如何降低改动成本
- 能用改动耗时与帧耗时两个指标验证架构决策
为什么"1. Architecture, Performance, and Games"从问题证据开始
游戏行业有个老规矩：功能先做出来，性能慢点没事，以后优化。但"以后优化"经常变成"永远没时间优化"——等到发售日临近，才发现核心玩法卡在 20fps。反过来，一上来就过度设计、追求完美架构，又会在功能需求还没定型的阶段浪费大量工期。
本页要解决的核心矛盾是：可修改性（改得快）与运行性能（跑得快）通常是冲突的。我们把"无模式基线"定义为"完全不考虑架构、想到哪写到哪"的代码，然后逐级加入解耦、模块化等候选机制，验证它们是否真的让"改需求的时间"和"跑游戏的速度"发生可观察的改变。通过条件是真实场景下的改动耗时和帧耗时同时可度量，而不是类图好看。
🔮 猜一猜：给一个耦合紧的系统加新功能，改动耗时主要花在"找"还是"改"？
来源、版本与独立重写边界
本页用作者完整在线正文核对正式标题、设计分叉和时代语境，并以作者源码仓库交叉检查结构。仓库许可证明确正文、HTML与样式为 CC BY-NC-ND 4.0，示例程序等其他文件为 MIT；因此下列中文解释、图示、交互和代码均为独立教学重写，不翻译、拼接或改写受 ND 限制的原文表达。
本章机制与术语
本章是全书的思想基础，理解四个贯穿性概念：
- ↡：程序各部分之间的关系与依赖方向。好的架构让改动只影响局部；坏的架构让一处改动波及全局。
- ↡：两个模块互相依赖的程度。高耦合 = 改一个就要改一串；解耦 = 模块只通过明确接口打交道。
- ↡：程序在给定硬件上的运行速度，核心指标是帧耗时（每帧 16ms 预算对应 60fps）。
- ↡：在开发不同阶段动态调整架构投入——原型期追求改得快，冲刺期追求跑得快。
四个概念共同约束"在可修改性、运行性能和交付速度之间做阶段性取舍"：任何架构决策都必须回到"现在改得有多快、跑得有多快、离交付还有多久"三个可观察量。
第 1 / 7 步 · ① 游戏循环在中心：每帧驱动全部系统
游戏循环是心脏：每帧按顺序驱动所有系统，各系统只负责自己的领域。
💡 对着动画看：动画把游戏拆成渲染、物理、音频、AI、输入、脚本六个系统，环绕游戏循环协同工作。注意看各系统之间的连接线——它们互相调用但不互相越权，这就是本章"解耦"思想的一张全景图。读下文"解耦能帮什么忙"时，回到这张图体会系统边界。
官方结构逐项深读
1. Architecture, Performance, and Games
本章不是模式，而是全书的地基：游戏开发最大的成本是"改动"，架构的价值就在于降低每次改动的代价。作者给出的总纲是——先追求可修改性，让游戏有趣；再优化性能，让游戏流畅。顺序不可反：一个不好玩的快游戏没有意义，一个好玩的慢游戏还有救。
What is Software Architecture?
架构不是某个类或某个模块，而是整个系统组件之间的关系网络：谁调用谁、谁依赖谁、数据往哪个方向流。它像城市规划——单栋楼（单个类）再精致，路网不通（依赖混乱）城市也会瘫痪。架构本身不产生任何游戏玩法，它只决定"你改玩法时要付出多大代价"。
What is good software architecture?
好的架构只有一个判据：它让你的改动变容易。具体表现是：要加一个新功能（比如给角色加冲刺），你能准确找到需要改的几个地方，改完不影响其他系统。反之，坏架构的判据也很简单：加一个功能要动十几个文件，还总能引入莫名其妙的新 bug。架构没有绝对优劣，只有"对当前团队和当前游戏合不合适"。
How do you make a change?
改动是一条有成本的流水线：找到要改的代码 → 理解它 → 动手改 → 测试 → 部署。好的架构压缩的是前两环——可定位性（顺着清晰的依赖快速找到目标）和可理解性（局部代码不用读懂全系统就能改）。如果你改一个功能要花三小时"找"、十分钟"改"，问题不在你，在架构。
How can decoupling help?
解耦（decoupling）是降低改动成本的核武器：两个模块之间只通过明确、狭窄的接口交互，谁也不关心对方内部怎么实现。拿动画里的六个系统举例：物理系统不知道渲染系统用什么 API，只把"物体位置更新了"这件事通过接口通知出去。这样替换任一系统（比如换音频后端）都不必碰其他系统。代价是接口设计本身要花心思，接口定错了反而更僵。
At What Cost?
解耦不是免费的：每一层抽象都增加间接性——调用要穿过更多层、调试要绕更多弯、新人要理解更多概念。过度设计（为永远不会出现的需求建抽象）比没有架构更糟：它让简单的事情变复杂。判断标准是：这个抽象现在就在帮你省改动成本吗？如果是"将来可能有用"——删掉它。
Performance and Speed
性能优化的第一原则是先测量再优化：不要凭直觉猜哪里慢，用 profiler 找出真正的热点。第二原则是优化要隔离在局部：改一个系统的内部实现，不影响它的对外接口——这样性能优化和架构维护可以并行不悖。这也是解耦的另一个好处：你可以在物理系统内部换上 SIMD 算法，而其他五个系统毫无感知。
The Good in Bad Code
"坏代码"有时是阶段性的正确选择：原型期用最直接的方式把玩法验证出来，哪怕耦合、重复、没有抽象——因为这个阶段最大风险是"游戏不好玩"，而不是"代码不好维护"。关键是要清楚自己写的是"临时坏代码"（有计划的债务）还是"以为很好但实际很烂"（无意识的债务）。前者要记账并计划偿还，后者才是灾难。
Striking a Balance
好的游戏架构是动态平衡的结果：不是"永远干净"或"永远快"，而是在正确的时间点切换优先级。玩法验证期追求可修改性（快改），性能冲刺期追求运行速度（快跑），两者通过解耦的边界互不拖累。作者把它比作"先让游戏有趣，再让它跑得快"——顺序颠倒就会两头落空。
Simplicity
简单是架构的最高美德：能用 100 行说清的事，不用 300 行加三层抽象。简单的代码可读、可改、可测；复杂的代码即使"设计精美"也难以上手。追求简单不等于不做架构，而是用最少的机制达到需要的解耦——每多一层抽象前，先问自己：少了它，改动真的会变慢吗？
Get On With It, Already
本章的落点是一句行动号召：别为了架构而架构。架构是手段不是目的，最终目的是"你的游戏能按时做完、改得动、跑得顺"。当你发现自己花了一整天重构一个"应该会用到"的抽象时，停下来问：玩家能感受到这个改动吗？不能？那它可能只是你的自我满足。
可迁移实现或计算骨架
initial state -> 记录当前改动耗时与帧耗时基线
fault injection -> 在没有解耦的代码上尝试加一个跨系统功能
pass condition -> 加入解耦边界后，同一功能改动耗时显著下降且帧耗时未恶化
reset -> initial state对应实践要点：先写一个不假思索的基线实现；记录"加功能耗时"和"帧耗时"两个数字；再引入一层解耦（如事件接口、依赖倒置），重测同一改动；若改动耗时下降而帧耗时没有明显恶化，解耦成立。该骨架只保存实验合同；真实项目还要固定团队规模、代码规模与硬件基线，并保留基线实现以便回退。
本章练习与节点验证矩阵
练习
问题 1：改动成本测量。
操作：在动画的六个系统中挑一个（如把音频换成另一种实现），估算要改动的模块数量
问题 2：性能热点实验。
操作：对同一功能先凭直觉选优化点，再对照动画各系统职责定位真实热点
问题 3：阶段取舍演练。
操作：模拟"玩法未定"与"临近发售"两种阶段，分别决定加不加某层抽象
术语复核
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 架构
- 解耦
- 阶段性取舍
练习答案参考
练习判据即答案：每个练习的"验证判据"列给出了通过标准——先自己动手，再对照判据核验。
术语复核与本章回顾
掌握"1. Architecture, Performance, and Games"意味着能从"游戏开发最大成本是改动"出发，解释架构、耦合、性能与阶段性取舍四个概念的关系，再用改动耗时与帧耗时两个可观察量推翻或保留架构决策。若"加功能变快且游戏不变慢"不能稳定复现，本章仍未通过。
一句话回顾：先让游戏有趣（快改），再让它流畅（快跑）；解耦是连接两者的桥——它让你优化性能时不必推翻架构，让架构演进时不必牺牲性能。