资源管理器

运行时资源管理器的职责（卷 I 7.2.2.1）

• 保证每个唯一资源在任意时刻只有一份在内存中；
• 管理每个资源的生命周期，加载需要的、卸载不再需要的；
• 加载复合资源（由其他资源构成，如 3D 模型 = 网格 + 材质 + 纹理 + 可选骨骼与动画）；
• 维护引用完整性：内部（单个资源内的交叉引用）与外部（资源之间），加载复合资源时确保子资源都载入并正确修补交叉引用；
• 管理已加载资源的内存，放到合适的位置；
• 允许按资源类型做加载后的自定义处理（logging in / 加载初始化）；
• 通常（但不总是）提供统一接口管理各种资源，并易于扩展新类型；
• 引擎支持时，处理流式（异步）加载（见 引擎文件系统与异步文件读写）。

文件与目录组织（卷 I 7.2.2.2）

• 有的引擎（通常是 PC 引擎）每个资源一个「散」文件，目录树主要为创作者方便而设计，引擎不在乎文件放在哪。书中假想游戏《Space Evaders》的树：Resources/NPC/{Pirate,Marine}、Player、Weapons/{Pistol,Rifle,BFG}、Levels/{Level1,Level2}、Objects/{Crate,Barrel}（「无处不在的可破坏箱子和爆炸桶」）。
• 有的引擎把多个资源打包进一个文件：OGRE 允许散文件或大 ZIP 包中的虚拟文件（ZIP 是开放格式，zlib 完全免费，zziplib 为 LGPL）；PlayStation 用 psarc 归档；Unreal 要求所有资源都在专有格式的包 (package / pak) 中，不允许散文件，由 UnrealEd 创建和管理。
• 归档格式的四个好处：
  1. 虚拟文件「记得」相对路径，挂载后的归档看起来就像文件系统；OGRE 和 PlayStation 的 FIOS 都用形如路径的字符串标识资源，程序员多数时候无需关心是散文件还是归档中的虚拟文件。
  2. 可压缩：省磁盘，更重要的是加载更快——尤其从比硬盘和 SSD 慢得多的蓝光盘读取时，解压开销常被少读数据省下的时间抵消。PS5 有专用硬件以极高速度解压 Oodle 格式（RAD Game Tools 开发的高效压缩算法）的 psarc，不占 CPU。
  3. I/O 更高效：机械硬盘上三大开销是寻道、打开每个文件、读数据，前两者不可忽视，单个大文件能把它们降到最低。SSD 没有寻道问题；PS5 和 Xbox Series X 都以高速 M.2 SSD 为主存储，所以寻道只在读蓝光盘时才是问题。
  4. 促进模块化：Naughty Dog 支持 N 种语言时，每个文本和音频资产有 N 个版本，同名但放在 N 个不同的 psarc 中；运行时只挂载玩家所选语言的归档，切换语言时卸载旧的、挂载新的，引擎其他部分无需知道当前语言（本地化见 游戏本地化与 Unicode）。

资源文件格式（卷 I 7.2.2.3）

• 有的用开放标准格式：纹理用 TGA、PNG、TIFF、JPEG、BMP，或 DirectX 的 S3TC（DXTn/DXTC）压缩格式；网格从 Maya、Lightwave 导出为 OBJ 或 COLLADA。
• 一种格式也可装多种资产，如 RAD Game Tools 的 Granny SDK 格式可存网格、骨骼层级和骨骼动画（几乎可改作存任何数据）。
• 许多引擎自定义格式：标准格式缺少所需信息；或为了尽量把处理放到离线，以缩短运行时加载处理时间——例如数据需要特定内存布局时，用原始二进制格式，由离线工具排好布局。

资源 GUID（卷 I 7.2.2.4）

• 每个资源都要有全局唯一标识符 (GUID)。最常见的是资源的文件系统路径（存为字符串或 32 位哈希）：直观、映射到磁盘文件，且操作系统保证路径唯一。
• 也有引擎用不直观的 GUID，如由工具分配并保证唯一的 128 位哈希。
• Unreal 的资源在大包文件里，包路径不能唯一标识单个资源（GEA 这里的描述对应 UE3 时代；现行 UE4/UE5 编辑器中通常一个资产一个 .uasset 包文件，.pak/IoStore 容器只是烘焙打包后的发行形式——见 烘焙、打包与 Zen 加载器 及 Epic 文档「Cooking Content and Creating Chunks」。书中「Unreal 不允许散文件、所有资源必须在大包中」的说法因此只适用于旧版），所以包内组织成文件夹层级，GUID = 包名 + 包内路径。例：《战争机器》中 Locust_Boomer.PhysicalMaterials.LocustBoomerLeather 指 Locust_Boomer 包里 PhysicalMaterials 文件夹下名为 LocustBoomerLeather 的材质。（字符串 ID 见 字符串与唯一标识符。）

