引擎运行时架构总览

1. 静态结构：分层与分界线

• 引擎自下而上是：目标硬件、驱动、操作系统、第三方 SDK、平台无关层、核心系统（断言、内存分配、数学、容器、字符串 id、反射与序列化、句柄等）、资源管理器、各大子系统（渲染、碰撞物理、动画、音频、HID、网络、剖析调试），再到游戏性基础层和游戏专属子系统。规则是上层依赖下层、反之不行，否则形成循环依赖。见 运行时引擎分层架构。
• 游戏与引擎之间如果能划线，就在游戏专属子系统与游戏性基础层之间，但实际上是一片渐变的模糊地带；GEA 第 17 章称这一层为玩法基础系统，并指出各引擎差异在这里最大。见 运行时对象模型架构。
• UE 的对应：渲染线程、场景代理与 RHI 对应"底层渲染器 + 场景与剔除层"（UE5 渲染架构），Actor/组件、GameMode 等属于游戏性基础层的一种实现（Gameplay 框架）。

2. 生命周期：启动与关闭

• C++ 全局/静态对象的构造析构顺序不可控，GEA 推荐单例管理器的构造析构什么也不做，在 main() 里按依赖顺序显式调用 startUp()，关闭时大致反序；"蛮力法总是胜出"，因为简单、显式、易调试。真实引擎（Naughty Dog）的启动还包括异常处理、专用对齐堆、配置文件、文件系统等。见 子系统启动与关闭。
• 启动时还会载入常驻 (LSR) 资源并记录栈标记，此后关卡资源在其上加载卸载。见 游戏世界的加载与流送 与 资源管理器。

3. 一帧之内：主循环与更新调度

下图把几页中的内容合成一帧的典型顺序（以 GEA 的分阶段、分桶循环为骨架，示意图）：

flowchart TB
  A["读取输入 HID"] --> B["推进时钟，得到 Δt"]
  B --> C["对每个桶：<br/>对象 PreAnimUpdate → 动画中间姿势 → 对象 PostAnimUpdate →<br/>布娃娃/物理/碰撞 → 最终姿势与矩阵调色板 → 对象 FinalUpdate"]
  C --> D["分发排队事件"]
  D --> E["音频等其他子系统批量更新"]
  E --> F["渲染：提交场景并交换缓冲"]

• 主循环：各子系统需要的频率不同（动画 30/60 Hz，物理可能更高，AI 每秒一两次），最简单是一个主循环更新一切；架构风格有消息泵、回调框架和基于事件的更新。时间步长上 GPP 推荐"固定更新步长、可变渲染"，GEA 认为多数引擎用测得的 Δt 并配合帧率调控，两者并列见 游戏循环与更新方法 和 游戏时间线与时钟。
• 批量更新：子系统由主循环直接驱动、批量处理，对象只修改子系统中属于自己的状态（网格实例的可见性、要播放的动画）。好处是缓存一致性、少重复计算、资源复用、便于分散/汇集。见 游戏对象的实时更新。
• 顺序约束：子系统之间（动画 ↔ 布娃娃物理）和对象之间（人抱着猫）都有依赖。GEA 的手段是分阶段钩子（最好是回调注册）和按依赖森林分桶；UE 对应的是 Tick 组和 Tick 依赖（委托与 Tick 机制）。物理在循环中的位置见 物理引擎与游戏的集成。
• 一致性规则："所有对象的状态在更新循环之前和之后一致，循环之中可能不一致。"违反它会出现一帧延迟；对策是状态缓存、时间戳和桶号断言。GPP 对"依次更新"的看法更乐观，两种观点并列记录在 游戏循环与更新方法。
• 事件分发也要嵌在循环里合适的位置（例如先更新动画时钟、再分发 EndOfAnimation 事件、再开始混合），否则会多出一帧延迟。见 事件与消息传递。

4. 多核：把一帧拆成作业

• 子系统各自启动多个作业（如每个需要混合的对象一个动画作业），接口要线程安全；对象代码要异步思考：尽早发起请求、尽晚取结果。见 作业系统 与 游戏对象并发更新。
• 并行度受依赖限制，每个依赖都是同步点；推迟同步点能减少空等（"优化并发设计的秘诀是延迟"）。
• 对象模型本身也能并行：Naughty Dog 让每个桶内的对象更新成为作业，跨桶访问免锁，同桶读快照、写用锁或请求队列。纤程作业让"阻塞等待射线结果"这类写法重新可行。
• 这与性能预算的关系见 帧时间预算与渲染性能。

5. 玩法基础系统：对象、事件、脚本、世界

• 对象模型：以对象为中心（单体层次 → 组合与组件）或以属性为中心（属性表、SoA）；UE 的 Actor/组件与 MassEntity 分别靠近两端。见 运行时对象模型架构。
• 对象从哪里来：世界块中的生成器（类型 id + 键值对）在运行时按类型实例化对象，类型模式和默认值把编辑器与运行时解耦。见 世界块数据格式与生成器。
• 对象之间如何找到和通信：句柄/智能指针/裸指针各有取舍，查询靠专用加速结构；通信靠事件对象（可排队、可转发、可多播）。见 游戏对象引用与查询、事件与消息传递。
• 谁来写玩法逻辑：脚本（文本或图形，如 UE 蓝图）把行为交给策划，代价是 VM 性能和调试成本。见 游戏脚本系统。
• 世界如何进出内存：从一关一载到气闸，再到细粒度流送和加载区域；UE5 的世界分区以网格和流送源自动完成。见 游戏世界的加载与流送。
• 游戏如何推进：高层流程常是状态机，Naughty Dog 的任务图还支持并行任务。见 游戏世界与游戏对象。

6. 贯穿全局的取舍

• 解耦 vs 性能：分层、事件、脚本、组件都在换取灵活性，代价是间接层和缓存不友好；数据导向与批量更新则反过来。GPP 视角的整体讨论见 游戏编程模式选型：解耦与性能。
• 内存是一等约束：分配器、流送和对象生成策略决定了引擎能否长时间稳定运行，见 游戏中的内存管理。