引擎基础架构的关键决策：分层、主循环与内存管理

做引擎架构这件事最困惑我的一个问题是明明整个项目都能跑为什么读别人的引擎源码就像走进一栋没有电力标记的大楼每扇门背后都通向一个未知的房间后来我自己动手拆过几个轻量引擎也接手过被改得乱七八糟的旧项目才慢慢意识到所谓基础架构并不是一堆代码文件的拼凑而是几个非常干净的决策谁在什么时机运行、谁允许知道谁的存在、以及谁掌握内存和资源的生死。这篇内容适合两类人一类是准备入行引擎开发、想知道那些大引擎内部到底怎么编排的初学者另一类是写过游戏逻辑但屡屡被耦合拖累、想回头梳理架构边界的客户端开发者。我不会从DX或者Vulkan的接口讲起那属于渲染模块的战役这里只聊引擎底层的地基——也就是哪怕你做的是一个一夜之间流行的小游戏也逃不开的那几个结构性问题。1. 分层边界引擎为什么不是一张网而是一摞盘子先回答一个最常见的问题引擎到底是不是把渲染、物理、音频全放一起然后互相调来调去如果你维护过一个项目你肯定见过这种大杂烩的运行方式。但它不是架构它只是堆代码。成熟的引擎架构第一眼看起来会非常像一摞盘子每一层只允许跟相邻的层打交道不允许跨层乱拽。1.1 我习惯从下往上画这五层底层是最容易被忽略的平台抽象层Platform Layer。这个层专门包装操作系统差异窗口系统、鼠标键盘输入、手柄、文件路径、线程同步原语。它的存在意义很简单上层代码里永远不许出现DirectX专属句柄、Windows.h的打开文件对话框或者Linux的X11窗口句柄。我自己在做跨平台工具时曾经因为一个文件监听模块里混进了平台API导致后来换到另一套工具链时整个模块重写这个教训很深刻。平台抽象层之上是核心层Core Layer包含数学库向量、矩阵、四元数、容器动态数组、哈希表、字符串、内存分配器、日志与诊断工具。这一层是纯数据结构和算法不关心你渲染的是人物还是方块。再往上是功能模块层Feature Layer渲染器、物理引擎、音频引擎、动画系统、网络模块都住在这儿。它们一般以库的形式存在每个库有明确的外向接口。比如渲染器对外只提供DrawMesh、SetCamera、SubmitFrame这类语义物理引擎对外只提供AddRigidBody、Raycast这类语义。这两个模块彼此通常不应该认识对方。功能模块层之上是场景管理Scene Management。场景是最容易跟游戏逻辑混淆的东西它实际上是世界状态的容器哪个物体在哪、坐标多少、旋转多少、身上挂了几份组件。场景管理关心的是组织这些数据而不是执行逻辑。再往上一层才是应用/游戏逻辑也就是策划脚本、Boss AI、技能系统那些东西。1.2 为什么必须是相邻依赖而不是谁方便谁调很多人写代码有个习惯反正渲染器拿不到物理结果那我直接让渲染器去读刚体列表不就完了反对这种做法的理由不是洁癖而是依赖方向决定了项目能不能并行开发、能不能局部替换、能不能测试。举个我实际遇到的例子。某个模拟项目为了省事让渲染模块直接遍历物理模块的碰撞体列表来画调试线。结果某次物理引擎内部把碰撞体数据结构从链表改成紧凑数组渲染模块那边就因为遍历方式不同直接崩了。问题不在于谁对谁错而在于一个渲染层不该知道物理层的内部存储细节。正确的做法是物理模块对外提供查询接口或者调试绘制回调渲染模块只消费这些规范的输出。我在架构里最信奉的一条规则是数据所有权就近访问权向下开放。场景管理者不直接向渲染模块暴露我正在遍历的节点数组而是暴露场景里现在有哪些静态网格、哪些变换矩阵需要同步。渲染模块不需要知道这些网格是从磁盘加载的还是脚本生成的它拿到的是一份已经整理好的渲染输入。这样做分层每一层都能单独替换、单独测试。2. 主循环引擎心跳为什么必须由你亲自控制如果说分层是引擎的空间结构主循环Game Loop就是引擎的时间结构。所有引擎都围绕一个死循环转处理输入、更新世界、提交渲染、等待垂直同步、再回到输入。看起来简单但循环里的每一个决策都影响手感、性能和功耗。2.1 固定步长还是可变步长这是第一道分岔可变步长最简单每帧计算deltaTime currentTime - lastTime然后所有更新逻辑都用这个deltaTime去乘。好处是迭代快逻辑好写坏处是物理模拟不稳定——当deltaTime忽大忽小弹簧系统会发散角色会抖动网络同步也需要特殊处理。固定步长则是把时间切成固定的小块常见是1/60秒也就是大约16.67毫秒。每次主循环先算从上次到现在过去了多少时间然后累加到一个时间缓冲器上只要缓冲器里累积的时间超过一个固定步长就执行一次固定更新一次可能执行多次直到时间不够为止。我在实际项目里通常采用混合方案逻辑更新用固定步长渲染插值用可变因子。固定步长保证逻辑的确定性渲染层根据上一次逻辑更新和下一次逻辑更新之间的比例做插值这样哪怕逻辑每秒只跑 30 次渲染仍然能撑到 60 帧画面既稳定又顺滑。这里有个容易忽略的细节固定步长的值不能随意设。如果你的游戏是针对60Hz显示器做垂直同步逻辑步长设成 1/60 秒会让你每帧恰好执行一次逻辑但用户换到 144Hz 显示器同样的固定步长时间参数每帧就要执行两三次逻辑性能开销直接翻倍。所以更稳的做法是把逻辑步长定在 1/120 秒甚至更低让不同刷新率下执行次数趋于一致再用插值补偿视觉效果。2.2 输入采样时刻决定手感很多自研引擎手感差根源不在物理参数而在主循环里没有固定输入采样点。我的经验是输入必须在每一帧的逻辑更新之前统一采样一次并作为这帧逻辑的输入快照。如果不做快照玩家在一个循环里按下跳跃、又在同一个循环末尾松开逻辑模块在不同时机读取输入时会出现这帧按了但没跳起来的怪现象。我自己就遇到过在回调里直接改键位状态导致同一个事件被多个模块分别处理时各拿各的理解最后角色行为看起来像抽风。后来把输入抽象成每一帧生成的按键状态数组各模块只读这份快照问题就消失了。2.3 循环顺序不能乱排一个标准的引擎循环顺序是这样的采样输入Input运行日志与调试界面可选但要在更新前推进动画Animations唤醒与步进物理Physics游戏逻辑脚本Script/Gameplay处理相机Camera渲染提交Render呈现Present物理必须在逻辑之前因为大多数游戏逻辑需要依赖物理的结果比如角色是否落地。渲染必须在所有逻辑之后因为渲染需要拿到最终的世界状态。动画则在物理之前因为动画驱动骨骼物理需要知道骨架的位置。有一个坑是如果你在更新逻辑里生成了新的物件而这个物件需要立刻参与物理或渲染那它的初始化顺序就会跟循环结构产生冲突。常见的处理办法是延迟生成把所有创建新实体的请求收集起来在循环末尾统一处理避免在物理步进中途改世界。我在某次项目里没有延迟创建结果一个机关的子弹在生成瞬间穿透了墙壁——因为物理步进时子弹还没被加进碰撞检测列表。3. 内存策略引擎性能的秘密藏在分配器里游戏开发者跟普通后端开发者最大的不同是对内存分配有近乎偏执的洁癖。原因很简单malloc是慢的还可能产生碎片更可怕的是大量小内存申请的缓存不友好会让整个 CPU 变成等内存的空转机器。3.1 帧内存与环形分配器我第一个建议是在引擎里单独划出一块帧内存Frame Memory。它的规则非常原始只往里塞不往外释放每帧结束整体重置。用途是那些这一帧用完就扔的临时数据比如 UI 排版产生的顶点、调试绘制的线条、碰撞查询的结果容器。实现上可以用一个巨块数组加一个偏移指针每次分配就是给当前偏移偏移往后挪。一帧结束后把头指针归零。这种分配器每秒可能执行几千次分配但实际每次分配只是移动一个整数速度比通用malloc快一到两个数量级。当然它有个显而易见的限制你不能在这块内存里存放跨帧存活的数据否则下一帧指针回绕就把你上一帧的东西踩了。所以使用它的人需要心理清楚我这块数据生命周期有多长。3.2 对象池解决的是弹幕和粒子这类频繁诞生又频繁死亡的对象游戏里最常见的开销杀手是粒子系统。每帧几百个粒子诞生、动画、消亡如果每次都new/delete分配器的锁和系统调用能吃掉不少帧时间。对象池的做法是在启动时预分配好一定数量的粒子对象池粒子诞生时从池中拿一个空闲元素池子头尾指针移动一下粒子消亡时把元素放回池子不用释放内存。我经常把对象池跟紧凑数组结合起来让存活的粒子连续存放在内存里方便渲染层整块读取。释放就采用Swap-Remove把要移除的元素和最后一个元素互换位置然后让数组长度减一。这样遍历时颗粒度紧凑CPU缓存命中率也更高。这个模式不仅适合粒子还适合投射物、敌人尸体、标记点只要对象类型具备短暂、数量多、结构固定的特征。3.3 缓存友好性真正的性能瓶颈是数据在内存里的摆放代码优化的天花板往往不是算法复杂度而是缓存行Cache Line。一个 CPU 缓存行通常是 64 字节如果遍历一个对象数组时每个对象的大小是 200 字节而用到的字段只有前 16 字节那么每一次访问都会把整条缓存行拉进来但只用了 8% 的数据这是极大的浪费。引擎架构层面的应对是 Data-Oriented Design数据导向设计核心思想是把相同的字段放到连续内存。比如所有角色的位置放在一个 float 数组里所有速度放在另一个数组里而不是给每个角色建一个结构体。这样物理系统暴算位置时CPU 拉进来的每一个缓存行都是纯粹的位置数据计算效率能提升好几倍。我在重构一个上万AI角色的模拟系统时把对象数组拆成了位置数组速度数组朝向数组同样的硬件配置运行帧率从二十多帧提到了接近满帧。这不是玄学是缓存命中率的胜利。3.4 虚拟内存预留避免大世界加载时的抖动做大型场景加载时最容易踩的坑是每次加载新区块都实时向操作系统申请大块虚拟内存导致卡顿。成熟的做法是在引擎启动时提前向操作系统预留很大一段地址空间Reserve但不提交物理内存Commit运行时按需提交小段。简单说预留是一个签名承诺这块地址我以后要用提交是真正把物理内存页挂上去。这样后续加载区块时大部分操作是提交已经预留好的地址不会频繁触发地址空间搜索和页表重构能显著减少加载尖峰。做流式开放世界时这个设计几乎是标配。4. 资源与生命周期谁加载、谁持有、谁卸载一个合格的引擎必须解决资源管理这个很无聊但十分致命的问题。游戏运行时需要加载模型、贴图、音频、动画、材质、配置文件如果谁加载谁管理项目一跑起来就是事故现场。4.1 用ID取代路径引用资源系统第一件事是给每一个资源一个稳定、与文件系统无关的标识符通常是一个哈希ID或GUID。游戏逻辑里引用资源时不写贴图路径/Icon/004.png而是写一个哈希ID渲染层拿这个ID到资源表中查询。这么做的好处首先是重构友好文件路径随便改代码不用动。其次是引用语义清晰不会出现两个模块各自加载同一资源、内存里存两份贴图的情况。资源系统内部有张全局映射表GUID - 资源的运行时描述符描述符里存了物理数据指针、引用计数、加载状态等。4.2 异步加载和依赖图不要等文件慢慢读如果一个角色要等它的模型、贴图、骨骼动画全部加载完才出现玩家会看到明显的卡屏。好一点的引擎都提供异步加载接口发起加载请求后立刻返回一个句柄加载在后台线程执行等数据准备完毕后再通知主线程切换。这里真正的复杂度是依赖图加载一个地图区块可能要求先加载地形数据、然后加载引用该地形的植被模型、最后加载植被材质里引用的贴图。资源系统必须有能力追踪这种依赖链并在所有依赖都就绪后回调资源可用。我自己写过一个简化的做法用一个资产清单文件描述每个资源的依赖加载时先读清单建一个待加载队列用拓扑顺序依次加载每个资源带一个依赖就绪计数归零时触发加载完成的回调。这个设计虽然简陋但让我彻底理解了为什么引擎会花大量精力维护一个资源工作图。4.3 引用计数与所有权谁该负责卸载资源卸载是另一个大坑规则必须非常明确。我采用的原则是加载资源的模块不一定是释放资源的模块释放由资源管理器统一调度。所有资源都带引用计数游戏逻辑在需要时增加引用不再需要时释放引用。资源管理器会定期或按阈值清理引用计数归零的资源。但引用计数有个麻烦循环引用。A 资源引用 BB 又引用 A两边都不释放内存就泄漏了。引擎层常用强引用弱引用的组合来打破循环。比如材质强引用贴图贴图对外只提供弱引用材质销毁后贴图失去唯一强引用自然被回收。关于流式加载Streaming我的建议是不要只做加载卸载两个状态而要做未加载-正在加载-可访问-待卸载四个状态。待卸载状态允许引擎延迟几帧真正释放资源这样玩家突然回头时资源还能快速复用不会因为一次物理内存回收就卡顿。5. 模块通信让渲染、物理、脚本不互相拉踩分层和内存搞定后下一个真正影响团队协作和开发效率的问题是模块之间怎么通信。很多引擎项目从外部看功能齐全内部却是一团乱麻正是因为模块之间在绕过边界直接调用。5.1 直接调用、事件总线、数据驱动三种方式都有适用场景我见过三种主流的模块通信方式。第一种是直接接口调用比如脚本里调用物理接口AddForce这是最直白、性能最高、排错最容易的方式适合强关联、高频、实时的调用。缺点是一旦调用关系泛滥依赖就变成蜘蛛网所以接口应该定义在模块的公共头文件里模块内部实现不对外暴露。第二种是事件总线Event Bus适合谁关心谁去听的场景。比如游戏里机关被触发这个事件可能被粒子系统、音效系统、任务系统、关卡情绪系统共同关心与其让机关代码分别调用四个系统的方法不如只发一条TriggerEvent各系统自己订阅。事件总线的优点是解耦缺点是不容易跟踪调用链调试时比较费劲所以不适合用在每帧都会发生的性能敏感路径上。第三种是数据驱动即模块之间不直接调用而是通过共享数据结构表达意图。比如物理模块每帧把所有刚体变换写入指定内存区渲染模块直接读这块。这个方式最接近现代 ECS 的做法——数据是组件逻辑是处理数据的系统。好处是缓存友好、并行度高坏处是需要参与者严格遵守数据协议一旦协议变动整改成本很高。5.2 一个推荐的通信姿势接口放在公共层实现放在私有层与其纠结用哪种通信方式不如先把规则定死模块间可调用的接口只存在于公共头文件中模块的类定义和函数实现完全私有。这样即使你用的是直接调用也有办法通过接口实现换实现。举个例子渲染器对外只声明class RendererInterface里面是void SubmitMesh(...)而真正的D3D12Renderer在 .cpp 文件内部私有地实现这个接口。脚本系统拿到的是接口指针永远拿不到D3D12Renderer的定义。你随时可以换一套渲染后端脚本那边一行不需要改。5.3 更新顺序先做什么后做什么不能由模块自己说了算每个模块可能有自己的 Tick 函数但Tick 的调用顺序必须由一个中央调度器决定不允许物理模块在更新时主动调动画模块的更新接口更不允许脚本系统在主循环之外偷偷开线程更新世界。我在自己维护的引擎里维护了一个双维护表一个表按逻辑顺序记录每帧需要被 Tick 的系统及其优先级另一个表专门记录渲染帧完整提交前必须完成的最后一批操作。比如相机变换和剔除必须在渲染提交之前但触发一场粒子爆炸则可以在渲染提交之后排队算。这里还有一个很深的设计有些模块有两阶段更新需求。例如动画系统先计算逻辑层的骨骼位置然后在渲染提交前再计算最终的蒙皮矩阵。如果动画系统只有一个 Tick就很难在渲染阶段拿到最新数据。我的做法是给关键模块提供BeginFrame/Update/PreRenderSubmit三个生命周期钩子调度器按固定顺序执行模块自己控制三个阶段里各自干什么。6. 实战中的耦合治理我是怎么拆掉一个缠绕引擎的理论上限说够多了讲一段我的真实经历。我接手过一个模拟引擎项目规模不大但功能模块极度缠绕渲染器能直接访问游戏角色类的成员变量物理引擎的步骤里会调用相机脚本而脚本系统在载入关卡时会直接创建图形资源。每次改动一个小系统其他系统里就冒出一堆编译错误修完编译错误又发现行为不对。我做的第一件事不是换架构而是先画依赖图。把每个模块的顶层文件之间的 include 关系画出来这不是为了看继承而是为了看清谁依赖谁。结果图画完所有箭头都交织在一起那就不叫图叫团。第一刀把平台层剥离。把窗口、输入、文件访问从功能模块里全部抽到一个独立的Platform包里用统一接口包装。这一步大约改了十几个文件的 include。第二刀把实体数据的访问权限收回。游戏逻辑不再直接暴露内部的PlayerComponent地址而是只提供只读快照接口。渲染器和物理器通过快照拿数据而不是直接拿组件指针。这个改动很痛苦因为原本很多代码在直接写player-pos但我咬着牙全改成world-GetTransform(entityId)。第三刀建立事件总线并迁移跨模块通知。原来机关触发时直接遍历场景里的音效对象去播放迁移之后只发一个trigger_event音效系统自己订阅。这个迁移花了三天但之后新增一个机关发光的效果一行系统代码不用改只需要音效系统或特效系统多订阅一条事件就行。拆完之后我印象最深的不是性能提升其实逻辑帧率变化不大而是改 bug 的速度明显变快。原来一个 bug 往往要翻三个模块才能定位现在看一眼事件日志就能确认是哪个模块出的问题。这才是架构带来的最大红利它降低的不是单次操作的开销而是整个团队持续开发的熵增。7. 基础架构的验收清单最后给准备搭引擎或者重构引擎工作的你一份我自己的验收清单不搞虚的每一条都是我踩过的坑。主循环里输入快照、固定步长逻辑、渲染插值这三件事是否被清晰分开混在一起的话第一步先拆它们。所有模块是否只能依赖相邻层级画依赖图时如果出现跨层箭头说明边界缺接口或者缺数据协议。是否有一块独立的帧内存专供临时数据使用如果没有可以考虑先加一个简单的头尾指针分配器。粒子、投射物、特效这类高频短命对象是否走了对象池还是每帧都在new/delete?后者通常会在Profiler中表现为分配开销和内存碎片。资源的加载是否支持异步加载资源时会不会阻塞主线程如果会是否有明确的加载状态机未加载/加载中/可用/待卸载模块间通信是否至少有一条可追踪的路径也就是出 bug 时你能不能仅凭日志就知道谁调用了谁、触发了什么事件。最后一条也是我认为最重要的一条当你改一个模块的内部实现时另一个模块的代码需要改动吗如果只需要在接口层变化你的架构就是健康的如果需要一行行去修调用方那架构就是债越早越疼。引擎基础架构不是一个能一步到位的成果它是你在每个项目里反复拆换、打磨出来的习惯。我写这套系列的第一篇就是想把这些习惯先摊开讲清楚。下一篇我准备深入渲染提交概览的细节聊一聊从场景数据到渲染指令之间那条真正的修罗之路。