企业官网建设流程全解析

《Unreal 对 C++ 做了什么》系列 (08/54)

08. 容器的进化：TArray, TMap, TSet 与性能陷阱 📦

🚀 导言：为什么不用 std::vector？

很多刚从标准 C++ 转到 UE 的开发者会问：“既然已经有了成熟的 STL，为什么 UE 还要自己写一套容器？”

答案主要有三点：

1. 反射集成：标准 STL 容器无法被UPROPERTY识别，引擎无法知道容器里装了什么，也就无法进行自动序列化和 GC 追踪。
2. 内存控制：UE 需要精准控制内存分配（通过FMemory），以便在不同游戏平台上进行内存对齐和池化管理。
3. 二进制兼容性：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

⚠️ 性能避坑指南

1. 频繁 Add 的代价：在循环里不断Add。

• 修正：先Reserve足够空间。

2. 大对象的传参：直接传递整个TArray会触发深拷贝。

• 修正：始终使用常量引用传递：const TArray<int32>& MyArray。

3. TMap 的 Key 选择：

• 如果你用FString做 Key，性能尚可。
• 如果你追求极致性能，请改用FName。因为FName本质上是一个整数 ID，哈希计算速度极快。

结语

UE 的容器不仅仅是数据的仓库，它们是反射系统的一部分。TArray 是你的首选，因为它对 CPU 缓存最友好；只有在需要高速查找时才考虑TMap/TSet。记住：永远给存储 UObject 指针的容器加上UPROPERTY()，这是保命的准则。

下一篇我们将探讨：《09. 字符串的“三重奏”：FName, FText, FString 的分工与转换》。我们将看看为什么 UE 这么麻烦，非要设计三种不同的字符串类型。