《Unreal 对 C++ 做了什么》系列 (08/54)
08. 容器的进化：TArray, TMap, TSet 与性能陷阱 📦
🚀 导言：为什么不用 std::vector？
很多刚从标准 C++ 转到 UE 的开发者会问：“既然已经有了成熟的 STL，为什么 UE 还要自己写一套容器？”
答案主要有三点：
- 反射集成：标准 STL 容器无法被
UPROPERTY识别，引擎无法知道容器里装了什么，也就无法进行自动序列化和 GC 追踪。 - 内存控制：UE 需要精准控制内存分配（通过
FMemory），以便在不同游戏平台上进行内存对齐和池化管理。 - 二进制兼容性：STL 的实现在不同编译器（MSVC vs Clang）之间存在差异，而 UE 的容器在所有平台上行为完全统一。
🔑 TArray：虚幻中最勤劳的“打工人”
TArray是 UE 中最常用的容器，对应std::vector。它将元素存储在一段连续的内存中。
1. 内存增长策略（Slack）
当你向TArray添加元素时，它并不总是只申请刚好足够的内存。
- Slack（余量）：为了避免频繁重新分配内存，
TArray会预留一些空闲空间。 - 性能技巧：如果你预知要装 1000 个元素，请务必使用
Reserve(1000)。这能将 N 次内存重分配减少为 1 次。
2. 移除元素的陷阱
在连续内存中删除中间元素，会导致后面的元素全部前移，时间复杂度为 。
- 优化方案：如果你不介意元素的顺序，请使用
RemoveAtSwap(Index)。它会将目标元素与数组末尾元素交换，然后直接删除末尾，时间复杂度降为 。
🔑 TMap 与 TSet：高效的哈希世界
- TSet：对应
std::unordered_set。用于快速查找、去重。 - TMap：对应
std::unordered_map。存储键值对（Key-Value）。
UE 的独特之处：
与 STL 的std::map（通常是红黑树）不同，UE 的TMap默认是**基于哈希（Hash）**的。
- 稀疏数组架构：UE 的哈希容器底层使用的是“哈希索引 + 稀疏数组”。这意味着即使你删除了中间的元素，容器也不会立刻压缩内存，而是留下“空洞（Hole）”，以保证其他元素的内存地址相对稳定。
🔗 容器与反射系统的“化学反应”
这是 UE 对容器做的最核心改造：让容器感知对象。
UCLASS()classAMyInventory:publicAActor{GENERATED_BODY()// 1. 自动序列化：引擎会自动把数组里的数据存入 .uasset// 2. GC 追踪：如果数组存的是 UObject*，GC 会确保它们不被误杀UPROPERTY(EditAnywhere,BlueprintReadWrite)TArray<UItem*>Items;// 3. 蓝图暴露：蓝图可以直接操作这个 TMapUPROPERTY(EditAnywhere)TMap<FString,int32>ItemScores;};极其重要的警告：
如果你的TArray存储的是UObject*（比如TArray<AActor*>），但你没有加UPROPERTY()，那么 GC 系统将看不见这些引用。
- 后果：数组里的指针所指向的对象会被 GC 回收掉，你的数组里会剩下一堆指向非法内存的野指针。一旦访问，直接 Crash。
📊 核心对比：UE 容器 vs. STL
| 特性 | UE 容器 (TArray/TMap) | 标准 C++ (std::vector/map) |
|---|---|---|
| 内存分配器 | 使用FMemory（可预测、平台优化） | 使用默认std::allocator |
| 反射支持 | 支持(加 UPROPERTY 即可) | 不支持 |
| 蓝图接口 | 完美支持 | 不支持 |
| 字符串集成 | 与FString/FName深度集成 | 需手动转换 |
| 迭代器安全性 | 相对较弱（删除操作易导致失效） | 较强 |
⚠️ 性能避坑指南
- 频繁 Add 的代价：在循环里不断
Add。
- 修正：先
Reserve足够空间。
- 大对象的传参：直接传递整个
TArray会触发深拷贝。
- 修正：始终使用常量引用传递：
const TArray<int32>& MyArray。
- TMap 的 Key 选择：
- 如果你用
FString做 Key，性能尚可。 - 如果你追求极致性能，请改用
FName。因为FName本质上是一个整数 ID，哈希计算速度极快。
结语
UE 的容器不仅仅是数据的仓库，它们是反射系统的一部分。TArray 是你的首选，因为它对 CPU 缓存最友好；只有在需要高速查找时才考虑TMap/TSet。记住：永远给存储 UObject 指针的容器加上UPROPERTY()，这是保命的准则。
下一篇我们将探讨：《09. 字符串的“三重奏”：FName, FText, FString 的分工与转换》。我们将看看为什么 UE 这么麻烦，非要设计三种不同的字符串类型。
