说到游戏引擎架构，很多人第一反应是渲染、物理、动画这些酷炫系统，但真正决定引擎上限的，往往是那层不怎么起眼的引擎基础架构。我做第一版引擎时，把渲染、资源、输入、角色逻辑全部塞进几个大类和一堆全局函数里，功能能跑，可每次加玩法都像拆积木，改一个公共头文件要重编大半个工程。后来我才意识到，问题不在具体系统的实现，而是基础架构那张「地图」没画清楚。游戏引擎架构跟盖楼一样，楼层越高越依赖地基，这篇先聚焦引擎基础架构，把模块边界、依赖方向、帧循环、数据流和性能骨架讲透，适合正在读引擎源码、或者打算自研轻量引擎的同学。
1. 引擎「地基」到底管什么：模块清单与边界
1.1 先分清层，再谈模块
引擎代码不是一堆类放在一起就能叫架构，它首先得有明确的层级。我习惯把引擎从上到下分成四层：平台抽象层、核心层、功能层、游戏层。平台抽象层负责跟操作系统打交道，包括窗口创建、输入、计时器、文件系统、图形 API 封装、线程原语；核心层提供容器、字符串、数学库、内存分配、资源管理、任务调度、日志、事件、反射等通用能力；功能层是可插拔的渲染器、物理模拟、动画系统、音频、网络、场景管理；游戏层则是那一层真正属于项目自己的玩法逻辑、角色 AI、关卡配置。
这四个层级各自的职责很不相同，但有一条共性：上层可以依赖下层，下层绝对不能依赖上层。平台抽象层不会知道「游戏里有没有子弹」，核心层也不会知道「当前跑的是不是策略游戏」。区分「核心能力」和「业务功能」时，我有一个很土但好用的判断方法：如果某个模块的代码会直接调用游戏层的类或接口，它就不是核心层，而是游戏层的一部分。很多引擎最后变成「大泥球」，就是从这一条开始被破坏的。
1.2 核心层与功能层的分界，为什么要卡这么死
有人会问：渲染器不也到处都是算法吗，为什么它不能算核心层？我的理解是，核心层强调「无业务语义的复用能力」，而功能层强调「面向特定领域的服务」。数学库、内存分配器换到任何项目都能用，渲染器则有自己的生命周期、场景图、材质模型，它的实现细节只有做渲染时才会关心。把渲染器下拉到核心层，会让核心层膨胀，而引擎一旦膨胀，所有上层模块都要跟着承受编译和依赖成本。
功能层内部也最好按可插拔标准切模块：渲染、物理、动画、音频各自独立，互不窥探内部实现。某次我在一个项目里看到物理模块被挂在场景管理模块下面，编辑器里拖动场景节点，结果物理碰撞体也被一起重建，问题很难排查。倒不是代码写错了，而是物理模块的生命周期错误地绑在了场景模块上。正确做法是，谁管理生命周期谁就拥有对象，物理模块自己要控制内部碰撞体的创建与销毁，场景模块只通过接口把「哪些节点需要参与物理」这个语义传给它。
用一张表把各层职责说清楚：
| 层级 | 主要职责 | 典型模块 | 依赖方向 |
|---|---|---|---|
| 游戏层 | 玩法、关卡、角色控制 | 角色系统、任务流程、关卡逻辑 | 依赖功能层与核心层 |
| 功能层 | 面向领域的能力服务 | 渲染、物理、动画、音频、网络 | 依赖核心层 |
| 核心层 | 通用基础设施 | 容器、数学、内存、资源、调度 | 依赖平台抽象层 |
| 平台抽象层 | 屏蔽操作系统差异 | 窗口、输入、文件、线程 | 不依赖业务代码 |
边界这件事，短期看不出好处，半年后发现某个模块能被整个挖走替换，或者一个新同事一天能定位到 bug 在哪一层，你就知道边界值多少钱了。
2. 依赖方向：谁可以调用谁，谁绝不能被谁调用
2.1 单向依赖的红线
模块划分出来后，紧接着就是依赖管理。依赖混乱比模块缺失更致命，因为它会形成循环：渲染器想播放打击音效，直接调音频模块的类；音频模块做环境模拟时又想读渲染场景里的遮挡数据，于是反过去依赖渲染模块。两个模块互相 include，增量编译越来越慢，单测链接时更是要把半个引擎拉进来。
约束依赖方向的核心就一句话：能不反向就不反向，跨模块调用必须通过接口。渲染器想触发音效，正确路径是发一个「打击事件」，音频模块自己去订阅事件；或者由游戏层作为协调者，拿到两个模块的接口后把「打击时播这段音效」的绑定关系配置好。让模块之间通过共同的核心层和事件机制交互，比 A 直接拿 B 的类要干净得多。
2.2 依赖圈子化与接口设计
模块多了以后，依赖关系通常不是一条直线，而是多个模块依赖到同一个稳定的中心。这个中心可以是核心层的接口定义，也可以是专门的依赖容器。做法是：把模块间需要共享的数据结构和事件定义提取到核心层，比如「碰撞结果」「打击点」「角色状态变化」这几类纯数据结构，不携带任何模块逻辑。这样渲染、音频、玩法都只依赖核心层，不会互相形成边。
接口设计上，我建议遵循「接口放在被依赖方」的原则。也就是说，音频模块自己定义「播放一次音效 PlayOneShot()」的抽象接口，由音频模块内部实现；其他模块调用这个接口，而不是反过来让音频模块依赖别人的抽象。接口描述的是「你能为我做什么」，而不是「我需要你来配合我做什么」。把接口放反了，依赖方向就会跟着翻过来。
有时候你会看到某团队的模块依赖图画出来是网状而不是朝下的树状，这几乎一定意味着缺少一个稳定的公共层。发现这种图别急着骂，先检查是不是有些共用的类型和事件散落在各个模块里了。把这些类型下沉到核心层，许多箭头会自己消失。
3. 帧循环设计：固定步长、可变步长与插值渲染
3.1 三种帧循环方案的对比
帧循环是引擎的「心跳」，基础架构里它最容易被忽略，却直接影响物理是否稳定、网络是否同步、编辑器是否卡顿。常见的方案有三种。
第一种是可变步长，每帧读取真实运行时间，计算 deltaTime 后更新逻辑。简单直观，但物理上容易出现「帧率越高物体弹得越高」这类问题，因为积分步长不稳定会累积误差。
第二种是固定步长，逻辑每秒更新固定 N 次，渲染可以在任意帧率跑。这样物理模拟、网络同步都有确定的行为，代价是逻辑对渲染有延迟，需要插值来补偿画面表现。
第三种是混合方案，逻辑固定步长加渲染插值，这个是最常在商业引擎里看到的做法。伪代码大致是：
const float kFixedStep = 1.0f / 60.0f; const float kMaxFrameTime = 0.25f; float accumulator = 0.0f; while (running) { float frameTime = min(GetFrameSeconds(), kMaxFrameTime); accumulator += frameTime; while (accumulator >= kFixedStep) { UpdateGameLogic(kFixedStep); // 物理、动画逻辑 accumulator -= kFixedStep; } float alpha = accumulator / kFixedStep; RenderFrame(alpha); // 用 alpha 插值渲染 }这个模式里的 accumulator 是关键。它把「时间余量」累积起来，逻辑按固定节奏走，渲染则利用余量计算出两个逻辑帧之间的插值系数 alpha。alpha 说明的是「你离上一帧逻辑状态更近，还是离下一帧更近」，画面里移动物体的平滑度就靠它保证。
3.2 时间缩放、断点调试与后台切走
帧循环真正会踩坑的地方，几乎都跟「时间的不可靠」有关。后台切走再回来，GetFrameSeconds() 可能给出几秒的间隔，我见过最直接的做法是拿这个值直接参与更新，结果角色瞬间瞬移穿墙。所以帧循环里一定要设 clamp，比如单帧最大时间上限 0.25 秒，超过就当掉线处理，必要时做平滑过渡。
另一个容易被忽略的是「游戏时间」和「真实时间」的区分。游戏要有暂停、减速、加速的时间缩放能力，动画、AI、技能冷却都应该使用可缩放的游戏时间推进，而 UI 的动画、编辑器的视图导航、性能监控则应该走真实时间。如果整个项目共用同一个时间戳，后面加「时停」技能和慢动作回放时，你会发现所有系统都被迫改一遍。
调试也是一个隐藏问题。当你打断点停住时，引擎还在继续计时，恢复运行后 deltaTime 会瞬间飙到很大。即便有 clamp，逻辑和画面的衔接依然可能怪怪的。很多引擎会提供「空闲模式」，检测到调试器挂起就把帧时间重置为稳定值。自己做引擎时别嫌这个小功能土，它省掉的坑比你想象的多。
固定步长虽然好，也别一味把帧率定得过高，60Hz 基本能满足大多数玩法，动作要求高的再上 120Hz。步长越密，CPU 越吃力，尤其物理和寻路的成本会等比放大。
4. 数据驱动与运行时：让引擎「可改」而不是「可读」
4.1 配置外置与资源引用
基础架构做到一定程度，你会自然碰到一个岔路：同样一个玩法，是做三份代码，还是做一套通用逻辑加一份配置数据。我的经验是，凡是美术和策划高频调整的东西，尽量设计成数据。怪物怎么移动、技能伤害系数、掉落概率这些字段，一旦写死在代码里，每次调整都要重编、重启、跑回归，团队会发现改一个数值要浪费整个下午。
数据驱动的核心不是「用配置文件代替代码」，而是把「规则」与「参数」分离。规则仍然在代码里，比如「角色受到伤害 = 攻击力 × 技能系数 × 随机浮动」，但攻击力、技能系数、浮动范围全部来自配置面板或数据表。这样运营调平衡，工程师不用管。
资源引用同样要数据化。场景文件、预制体、动画状态机描述规范，资源不再用「文件名」作为唯一标识，而是用 GUID 或 Hash 引用。文件名会重命名，GUID 不会。我见过因为资源改名导致关卡缺失的情况，原因就是序列化里存的是字符串路径。用稳定的 ID 管理资源引用，改名、迁移目录都不会断链。
大致的资源管理流程可以这样拆：加载请求经过资源管理器，按依赖关系递归加载，每个资源带引用计数，场景加载结束后自动归零触发卸载；运行期对频繁使用的加载项做缓存，而不是每次创建新对象。设备上内存不足时，按最近最少使用策略回收可卸载资源。这一整套逻辑属于引擎基础架构，不属于某个具体游戏模式。
4.2 热重载：从改数据到改代码
数据驱动的另一个好处是天然支持热重载。线上运行时修改技能表保存，资源管理器监听到文件变化后重新加载，已经创建出的对象只需要把旧字段换成新字段，不需要重启进程。这一步对迭代效率的提升非常明显，编辑器里调数值时那叫一个舒服。
如果追求更彻底的热重载，就到了脚本系统这一层。脚本层通常放在核心层之上，由脚本引擎管理类的注册与替换。做热重载之前要先想清楚：已经加载的旧对象怎么迁移到新类？旧对象持有的状态字段哪些保留哪些放弃？事件绑定的方法怎么重新指向？这些问题没有一个通用答案。我的建议是，先做数据热重载，把配置和资源的动态更新跑稳，再考虑脚本热重载。
说白了，热重载的本质是「运行时类型系统和资源管理器的协作」，它要求你从一开始就把对象创建、卸载、状态迁移这几个生命周期接口设计清楚。你要是等代码都写完才想加热重载，会发现到处都在 new 对象、到处都在改全局状态，根本无从下手。
5. 内存分配与多线程任务调度：性能天花板的两块基石
5.1 分配器选型
引擎基础架构里，内存分配的问题通常不是「内存在哪」，而是「分配和释放的节奏、碎片、缓存局部性」。游戏每一帧都会有大量临时对象，每次都走系统 malloc 会产生碎片、还会有隐藏的系统调用开销。成熟引擎都会提供几个基础分配器组合使用，最常用的有栈式分配器、池式分配器和帧分配器。
| 分配器 | 典型用途 | 优势 | 风险 |
|---|---|---|---|
| 帧分配器 | 每帧生命周期很短的临时数据 | 分配释放极快，几乎不产生碎片 | 误用长生命周期对象会导致悬垂 |
| 栈式分配器 | 临时缓冲区、递归调用场景 | 顺序分配反向释放，管理简单 | 需要维护栈顶，越界难排查 |
| 池式分配器 | 子弹、敌人、特效等固定类型对象 | 固定大小节点复用，缓存友好 | 池子满了要扩容策略 |
| 通用定位分配器 | 大块持久数据 | 灵活，兼顾对齐 | 碎片风险高，慎用 |
直接用系统 malloc 不是不行，但引擎高流量路径上要尽量避免。我见过一个项目，把每帧都要创建的矩阵对象全部丢给默认分配器，后来换成栈式分配器，帧时间直接掉了十几个点。反过来也别滥用池化，很多对象生命周期差异极大，硬塞进同一个池里反而增加管理复杂度，先用性能分析工具看清楚分配热点，再决定优化哪个。
内存布局还要考虑缓存友好。数组比链表好，因为内存连续、预取效率高。即使数据关系上适合用指针连接，你也应该尽量先把它们放进连续数组，再用索引代替指针。做任务调度时这点尤其明显，线程并发读同一块连续数据，和并发访问散落的内存块，速度差距能有好几倍。
5.2 任务依赖图与帧预算
多线程调度是引擎性能天花板的另一个决定性因素。基础做法是维护一个线程池，把每一帧要做的事拆成一个个任务，任务是独立的，任务之间可以有依赖关系。核心层的任务调度器负责把没有依赖的任务分发给空闲线程，每个任务完成后唤醒等待它的任务。
我之前做的系统里，每帧是这样组织任务的：动画 Prepare、物理 Step、渲染 Culling、粒子 Update 各是一个任务，物理 Step 依赖动画 Prepare 的输出，渲染 Culling 依赖物理和动画的成果。任务调度器根据依赖图决定执行顺序，同一帧里没有依赖的部分可以并行。伪代码轮廓：
TaskGraph graph; auto anim = graph.AddTask("AnimPrepare", [] { /* 更新骨骼 */ }); auto phys = graph.AddTask("Physics", [] { /* 推进物理 */ }, anim); auto cull = graph.AddTask("Cull", [] { /* 可见性裁剪 */ }, phys); graph.Submit(); // 自动并行无依赖任务 graph.Wait(); // 主线程在这里等待一帧任务完成任务调度器真正复杂的是帧预算控制。有的任务如果上一帧都跑不完，下一帧就不该再排队堆积，否则玩家会感觉到操作延迟越来越大。通常的做法是给每帧设定一个总预算，超过预算的任务按优先级淘汰或降级，比如降低物理精度、减少渲染粒子数。这就是所谓「永不追帧」策略，游戏宁可降低画质，也不该让输入响应越来越迟钝。
多线程调度最大的敌人其实是数据竞争和误共享。任务里绝不能直接操作 UI 和渲染上下文，只能产生结果数据，真正提交渲染要回到主线程。把共享数据的写入放进同一个任务里，比到处加锁要高效得多。我也常跟人说，不到万不得已不要自己实现并发容器，先保证任务划分正确，再加细粒度锁或原子操作，90% 的情况下这样已经够了。
6. 模块通信与编译期解耦：引擎改起来不伤筋动骨的关键
6.1 接口隔离与服务定位
做引擎到了一定规模，你会发现模块之间的耦合不只在运行时，还在编译期。一个公共头文件被几十个模块包含，每次改动哪怕只是加个字段，全工程都要重新编译一次。于是基础架构里就有一个经常被忽略的责任：控制头文件依赖半径。
几个实用手段。第一，接口类只暴露纯函数和纯数据，不讲实现细节；第二，使用不透明指针把私有结构藏进实现文件；第三，模块对外只提供一个工厂函数或单例入口，调用方拿到的是一份接口指针。这样哪怕内部实现天翻地覆，只要接口没变，所有依赖方都不需要重新编译。服务定位器（Service Locator）在这个场景下挺好用：把渲染、音频、物理等模块注册到一个统一容器，其他模块需要时按接口类型查询。它适合模块数量多、替代关系明确的引擎。
有一点要提醒：接口越宽，耦合就越重。很多团队喜欢把十几个方法塞到一个「Renderer」接口里，导致每个使用方都间接依赖整个渲染能力，一改就要重编一大片。更好的做法是拆成多个小接口，比如「对象提交」「相机管理」「贴图加载」，让不同的调用方依赖不同的窄接口。窄接口在运行时实现类可以相同，但在编译期它把影响范围隔离开了。
6.2 事件总线的使用边界与「过度抽象」
跨模块通信最常见的选择是事件总线。A 模块发布事件，B 模块订阅事件，两者互不感知，松耦合确实好。但它也有明显的代价：调用关系变隐晦。一个事件发出去，你不知道有多少订阅者会被触发，也不知道它们触发顺序依赖。这在线下排查诡异 bug 时特别折磨人。
所以我会给事件总线定几条使用边界。低频、面向广播、或者未来可能增加多个监听方的事件，适合走总线，比如「游戏开始」「关卡加载完成」「成就解锁」。高频且需要返回值的操作（比如「播放一段音效并拿到句柄」），应该走窄接口直接调用。与流程强相关的步骤（比如「先算动画再推进物理」），也绝不能用事件总线，因为它无法保证顺序。事件总线用来解耦，但引入的隐式依赖却需要更强的项目纪律来对冲。
过度抽象的案例我见过不少：一个简单的「禁用输入」操作，被抽象成事件、监听器、命令模式三方协作，线上排查时一路翻六个文件还没找到赋值的位置。做基础架构时要时刻记得抽象是为了降低认知负担，不是增加。我给自己定的标准是：如果一段代码在没有性能问题的情况下不能被一句话讲清「它调了什么、谁在听它」，那么这个抽象大概率是多余的。
如果让我重新做一版引擎，我会先画一幅模块依赖图再写第一行代码。图上箭头朝下、没有环，是第一关；接着才是帧循环、资源、内存、调度这些细节往里填。基础架构的美，不在于用上多前沿的设计模式，而在于每个模块都知道自己在哪、要管什么、能信谁。后面我打算继续拆帧循环和资源管理里的具体实现，这篇先把骨架立住，泥巴和钢筋都有了，墙才好往上砌。