资源注册表（卷 I 7.2.2.5）

• 为保证唯一副本，多数资源管理器维护已加载资源的注册表，最简单就是字典：键为 GUID，值为指向内存中资源的指针（字典实现见 容器与哈希表）。加载时加入、卸载时移除；请求时按 GUID 查找，找到返回指针，找不到则自动加载或返回失败码。
• 找不到就自动加载看似直观，有些引擎也这么做，但问题严重：加载很慢（定位打开文件、从可能很慢的蓝光盘读大量数据、可能还要加载后初始化），游戏中途请求会造成明显卡顿甚至数秒冻结。所以引擎通常二选一：
  1. 游戏进行中完全禁止加载：关卡全部资源在开始前集中加载，玩家看读取画面或进度条；
  2. 异步加载（流式）：玩家在关卡 X 时后台加载关卡 Y。体验无读取画面，更好，但实现难得多。

资源生命周期（卷 I 7.2.2.6）

生命周期是从首次载入到内存被回收挪作他用的时间段。资源管理器可以自动管理，或提供 API 让游戏手动管理。

• 何时加载容易回答（玩家首次见到之前），何时卸载难：很多资源跨关卡共享，不能在关卡 X 结束时卸载、又因关卡 Y 立刻重新加载。
• 引用计数方案：加载新关卡时遍历其资源表，每个资源计数 +1（先不加载）；再遍历不再需要的关卡的资源，计数 −1，降到 0 的卸载；最后加载计数刚从 0 变 1 的资源。
• 书中表 7.2 的例子：关卡 X 用 A、B、C，关卡 Y 用 B、C、D、E（B、C 共享）。

括号表示正在加载或卸载（原书用粗体表示在内存中、灰底表示不在内存中）。B、C 始终留在内存中，没有被卸载后再加载。

资源的内存管理（卷 I 7.2.2.7）

资源加载后放哪里与内存管理密切相关：纹理、顶点缓冲、索引缓冲、着色器代码等必须在显存（PS4 上是映射为经高速「garlic」总线访问的内存块）；其余多数可在主内存，但不同资源可能放在不同地址范围（常驻的全局资源一处，频繁加载卸载的另一处）。内存分配子系统的设计常与资源管理器紧密相关——可能为现有分配器设计资源管理器，也可能反过来。核心问题是加载卸载时避免碎片（见 自定义内存分配器）。

• 资源块分配器（GEA 自拟的名字）：维护所有含空闲空间的块及其空闲区域的链表，从中按任意策略分配（如用通用堆管理空闲链表，或在每块空闲区映射一个小栈分配器）。问题是块只能整块释放，块里分配的内存会随资源卸载「凭空消失」。解决：只用某关卡的块满足生命周期与该关卡一致的请求，分配器按关卡分别管理，调用者需指明为哪个关卡分配。由于加载资源时除文件本身外通常还要动态分配内存，这能有效回收原本浪费的块空间。
• 分段资源文件：一个资源文件含 1–4 个段 (section)，每段再分块：主内存数据段、显存数据段、加载期间临时使用后丢弃的段、调试信息段（调试模式加载，最终发行版根本不加载）。
• PS5 的 AMPR：AMM 库控制物理到虚拟页映射，APR 库向 M.2 SSD 和硬件解压器发送命令列表。Naughty Dog 最近把大部分资产加载改为基于 AMPR：预分配一大段连续虚拟地址，每个资产映射到其中一个子范围；流入时让 AMM 为该范围映射物理页，再让 APR 把数据加载并解压进去；流出时只需让 AMM 取消映射，物理页回到空闲池供其他资产复用。（AMPR 介绍见 引擎文件系统与异步文件读写。）

与 UE5 的对照

UE5 的运行时资产引用与异步加载见 资产管理与异步加载。GEA 对 Unreal 的描述（包文件、包名 + 包内路径作 GUID、UnrealEd 管理）是概念层面的，具体机制以该页的 UE 官方来源为准。