1. 为什么我劝你别只盯着某个渲染特性先看引擎的架构先讲个我自己的事。几年前我在一个中型项目里做战斗系统每天跟角色动画、技能逻辑、伤害计算打交道。某天忽然冒出一个特别诡异的bug一个被击飞的敌人血条扣了动画也播了但打在它身上的特效位置完全不对再细看特效挂的坐标居然是从上一个被打死的敌人身上继承的。定位了一整天最后发现不是某个系统写错了而是整个引擎的资源生命周期管理出了问题一个Entity被销毁之后它的Transform组件没有被正确释放回池子后续新生成的特效组件刚好复用了这块内存于是视觉表现就串了。从那天起我意识到一件事在引擎里遇到的大部分奇怪的、难以定位的问题根子往往不在某个具体系统而在架构层。这也是我从会用引擎转向想理解引擎的转折点。你当然可以一辈子只当Unity、UE或Godot的熟练使用者不去管引擎内部怎么组织但一旦你遇到以下任何一种情况——想做定制管线、想写编辑器工具、想优化加载速度、想跨平台移植、甚至只是想把内存占用压下来——你会立刻发现不懂架构就寸步难行。那么游戏引擎的架构到底指什么我给你的定义是引擎负责把游戏世界里变化的东西逻辑、渲染、物理、动画和相对不变的东西资源、配置、场景数据组织起来并让它们以稳定的频率协同工作的一整套代码与数据结构的骨架。这套骨架通常包含内存管理、帧循环、事件分发、组件模型、资源生命周期、渲染/逻辑分离的调度机制等几个大板块。本系列的第一篇我就先把这块地基讲清楚引擎基础架构由哪几根大梁撑起来引擎和普通软件为什么在结构上天然不同以及如果你要从零搭一个最小可用的引擎骨架应该怎么起步。这个系列适合这么几种人引擎使用者想进阶到能改引擎甚至能二开的深度用户想做游戏开发的在校学生或刚入行的程序员想知道游戏代码和业务代码的区别到底在哪对GDC分享、引擎源码剖析感兴趣但被那一堆英文术语和庞大代码库劝退的爱好者。我会尽量用工程师跟工程师聊天的方式来讲不整虚的。2. 引擎和普通软件的三观不一样帧循环、实时性、生命周期很多写后台服务、Web应用的同事转来做游戏最常见的不适应就是游戏里没有一个请求-响应的关节取而代之的是一圈又一圈永不停歇的循环。这份差异决定了引擎架构的第一性原理。2.1 帧循环所有系统的呼吸节奏你写一个管理系统逻辑通常是等用户操作→处理→响应。引擎不是这样它在启动后就自我驱动每一帧都要完成一连串固定动作处理输入→更新逻辑→跑物理→准备渲染→提交渲染→再次回到起点。这个帧循环就是引擎的呼吸节奏。帧循环有两种常见的节奏控制方式。固定时间步Fixed Timestep物理模拟和逻辑更新按照固定的时间间隔执行比如每1/60秒更新一次好处是结果可复现、调试稳定坏处是如果帧率低于步长可能会出现为了追赶时间而连续多次更新的死亡螺旋。可变时间步Variable Timestep每帧使用真实经过的时间deltaTime来驱动好处是绘制跟得上实时坏处是物理稳定性差、不同帧率下行为不一致。成熟引擎几乎都是混合式渲染走可变时间步保证画面流动感逻辑和物理走固定时间步保证确定性。所以你会在Unity里同时看到Update()渲染帧驱动和FixedUpdate()固定步长驱动在UE里看到Tick()时也分priority和bTickEvenWhenPaused。这两套时间基准的存在是所有引擎架构设计矛盾的源头也是后面一切系统设计的隐藏前提。2.2 实时性约束19毫秒预算到底意味着什么普通软件的一个查询耗300毫秒用户顶多觉得有点慢。游戏里一帧只有约16.6毫秒60FPS下渲染往往已经占掉10~12毫秒留给逻辑、物理、动画的只有几毫秒的时间预算。这种严苛的实时预算让引擎架构产生了一个核心设计态度数据优先于抽象。你很少看到引擎的关键路径上堆满一层层接口封装因为虚函数调用、动态内存分配、隐式锁这些在业务代码里无所谓的开销在引擎热路径上都是要被消灭的对象。我见过一个很典型的反例。一个自研引擎早期用了大量shared_ptr管理组件对象逻辑写起来特别爽结果到千人同屏测试时直接卡成PPT。原因很简单shared_ptr的引用计数是原子操作大量并发的增减计数把CPU缓存都打穿了。后来改成实体池化显式free回收类似我在开头讲的那个串联bug的解法帧时间立刻降了30%。游戏引擎架构的第一课就是学会为了性能约束去放弃代码上的优雅。此外引擎架构还需要处理好生命周期的一致性。引擎里所有对象资源、实体、组件、命令都不是随用随new、用完丢给GC的类型而是有明确的创建→使用→回收阶段。一个资源可能同时被渲染、物理、音频三个系统引用如果其中一个系统还在用资源管理器就把它卸载了那就会出现我开头说的那种串数据事故。生命周期管理是引擎架构和普通软件架构最本质的分水岭之一。3. 引擎基础架构的三根支柱分层、组件模型、资源管理架构这个词听着虚落到代码层面其实就三件事。搞定这三件事你就算抓住了引擎的骨架。3.1 支柱一分层架构——渲染层永远不该知道UI按钮叫什么引擎的基础架构普遍采用分层设计。我把它简化成底下这张关系层级职责典型模块能依赖谁平台层窗口、输入、图形API封装Win32/GLFW、DX/Vulkan、音频后端谁也不依赖核心层数学库、容器、内存分配、事件Math、Vector、PoolAllocator平台层功能层具体游戏系统渲染、物理、动画、音频、UI平台层核心层游戏层玩法逻辑玩家控制器、AI、任务、战斗以上全都行工具层编辑器与调试Scene视图、Inspector以上全都行这条依赖规则的目的是避免环依赖——如果渲染层直接引用一个UI按钮类那么UI层的一个小改版都可能引起渲染层重编、甚至逻辑混乱。实际工程里引擎往往通过接口反向控制让上层系统向底层注册回调例如物理模块不知道谁在听碰撞事件它只管发消息。高层可以知道低层的存在低层做梦都不该知道高层是谁——这句规则比任何一项具体功能都金贵。3.2 支柱二实体组件模型——为什么现在人人都在谈ECS游戏场景里的物品不是替你写好的对象而是实体组件的自由组合。经典的组件模型有两种层级组件模型树状Unity的GameObject、UE的Actor组件挂在节点上节点之间是父子关系。优点是好理解、适合做场景编辑缺点是写复杂玩法时组件间通信容易绕成蛛网。数据驱动组件模型ECS实体只是一个ID所有组件数据存储在各类型的紧凑数组中系统负责遍历同时拥有A、B、C组件的实体并做处理。优点是缓存友好、便于多线程缺点是没有天然的节点树实现场景编辑器和一整套序列化反而更费劲。做架构决策时你要根据团队规模和产品类型来选。中小团队做线性关卡游戏用层级组件模型能省大量的编辑器工期千人同屏、海量简单实体子弹、粒子、单位的玩法ECS几乎是唯一解。我在实际项目里见过大量团队因为ECS听起来酷而硬上结果编辑器工具链跟不上开发效率反而腰斩。架构从来不是越新越好是越匹配越好。3.3 支柱三资源管理——所有系统都绕不开的那个中心资源管理负责的事情很朴素加载、缓存、引用计数、卸载。但做好极难。引擎里的资源类型五花八门纹理、网格、材质、动画片段、音频、预制体、关卡流送块……它们的共同点是体积大、加载慢、被多处复用。一个理性的资源管理器会把资源分为两类一类是常驻内存启动就加载的核心资源一类是按需加载进入某区域才加载、离开就卸载。引用计数用于判断还有没有人在用同时提供预加载和异步加载接口让关卡切换时不用卡死主线程。资源系统还常配合一个资源缓存目录Asset Database/GUID保证同一个物理文件在整个引擎内只有一份实体所有引用都走GUID而不是路径——这一步能根治大量路径写错导致加载失败的工程级问题。4. 亲手搭一个最小引擎骨架从空项目到能跑场景理论学习再多不动手等于没看。我建议你亲手实现一个最小引擎骨架不需要任何图形API只做调度实体管理内存池化三件事你就能真切体会到架构权衡发生在哪里。4.1 最小骨架的目标我不是要造UE而是让跑系统的系统跑起来我们要做的这个最小引擎骨架标准就三条有一个稳定的帧循环能控制固定步长和渲染步长的关系有一个实体池和管理器能创建/销毁实体而不产生旷日持久的内存泄漏有一个简单的系统注册机制让不同的Feature移动、渲染占位、AI占位按顺序Tick。我不建议一上来就碰图形API因为那会把你的注意力从架构拉到渲染细节上。等你理解了系统如何组织再把渲染接进去相当于给骨架装上肌肉顺理成章。4.2 第一步实现一个排他式的堆内存分配器引擎最需要的基本功是自己管内存。下面是一个极简的方块分配器Block Allocator它从一块大缓冲里按固定大小切块分配释放时直接标记空闲——没有碎片、速度极快class BlockAllocator { public: BlockAllocator(size_t blockSize, size_t blockCount) : mBlockSize(blockSize), mBlockCount(blockCount) { mBuffer static_castuint8_t*(::operator new(blockSize * blockCount)); mFreeList new uint32_t[blockCount]; for (uint32_t i 0; i blockCount; i) mFreeList[i] i; mFreeCount blockCount; } void* Allocate() { if (mFreeCount 0) return nullptr; uint32_t index mFreeList[--mFreeCount]; return mBuffer index * mBlockSize; } void Free(void* ptr) { uintptr_t offset static_castuint8_t*(ptr) - mBuffer; uint32_t index static_castuint32_t(offset / mBlockSize); mFreeList[mFreeCount] index; } ~BlockAllocator() { delete[] mFreeList; ::operator delete(mBuffer); } private: uint8_t* mBuffer; uint32_t* mFreeList; size_t mBlockSize; size_t mBlockCount; size_t mFreeCount; };这段代码里最关键的思维是内存分配从一个系统调用变成了数组下标的读写。分配和释放都是O(1)而且不会产生碎片。代价是你只能固定分配大小为blockSize的对象。这就是引擎架构中典型的限制自由度来换性能也是为什么游戏引擎很少用通用malloc管理高频小对象。4.3 第二步建立实体ID索引版本号的实体池实体池的设计要解决一个经典难题怎么判断一个ID到底还活着答案是用分代索引Generation Index。我给出简化版struct EntityID { uint32_t index; // 在池中的槽位 uint32_t generation; // 代际每复用一次槽位就1 }; class EntityPool { public: EntityID Create() { if (mFreeCount 0) throw std::runtime_error(池已满); uint32_t slot mFreeSlots[--mFreeCount]; mGenerations[slot]; mAlive[slot] true; return EntityID{slot, mGenerations[slot]}; } void Destroy(EntityID id) { if (!IsAlive(id)) return; mAlive[id.index] false; mFreeSlots[mFreeCount] id.index; // 注意不清空组件数据。组件数据留给组件系统去清理 } bool IsAlive(EntityID id) const { return mAlive[id.index] mGenerations[id.index] id.generation; } private: std::vectoruint32_t mFreeSlots; std::vectoruint32_t mGenerations; std::vectorbool mAlive; size_t mFreeCount 0; };为什么版本号这么重要因为一个旧的EntityID如果被推迟到下一帧用来索引数据而那个槽位已经被新实体复用数据就会错乱。加上generation校验之后旧ID在使用时会因为generation不匹配被判已死从根源上报废。这部分就是我在开场讲述的那个bug的正确解法——一个带分代校验的实体池永远不会把上一具尸体的坐标传给下一颗子弹。4.4 第三步用系统注册表组织Tick顺序引擎的核心是系统按顺序给实体施加行为。这个系统注册表只要做两层登记系统和按序调用。enum class TickPhase : uint8_t { PreUpdate, // 输入处理、动画采样前置 LogicUpdate, // 游戏逻辑移动、AI、战斗 Physics // 物理模拟固定时间步 }; struct IGameSystem { virtual void Tick(float deltaTime) 0; virtual ~IGameSystem() default; }; class SystemRegistry { public: void RegisterSystem(TickPhase phase, IGameSystem* system, const char* name) { mSystems[static_castsize_t(phase)].push_back({system, name}); } void TickPhase(TickPhase phase, float deltaTime) { auto list mSystems[static_castsize_t(phase)]; for (auto entry : list) { // 可以在这里加性能标记Profiler方便后续优化定位 entry.system-Tick(deltaTime); } } private: struct SystemEntry { IGameSystem* system; const char* name; }; std::vectorSystemEntry mSystems[static_castsize_t(TickPhase::Count)]; };这段骨架的价值在于它把引擎在某一帧到底干了什么变成了可以精确控制、插桩测速、甚至热重载的流程。你可以在每次TickPhase前后打点就知道物理花了几毫秒、AI花了几毫秒、哪个系统是帧时间刺客。引擎优化最常见的起手式就是在系统调度上做性能剖析。4.5 第四步主循环把固定步长和时间累积接起来最后一步把帧循环和时间控制写出来class Engine { public: void Run() { mLastFrameTime std::chrono::steady_clock::now(); while (!mShouldQuit) { auto now std::chrono::steady_clock::now(); float frameDelta std::chrono::durationfloat(now - mLastFrameTime).count(); mLastFrameTime now; // 固定步长累积最多追4步防止死亡螺旋 mAccumulator frameDelta; int steps 0; while (mAccumulator mFixedStep steps MaxSteps) { mSystems.TickPhase(TickPhase::Physics, mFixedStep); mAccumulator - mFixedStep; steps; } mSystems.TickPhase(TickPhase::PreUpdate, frameDelta); mSystems.TickPhase(TickPhase::LogicUpdate, frameDelta); // 渲染部分这里只是占位 RenderFrame(); } } private: void RenderFrame() { /* 接入图形API后在这里提交渲染命令 */ } float mFixedStep 1.0f / 60.0f; float mAccumulator 0.0f; bool mShouldQuit false; SystemRegistry mSystems; std::chrono::time_pointstd::chrono::steady_clock mLastFrameTime; static constexpr int MaxSteps 4; };注意里头的两处用心固定步长最大追4步是防止帧率暴跌时物理更新追不上真实时间的死亡螺旋逻辑和物理分离让你在物理迭代N次时逻辑还能用真实的frameDelta去做插值。等以后你加渲染的插值逻辑时这套分离会感激不尽。5. 主循环里被忽略的致命细节Tick顺序、线程与后来者的代价骨架搭完了但这篇文章真正的重头戏才刚刚开始。很多人能搭出主循环但很少有人搭出不会在高压下翻车的主循环。下面这几个问题就是后来测试时最常给我暴击的地方。5.1 Tick顺序看起来是小问题翻车是大事故先看一个典型场景玩家按了跳跃键A系统负责把跳跃输入改成速度增量B系统负责把速度解析到位置。如果A在B之后Tick那么玩家这一帧按下的跳跃会整整晚一帧生效——在60FPS下是16毫秒延迟玩家体感手感肉、不跟手。这类问题还不是最难查的更难查的是擦边交叉依赖A系统修改了实体位置B系统依赖实体位置做试探然后又把试探结果写回实体。这个顺序谁先谁后会导致行为完全不可复现。我给你的经验法则是系统Tick阶段之间数据只能单向流动。一个阶段的系统只能读上一个阶段产出的数据写出来给下一个阶段消费。如果两个系统要互相引用数据那就抽象出一个中间共享状态而不是让两个系统直接互相调用。这里没有银弹只有设计纪律。5.2 多线程不是把系统丢到线程池就完事做引擎架构的人或多或少先得天真一次把AI、物理、渲染各丢一个线程立刻降帧。现实是系统之间数据依赖纠缠不清你强行并发只会迎来两种结局一种是你加了一堆锁性能不升反降另一种是你去掉锁然后收获数百个随机崩溃后半夜的诡异Bug之夜。业界目前主流的折中思路是单线程负责逻辑渲染和资源加载放异步线程。逻辑线程产出一个个命令Command写入无锁队列渲染线程消费命令、驱动GPU。这个设计的精妙之处在于逻辑线程完全不需要知道渲染线程在做什么渲染线程也永远不需要回调逻辑线程——两个世界的交错点被限制在一个无锁队列里。当你想进一步并行逻辑时再上Job System按数据不重叠的原则切分实体组而不是按系统功能切分。我强烈建议你在动手做多线程前先单线程跑通并隔离好命令队列。5.3 后来者的代价往一个已经跑起来的引擎加东西有多痛骨架搭完就进入了漫长的添砖加瓦阶段。这时你会遇到一个常见悲哀所有看起来独立的功能最终都会通过时机纠缠在一起。例如你想给敌人加一个死亡播报后延迟两帧爆炸的时序控制发现脚本里没有统一的延迟事件调度器于是你用协程、用计时器、用状态机各写了一遍。过了半年你想把所有延迟剥出来做时间缩放慢动作结果发现要改的地方遍布几十个脚本。这类苦头我吃得太多了所以想单独提醒你引擎骨架搭建的第一天就要留好统一的调度与事件机制来托管这类时序问题。5.4 一个承上启下的预告下一期我们要拆渲染与资源的协作逻辑写到这里第一期的核心思想已经讲得差不多了。往深了走你迟早会遇到引擎基础架构和引擎功能架构的边界。我这个系列后续会把渲染系统的场景管理、资源流的加载调度、《资源生命周期与场景切换的博弈》这些和引擎基础架构直接挂钩的内容一条条捋出来。按我的经验很多引擎的深坑不在某个渲染API上而是在资源到底什么时候加载、什么时候卸载、什么时候该预取这一连串跟基础架构强绑定决策上。下一期我们就把这块硬骨头直接端上桌。现在的你如果把这套最小骨架跑起来并且亲手模拟几个场景——比如每帧生成1000个实体再销毁一半、“逻辑线程被慢速资源加载卡住”——你会对引擎架构这个词产生完全不同的体感。强烈建议你看完本篇后动手把这几个片段组装起来跑一遍。架构的书读一百遍不如自己踩一遍主循环的坑。 
长河君 · 2026/10/8 4:30:15 · 阅读 1.2k 从零搭建游戏引擎骨架：帧循环、实体池与资源生命周期管理
1. 为什么我劝你别只盯着某个渲染特性先看引擎的架构先讲个我自己的事。几年前我在一个中型项目里做战斗系统每天跟角色动画、技能逻辑、伤害计算打交道。某天忽然冒出一个特别诡异的bug一个被击飞的敌人血条扣了动画也播了但打在它身上的特效位置完全不对再细看特效挂的坐标居然是从上一个被打死的敌人身上继承的。定位了一整天最后发现不是某个系统写错了而是整个引擎的资源生命周期管理出了问题一个Entity被销毁之后它的Transform组件没有被正确释放回池子后续新生成的特效组件刚好复用了这块内存于是视觉表现就串了。从那天起我意识到一件事在引擎里遇到的大部分奇怪的、难以定位的问题根子往往不在某个具体系统而在架构层。这也是我从会用引擎转向想理解引擎的转折点。你当然可以一辈子只当Unity、UE或Godot的熟练使用者不去管引擎内部怎么组织但一旦你遇到以下任何一种情况——想做定制管线、想写编辑器工具、想优化加载速度、想跨平台移植、甚至只是想把内存占用压下来——你会立刻发现不懂架构就寸步难行。那么游戏引擎的架构到底指什么我给你的定义是引擎负责把游戏世界里变化的东西逻辑、渲染、物理、动画和相对不变的东西资源、配置、场景数据组织起来并让它们以稳定的频率协同工作的一整套代码与数据结构的骨架。这套骨架通常包含内存管理、帧循环、事件分发、组件模型、资源生命周期、渲染/逻辑分离的调度机制等几个大板块。本系列的第一篇我就先把这块地基讲清楚引擎基础架构由哪几根大梁撑起来引擎和普通软件为什么在结构上天然不同以及如果你要从零搭一个最小可用的引擎骨架应该怎么起步。这个系列适合这么几种人引擎使用者想进阶到能改引擎甚至能二开的深度用户想做游戏开发的在校学生或刚入行的程序员想知道游戏代码和业务代码的区别到底在哪对GDC分享、引擎源码剖析感兴趣但被那一堆英文术语和庞大代码库劝退的爱好者。我会尽量用工程师跟工程师聊天的方式来讲不整虚的。2. 引擎和普通软件的三观不一样帧循环、实时性、生命周期很多写后台服务、Web应用的同事转来做游戏最常见的不适应就是游戏里没有一个请求-响应的关节取而代之的是一圈又一圈永不停歇的循环。这份差异决定了引擎架构的第一性原理。2.1 帧循环所有系统的呼吸节奏你写一个管理系统逻辑通常是等用户操作→处理→响应。引擎不是这样它在启动后就自我驱动每一帧都要完成一连串固定动作处理输入→更新逻辑→跑物理→准备渲染→提交渲染→再次回到起点。这个帧循环就是引擎的呼吸节奏。帧循环有两种常见的节奏控制方式。固定时间步Fixed Timestep物理模拟和逻辑更新按照固定的时间间隔执行比如每1/60秒更新一次好处是结果可复现、调试稳定坏处是如果帧率低于步长可能会出现为了追赶时间而连续多次更新的死亡螺旋。可变时间步Variable Timestep每帧使用真实经过的时间deltaTime来驱动好处是绘制跟得上实时坏处是物理稳定性差、不同帧率下行为不一致。成熟引擎几乎都是混合式渲染走可变时间步保证画面流动感逻辑和物理走固定时间步保证确定性。所以你会在Unity里同时看到Update()渲染帧驱动和FixedUpdate()固定步长驱动在UE里看到Tick()时也分priority和bTickEvenWhenPaused。这两套时间基准的存在是所有引擎架构设计矛盾的源头也是后面一切系统设计的隐藏前提。2.2 实时性约束19毫秒预算到底意味着什么普通软件的一个查询耗300毫秒用户顶多觉得有点慢。游戏里一帧只有约16.6毫秒60FPS下渲染往往已经占掉10~12毫秒留给逻辑、物理、动画的只有几毫秒的时间预算。这种严苛的实时预算让引擎架构产生了一个核心设计态度数据优先于抽象。你很少看到引擎的关键路径上堆满一层层接口封装因为虚函数调用、动态内存分配、隐式锁这些在业务代码里无所谓的开销在引擎热路径上都是要被消灭的对象。我见过一个很典型的反例。一个自研引擎早期用了大量shared_ptr管理组件对象逻辑写起来特别爽结果到千人同屏测试时直接卡成PPT。原因很简单shared_ptr的引用计数是原子操作大量并发的增减计数把CPU缓存都打穿了。后来改成实体池化显式free回收类似我在开头讲的那个串联bug的解法帧时间立刻降了30%。游戏引擎架构的第一课就是学会为了性能约束去放弃代码上的优雅。此外引擎架构还需要处理好生命周期的一致性。引擎里所有对象资源、实体、组件、命令都不是随用随new、用完丢给GC的类型而是有明确的创建→使用→回收阶段。一个资源可能同时被渲染、物理、音频三个系统引用如果其中一个系统还在用资源管理器就把它卸载了那就会出现我开头说的那种串数据事故。生命周期管理是引擎架构和普通软件架构最本质的分水岭之一。3. 引擎基础架构的三根支柱分层、组件模型、资源管理架构这个词听着虚落到代码层面其实就三件事。搞定这三件事你就算抓住了引擎的骨架。3.1 支柱一分层架构——渲染层永远不该知道UI按钮叫什么引擎的基础架构普遍采用分层设计。我把它简化成底下这张关系层级职责典型模块能依赖谁平台层窗口、输入、图形API封装Win32/GLFW、DX/Vulkan、音频后端谁也不依赖核心层数学库、容器、内存分配、事件Math、Vector、PoolAllocator平台层功能层具体游戏系统渲染、物理、动画、音频、UI平台层核心层游戏层玩法逻辑玩家控制器、AI、任务、战斗以上全都行工具层编辑器与调试Scene视图、Inspector以上全都行这条依赖规则的目的是避免环依赖——如果渲染层直接引用一个UI按钮类那么UI层的一个小改版都可能引起渲染层重编、甚至逻辑混乱。实际工程里引擎往往通过接口反向控制让上层系统向底层注册回调例如物理模块不知道谁在听碰撞事件它只管发消息。高层可以知道低层的存在低层做梦都不该知道高层是谁——这句规则比任何一项具体功能都金贵。3.2 支柱二实体组件模型——为什么现在人人都在谈ECS游戏场景里的物品不是替你写好的对象而是实体组件的自由组合。经典的组件模型有两种层级组件模型树状Unity的GameObject、UE的Actor组件挂在节点上节点之间是父子关系。优点是好理解、适合做场景编辑缺点是写复杂玩法时组件间通信容易绕成蛛网。数据驱动组件模型ECS实体只是一个ID所有组件数据存储在各类型的紧凑数组中系统负责遍历同时拥有A、B、C组件的实体并做处理。优点是缓存友好、便于多线程缺点是没有天然的节点树实现场景编辑器和一整套序列化反而更费劲。做架构决策时你要根据团队规模和产品类型来选。中小团队做线性关卡游戏用层级组件模型能省大量的编辑器工期千人同屏、海量简单实体子弹、粒子、单位的玩法ECS几乎是唯一解。我在实际项目里见过大量团队因为ECS听起来酷而硬上结果编辑器工具链跟不上开发效率反而腰斩。架构从来不是越新越好是越匹配越好。3.3 支柱三资源管理——所有系统都绕不开的那个中心资源管理负责的事情很朴素加载、缓存、引用计数、卸载。但做好极难。引擎里的资源类型五花八门纹理、网格、材质、动画片段、音频、预制体、关卡流送块……它们的共同点是体积大、加载慢、被多处复用。一个理性的资源管理器会把资源分为两类一类是常驻内存启动就加载的核心资源一类是按需加载进入某区域才加载、离开就卸载。引用计数用于判断还有没有人在用同时提供预加载和异步加载接口让关卡切换时不用卡死主线程。资源系统还常配合一个资源缓存目录Asset Database/GUID保证同一个物理文件在整个引擎内只有一份实体所有引用都走GUID而不是路径——这一步能根治大量路径写错导致加载失败的工程级问题。4. 亲手搭一个最小引擎骨架从空项目到能跑场景理论学习再多不动手等于没看。我建议你亲手实现一个最小引擎骨架不需要任何图形API只做调度实体管理内存池化三件事你就能真切体会到架构权衡发生在哪里。4.1 最小骨架的目标我不是要造UE而是让跑系统的系统跑起来我们要做的这个最小引擎骨架标准就三条有一个稳定的帧循环能控制固定步长和渲染步长的关系有一个实体池和管理器能创建/销毁实体而不产生旷日持久的内存泄漏有一个简单的系统注册机制让不同的Feature移动、渲染占位、AI占位按顺序Tick。我不建议一上来就碰图形API因为那会把你的注意力从架构拉到渲染细节上。等你理解了系统如何组织再把渲染接进去相当于给骨架装上肌肉顺理成章。4.2 第一步实现一个排他式的堆内存分配器引擎最需要的基本功是自己管内存。下面是一个极简的方块分配器Block Allocator它从一块大缓冲里按固定大小切块分配释放时直接标记空闲——没有碎片、速度极快class BlockAllocator { public: BlockAllocator(size_t blockSize, size_t blockCount) : mBlockSize(blockSize), mBlockCount(blockCount) { mBuffer static_castuint8_t*(::operator new(blockSize * blockCount)); mFreeList new uint32_t[blockCount]; for (uint32_t i 0; i blockCount; i) mFreeList[i] i; mFreeCount blockCount; } void* Allocate() { if (mFreeCount 0) return nullptr; uint32_t index mFreeList[--mFreeCount]; return mBuffer index * mBlockSize; } void Free(void* ptr) { uintptr_t offset static_castuint8_t*(ptr) - mBuffer; uint32_t index static_castuint32_t(offset / mBlockSize); mFreeList[mFreeCount] index; } ~BlockAllocator() { delete[] mFreeList; ::operator delete(mBuffer); } private: uint8_t* mBuffer; uint32_t* mFreeList; size_t mBlockSize; size_t mBlockCount; size_t mFreeCount; };这段代码里最关键的思维是内存分配从一个系统调用变成了数组下标的读写。分配和释放都是O(1)而且不会产生碎片。代价是你只能固定分配大小为blockSize的对象。这就是引擎架构中典型的限制自由度来换性能也是为什么游戏引擎很少用通用malloc管理高频小对象。4.3 第二步建立实体ID索引版本号的实体池实体池的设计要解决一个经典难题怎么判断一个ID到底还活着答案是用分代索引Generation Index。我给出简化版struct EntityID { uint32_t index; // 在池中的槽位 uint32_t generation; // 代际每复用一次槽位就1 }; class EntityPool { public: EntityID Create() { if (mFreeCount 0) throw std::runtime_error(池已满); uint32_t slot mFreeSlots[--mFreeCount]; mGenerations[slot]; mAlive[slot] true; return EntityID{slot, mGenerations[slot]}; } void Destroy(EntityID id) { if (!IsAlive(id)) return; mAlive[id.index] false; mFreeSlots[mFreeCount] id.index; // 注意不清空组件数据。组件数据留给组件系统去清理 } bool IsAlive(EntityID id) const { return mAlive[id.index] mGenerations[id.index] id.generation; } private: std::vectoruint32_t mFreeSlots; std::vectoruint32_t mGenerations; std::vectorbool mAlive; size_t mFreeCount 0; };为什么版本号这么重要因为一个旧的EntityID如果被推迟到下一帧用来索引数据而那个槽位已经被新实体复用数据就会错乱。加上generation校验之后旧ID在使用时会因为generation不匹配被判已死从根源上报废。这部分就是我在开场讲述的那个bug的正确解法——一个带分代校验的实体池永远不会把上一具尸体的坐标传给下一颗子弹。4.4 第三步用系统注册表组织Tick顺序引擎的核心是系统按顺序给实体施加行为。这个系统注册表只要做两层登记系统和按序调用。enum class TickPhase : uint8_t { PreUpdate, // 输入处理、动画采样前置 LogicUpdate, // 游戏逻辑移动、AI、战斗 Physics // 物理模拟固定时间步 }; struct IGameSystem { virtual void Tick(float deltaTime) 0; virtual ~IGameSystem() default; }; class SystemRegistry { public: void RegisterSystem(TickPhase phase, IGameSystem* system, const char* name) { mSystems[static_castsize_t(phase)].push_back({system, name}); } void TickPhase(TickPhase phase, float deltaTime) { auto list mSystems[static_castsize_t(phase)]; for (auto entry : list) { // 可以在这里加性能标记Profiler方便后续优化定位 entry.system-Tick(deltaTime); } } private: struct SystemEntry { IGameSystem* system; const char* name; }; std::vectorSystemEntry mSystems[static_castsize_t(TickPhase::Count)]; };这段骨架的价值在于它把引擎在某一帧到底干了什么变成了可以精确控制、插桩测速、甚至热重载的流程。你可以在每次TickPhase前后打点就知道物理花了几毫秒、AI花了几毫秒、哪个系统是帧时间刺客。引擎优化最常见的起手式就是在系统调度上做性能剖析。4.5 第四步主循环把固定步长和时间累积接起来最后一步把帧循环和时间控制写出来class Engine { public: void Run() { mLastFrameTime std::chrono::steady_clock::now(); while (!mShouldQuit) { auto now std::chrono::steady_clock::now(); float frameDelta std::chrono::durationfloat(now - mLastFrameTime).count(); mLastFrameTime now; // 固定步长累积最多追4步防止死亡螺旋 mAccumulator frameDelta; int steps 0; while (mAccumulator mFixedStep steps MaxSteps) { mSystems.TickPhase(TickPhase::Physics, mFixedStep); mAccumulator - mFixedStep; steps; } mSystems.TickPhase(TickPhase::PreUpdate, frameDelta); mSystems.TickPhase(TickPhase::LogicUpdate, frameDelta); // 渲染部分这里只是占位 RenderFrame(); } } private: void RenderFrame() { /* 接入图形API后在这里提交渲染命令 */ } float mFixedStep 1.0f / 60.0f; float mAccumulator 0.0f; bool mShouldQuit false; SystemRegistry mSystems; std::chrono::time_pointstd::chrono::steady_clock mLastFrameTime; static constexpr int MaxSteps 4; };注意里头的两处用心固定步长最大追4步是防止帧率暴跌时物理更新追不上真实时间的死亡螺旋逻辑和物理分离让你在物理迭代N次时逻辑还能用真实的frameDelta去做插值。等以后你加渲染的插值逻辑时这套分离会感激不尽。5. 主循环里被忽略的致命细节Tick顺序、线程与后来者的代价骨架搭完了但这篇文章真正的重头戏才刚刚开始。很多人能搭出主循环但很少有人搭出不会在高压下翻车的主循环。下面这几个问题就是后来测试时最常给我暴击的地方。5.1 Tick顺序看起来是小问题翻车是大事故先看一个典型场景玩家按了跳跃键A系统负责把跳跃输入改成速度增量B系统负责把速度解析到位置。如果A在B之后Tick那么玩家这一帧按下的跳跃会整整晚一帧生效——在60FPS下是16毫秒延迟玩家体感手感肉、不跟手。这类问题还不是最难查的更难查的是擦边交叉依赖A系统修改了实体位置B系统依赖实体位置做试探然后又把试探结果写回实体。这个顺序谁先谁后会导致行为完全不可复现。我给你的经验法则是系统Tick阶段之间数据只能单向流动。一个阶段的系统只能读上一个阶段产出的数据写出来给下一个阶段消费。如果两个系统要互相引用数据那就抽象出一个中间共享状态而不是让两个系统直接互相调用。这里没有银弹只有设计纪律。5.2 多线程不是把系统丢到线程池就完事做引擎架构的人或多或少先得天真一次把AI、物理、渲染各丢一个线程立刻降帧。现实是系统之间数据依赖纠缠不清你强行并发只会迎来两种结局一种是你加了一堆锁性能不升反降另一种是你去掉锁然后收获数百个随机崩溃后半夜的诡异Bug之夜。业界目前主流的折中思路是单线程负责逻辑渲染和资源加载放异步线程。逻辑线程产出一个个命令Command写入无锁队列渲染线程消费命令、驱动GPU。这个设计的精妙之处在于逻辑线程完全不需要知道渲染线程在做什么渲染线程也永远不需要回调逻辑线程——两个世界的交错点被限制在一个无锁队列里。当你想进一步并行逻辑时再上Job System按数据不重叠的原则切分实体组而不是按系统功能切分。我强烈建议你在动手做多线程前先单线程跑通并隔离好命令队列。5.3 后来者的代价往一个已经跑起来的引擎加东西有多痛骨架搭完就进入了漫长的添砖加瓦阶段。这时你会遇到一个常见悲哀所有看起来独立的功能最终都会通过时机纠缠在一起。例如你想给敌人加一个死亡播报后延迟两帧爆炸的时序控制发现脚本里没有统一的延迟事件调度器于是你用协程、用计时器、用状态机各写了一遍。过了半年你想把所有延迟剥出来做时间缩放慢动作结果发现要改的地方遍布几十个脚本。这类苦头我吃得太多了所以想单独提醒你引擎骨架搭建的第一天就要留好统一的调度与事件机制来托管这类时序问题。5.4 一个承上启下的预告下一期我们要拆渲染与资源的协作逻辑写到这里第一期的核心思想已经讲得差不多了。往深了走你迟早会遇到引擎基础架构和引擎功能架构的边界。我这个系列后续会把渲染系统的场景管理、资源流的加载调度、《资源生命周期与场景切换的博弈》这些和引擎基础架构直接挂钩的内容一条条捋出来。按我的经验很多引擎的深坑不在某个渲染API上而是在资源到底什么时候加载、什么时候卸载、什么时候该预取这一连串跟基础架构强绑定决策上。下一期我们就把这块硬骨头直接端上桌。现在的你如果把这套最小骨架跑起来并且亲手模拟几个场景——比如每帧生成1000个实体再销毁一半、“逻辑线程被慢速资源加载卡住”——你会对引擎架构这个词产生完全不同的体感。强烈建议你看完本篇后动手把这几个片段组装起来跑一遍。架构的书读一百遍不如自己踩一遍主循环的坑。