字符串与唯一标识符

字符串的问题（卷 I 6.4.1）

• 存储与管理：C/C++ 中字符串不是原子类型，变长导致要么限定长度、要么动态分配缓冲。
• 本地化：面向玩家的字符串都要翻译，涉及字形、书写方向、译文长短差异，见 游戏本地化与 Unicode。
• 内部字符串：资源文件名、对象 ID（设计师给关卡对象起「PlayerCamera」「enemy-tank-01」「explosionTrigger」这样的名字）。比较整数或浮点是一条机器指令，比较字符串要 strcmp() 做 $O(n)$ 扫描，复制要 $O(n)$ 拷贝甚至动态分配。作者在某项目中做性能分析，发现 strcmp() 和 strcpy() 是最贵的两个函数；去掉不必要的字符串操作并采用本节技术后，它们几乎从分析结果中消失，帧率显著提高（他也听其他工作室讲过类似故事）。

字符串类（卷 I 6.4.2）

• std::string 等字符串类方便，但有隐藏成本：C 风格数组传参通常只是把首字符地址放进寄存器；字符串对象若声明或使用不当会触发拷贝构造，可能动态分配，让看似无害的调用花费数千个周期。
• 作者通常在运行时游戏代码中避免字符串类。若要用，先了解它：缓冲是否只读？是否用写时复制 (copy on write)？有无移动构造？是否拥有内存，还是能引用不归它所有的内存？经验法则：字符串对象总是按引用传递，绝不按值传递；尽早、经常做性能分析。
• 例外：路径类。Path 类可提供提取文件名、扩展名、目录的函数，并屏蔽操作系统差异（如把 Windows 反斜杠转换为 UNIX 正斜杠），跨平台实现很有价值（GEA 7.1.1.4 节有更多讨论）。

唯一标识符与字符串 ID（卷 I 6.4.3）

• 游戏对象（如吃豆人里的「pac_man」「blinky」「pinky」「inky」「clyde」）和构成它们的资产（网格、材质、纹理、音频、动画）都需要唯一标识。字符串很自然：资产常是磁盘文件，可用路径唯一标识；设计师也更愿意起可读名字，而不是记整数索引或 64/128 位 GUID。但比较速度至关重要，strcmp() 太慢。
• 哈希字符串 ID（卷 I 6.4.3.1）：把字符串哈希成「半唯一」整数，比较就是整数比较；把原字符串存进哈希表，就能由哈希码找回原字符串，用于调试、屏幕显示和日志。游戏程序员常称之为 string id，Unreal 称为 name（FName 类）。
• 冲突：32 位哈希有四十多亿个值，好的哈希函数下合理输入几乎不会冲突。Naughty Dog 最初用 CRC-32 的变体，在《神秘海域》《最后生还者》多年开发中只遇到过几次冲突，修复也只需稍改其中一个字符串（加「2」或「b」，或换个同义词）。自《最后生还者 第二部》起改用 64 位哈希，按单个游戏的字符串数量和典型长度，基本消除了冲突可能。（哈希函数对比见 容器与哈希表。）

实现要点（卷 I 6.4.3.2）

• 何时哈希：多数引擎在运行时哈希。Naughty Dog 允许运行时哈希，同时用 C++ 用户自定义字面量把 "any_string"_sid 在编译期变成整数，于是 string id 能用在任何需要整型常量的地方，包括 switch 的 case 标签（运行时函数调用的结果不是常量，不能作 case 标签）。
• 驻留 (interning)：生成 string id 时通常还把字符串加入全局字符串表以便日后找回。工具链也可以预先把字符串哈希好，引擎读到的数据里已经是 ID。
• 驻留很慢（运行哈希、为字符串分配内存并复制进表），所以（非编译期生成时）每个字符串只驻留一次并保存结果：

static StringId sid_foo = internString("foo");   // 好：只驻留一次
void f(StringId id) { if (id == sid_foo) { /* ... */ } }
// 差：每次调用 f() 都重新驻留
void g(StringId id) { if (id == internString("foo")) { /* ... */ } }

• internString() 的一种实现：StringId sid = hashCrc32(str)，若全局 HashTable<StringId, const char*> 中没有该 sid，则存入 strdup(str)（复制一份，以防原字符串是动态分配的、之后会被释放）。原书问题：书中代码声明的表名是 gStringIdTable，但 if 判断和插入处写成了 gStringTable，照抄无法编译，应统一为同一个变量名。另外该实现只按哈希值查表，不比较已存字符串与 str 是否相同，所以发生冲突时会静默返回同一 ID；实际使用时宜在开发版中检测（表中已存在该 sid 但字符串不同则报错），以便按上文做法改名。
• 包装成小类：Unreal 把 string id 和指向对应 C 字符数组的指针包进 FName；Naughty Dog 同样把 ID 包进 StringId 类，并写了自定义字面量运算符，使 SID("any_string") 生成该类实例，哈希值由 "any_string"_sid 产生。
• 字符串放调试内存：发售版游戏只用 ID，字符串仅供人看，所以字符串表可以放在零售机上不存在的内存区域。例：PS5 开发机除 16 GiB 零售内存外还有 16 GiB「调试内存」（debug / development / dev memory）。这样字符串不占最终游戏的内存——但绝不能写依赖这些字符串存在的产品代码（构建配置见 构建配置与编译优化）。

与 UE5 FName 的对照

• GEA 把 FName 描述为「string id + 指向 C 字符数组的指针」的小类，归入哈希字符串 ID 一类。
• 容器与字符串（依据 UE 5.8 官方文档）则记录 FName 存的是全局字符串表中的索引和实例号，用哈希表完成字符串到 FName 的转换，== 只比较索引，且不区分大小写。
• 两种说法的共同点是「比较只需整数比较、原字符串在全局表中可找回」；具体存储内容不同，以官方文档描述的 UE 5.8 为准，GEA 的描述可视为对这一类设计的概括。GEA 未提大小写问题，而不区分大小写正是 UE 文档中 FString→FName 转换会丢信息的原因。

取舍小结