Unreal是如何驾驭内存的 第11章 字符串与名称系统——FName、FString、FText

第11章 字符串与名称系统——FName、FString、FText

UE提供了三种截然不同性格的字符串类型。FName是一个不可变标识符，整个进程只存一份字符串正文，实例仅占8字节；FString是一条普通的堆字符串，和std::string定位类似但缺少短字符串优化；FText则为用户可见的本地化文本而生，内部维护着一套从源文本到译文的重建链。三者的内存成本、转换代价和适用场景各不相同，本章逐一展开。

11.1 三种字符串的定位

FName的角色是标识符和键。它将字符串正文存储在全局名称池中，实例只保留一个4字节索引加一个4字节数字后缀。因此10 000个Actor即使都叫同一个名字，也只占80 KB左右的实例空间加上池中一份约30字节的正文。FName最常见的用途包括资产名、属性名、行名和Tag。

FString是通用可变字符串，内部就是一个TArray<TCHAR>。它支持拼接、替换、格式化，但每次操作都可能引发堆分配和复制。日志输出、路径拼接和各类运行时格式化通常使用FString。

FText面向用户可见的UI文本。它内部持有一个线程安全的共享引用TSharedRef<ITextData>，指向一组带有本地化元数据的文本数据。同一段用LOCTEXT定义的文本在内存中只存一份，被多处UI控件共享；切换语言时，FText能根据自身的重建历史自动查找新语言的译文。

三者之间有一条清晰的分工线：如果这段文字要显示给玩家，用FText；如果它是一个在代码内部流转的标识符或字典键，用FName；如果需要对字符串做拼接、截取或格式化操作，用FString。

11.2 FName——高性能标识符

11.2.1 为什么需要FName

游戏引擎中充斥着"名字"——资产名、骨骼名、属性名、标签。这些名字有三个共同特征：字典量有限，通常在几千到几万个不同名字的范围内；频繁参与比较和查找；创建后极少修改。如果用FString来存储，大量重复的字符串会带来冗余堆分配，而逐字符比较的O(N)成本在热路径上也难以接受。

FName的方案是全局去重存储加整数ID比较：字符串正文只在全局池中保留一份，每个FName实例只是一个8字节的"门牌号"，比较两个FName等同于比较两个int32。这一设计使得FName在TMap查找、属性匹配、标签过滤等场景中成为最优的键类型。

11.2.2 FName的内存布局——仅8字节

classFName{private:FNameEntryId ComparisonIndex;// 4字节：在全局名称表中的索引uint32 Number;// 4字节：数字后缀（如 "Bone_3" 中的3）// 总计：8字节};

Number字段的巧妙之处在于：引擎中大量名字带有数字后缀（Bone_0、Bone_1、MeshComponent_3），它们共享池中同一个"Bone"或"MeshComponent"条目，仅靠Number字段区分。这避免了为每个后缀变体在池中多存一份字符串。当Number为0时表示没有后缀，FName(“Bone”)的Number就是0。一个骨骼模型可能有200根骨骼，名为Bone_0到Bone_199——如果每个后缀都单独占一个池条目，就是200条约4 KB的池空间；而用Number字段表示后缀，只需一条约20字节的"Bone"条目。

11.2.3 FName全局池——FNamePool

classFNamePool{staticconstexprint32 ShardBits=8;staticconstexprint32 NumShards=1<<ShardBits;// 256个分片structFShard{mutableFRWLock Lock;FNameEntryAllocator Allocator;TMap<uint64,FNameEntryId>LookupMap;};FShard Shards[NumShards];FShard&GetShard(uint32 Hash){returnShards[Hash&(NumShards-1)];}};

名称池将条目分散到256个Shard中，每个Shard有自己的读写锁。创建FName时先计算字符串哈希，据此选中目标Shard，在该Shard的LookupMap中查找。若已存在则直接返回索引；若不存在则在该Shard的Allocator中分配一条新的FNameEntry并插入映射表。分片设计使得多线程同时创建不同名字时，绝大多数操作落入不同Shard，锁竞争极低。

读操作（查找已存在的名字）只需获取读锁，多个线程可以并发读同一个Shard而互不阻塞。只有当需要插入新名字时才升级为写锁。在引擎启动完成、大部分名字已注册之后，运行时的FName构造几乎全是读操作，锁开销可以忽略不计。

11.2.4 FNameEntry——条目结构

structFNameEntry{FNameEntryId ComparisonId;FNameEntryHeader Header;// 之后紧跟字符串数据（窄字符或宽字符）};structFNameEntryHeader{uint16 Len:10;// 字符串长度（最大1023）uint16 bIsWide:1;// 是否宽字符};

FNameEntry将字符串内容直接追加在Header后面，不额外分配内存。对于纯ASCII的名字（变量名、路径中的字母数字部分），bIsWide为0，每个字符仅占1字节，比TCHAR的2字节节省一半空间。包含CJK或其他非ASCII字符的名字则以宽字符形式存储。条目的Len字段只有10bit，意味着单个FName的字符串长度上限为1023个字符——对于标识符来说绰绰有余。

11.2.5 内存统计

一个名称字符串在全局池中只存储一次：

假设有10,000个Actor都叫 "Blueprint_Actor"： FString方案：10,000 × ~40字节 = ~400 KB FName方案： 全局池：1 × ~30字节 = 30字节 实例：10,000 × 8字节 = 80 KB 总计：~80 KB 节省：400KB → 80KB (80%节省)

在一个中等规模的UE项目中，全局名称池通常包含数万到十几万个不同名字。假设平均每个名字8个ASCII字符，加上FNameEntry的头部和对齐，每条目约20字节。10万条目的池本身约2 MB，而这10万个名字被引擎中成千上万处引用时，每处引用只花8字节，与用FString的方案相比节省的内存往往达到数百MB级别。

11.2.6 FName的比较与大小写

// FName比较 = 两个int32比较booloperator==(constFName&Other)const{returnComparisonIndex==Other.ComparisonIndex&&Number==Other.Number;// 相当于比较两个int64，O(1)}

FName的比较默认忽略大小写。在创建时引擎会将字符串转为一种规范化的大小写无关形式来计算ComparisonIndex，因此FName("Weapon")和FName("weapon")得到相同的ComparisonIndex，==比较返回true。这与文件系统的行为一致——Windows上文件名不区分大小写，UE选择在FName层面保持同样的语义。

如果确实需要区分大小写进行比较，可以使用FName::IsEqual(Other, ENameCase::CaseSensitive)。但要注意这条路径需要从池中取出原始字符串逐字符对比，退化为O(N)操作，失去了FName的速度优势。

11.2.7 FName的常见操作与代价

值得注意的是，"创建"操作即使名字已存在，也需要O(N)时间来计算字符串哈希。在循环中反复用同一个字面量构造FName不是零成本操作——应在循环外构造一次，在循环内复用。引擎代码中大量使用static const FName局部静态变量正是这种优化模式：

voidSomeFunction(){// 只在第一次调用时构造，后续直接复用staticconstFNameHealthName(TEXT("Health"));if(PropertyName==HealthName){// ...}}

11.2.8 FName池的生命周期与碎片化

FNamePool的条目一旦创建便永远不会被释放。这是刻意的设计决策：FName实例遍布引擎各处——UObject的名字、UPROPERTY的属性名、资产注册表的键——如果池中的条目被回收，所有持有该索引的FName都会变成悬挂引用，追踪这些持有者在实践中不可行。代价是名称池只增不减。

FNameEntryAllocator在每个Shard内部以Block为单位分配内存。新条目从当前Block的尾部顺序追加，满了就申请一个新Block。由于条目长度不等且从不释放，Block中可能存在短条目和长条目交错的局面，但因为条目不会被删除，不存在传统意义上的碎片空洞——只是空间无法回收。

在编辑器中长期工作、反复导入删除资产的场景下，名称池会持续增长。每次导入一个新资产，其中包含的所有FName（材质名、纹理名、骨骼名等）都会注册到池中；即使之后删除该资产，这些名字仍然留在池里。一个大型项目在编辑器中运行数小时后，池可能增长到20-50 MB。发布构建中由于内容经过Cook、名称集合相对确定，池的大小通常稳定在项目实际需要的规模内。

可以通过FName::GetNameTableMemorySize()在运行时查询当前池的总字节数，用于内存报告或预算监控。如果发现池异常庞大，往往说明存在程序化生成大量唯一名称的代码——这是下面要讨论的问题。

11.2.9 程序化名称生成的陷阱

对于需要在运行时动态创建大量对象并赋予不同名字的场景（例如弹幕游戏中生成上万个投射物），需要意识到每个唯一字符串都会在池中永久占据一个条目。如果用FString::Printf(TEXT("Projectile_%d"), Index)来为每个投射物命名，一万个不同的Index就是一万条不可回收的池条目。

更经济的做法是利用FName自带的Number字段。FName在解析字符串时会自动识别尾部的_N模式：所有"Projectile_0"到"Projectile_9999"共享池中同一个"Projectile"条目，Number字段存储各自的数字后缀，池里只增加一条记录而非一万条。代码上只需直接传入带后缀的字符串，FName的构造逻辑会自动拆分：

// 这些FName共享同一个池条目 "Projectile", Number分别为 0, 1, 2FNameName0(TEXT("Projectile_0"));FNameName1(TEXT("Projectile_1"));FNameName2(TEXT("Projectile_2"));// 池中只有一个 "Projectile" 条目

如果投射物不需要有名字（纯粹的数据对象），最干净的方案是使用NAME_None或者直接用FStruct而非UObject——从根本上避开FName池的增长。

11.3 FString——通用堆字符串

FString是UE中最平凡也最常用的字符串类型。它本质上就是一个TArray<TCHAR>的薄封装，继承了TArray的增长策略、内存量化和移动语义。理解FString的内存行为，很大程度上等同于理解"一个元素为2字节的TArray"的行为。

11.3.1 内存布局

classFString{private:TArray<TCHAR>Data;// TCHAR在多数平台上为wchar_t(Windows)或char16_t// UE5在多数平台使用UTF-16, sizeof(TCHAR) = 2};

FString的本体是16字节的TArray头，指向堆上的TCHAR数组。空FString不做堆分配——Data指针为nullptr，Num和Max均为0。一旦赋值，即使只有一个字符也要分配堆内存，因为UE的FString没有SSO。

11.3.2 关键特性

FString没有实现短字符串优化（SSO）。即使只存一个字符，也要进行一次堆分配。Data数组始终以\0结尾，Num字段包含这个终结符。FString可以自由拼接、替换和格式化，这使它成为日志输出和字符串处理的默认选择，但每次修改都可能触发堆重分配。

移动语义在FString上表现良好：MoveTemp(SomeString)将源字符串的Data指针、Num和Max三个字段直接搬到目标，源变为空字符串，不发生堆操作。在函数返回FString时，编译器的RVO通常能直接在调用者的栈帧上构造字符串，连移动都不需要。

11.3.3 常见操作的内存影响

// 拼接——每次可能触发堆重分配FString Result;for(int32 i=0;i<1000;++i){Result+=FString::FromInt(i);// O(N²)的内存操作}// 优化：预估大小FString Result;Result.Reserve(5000);for(int32 i=0;i<1000;++i){Result+=FString::FromInt(i);// 不触发重分配}// 使用FString::Printf一次性格式化FString Result=FString::Printf(TEXT("Name=%s, Value=%d"),*Name,Value);

TStringBuilder<N>是另一种避免频繁堆分配的方式。它在栈上预留N个TCHAR的固定缓冲区，拼接过程不触发堆分配，只有超出N时才溢出到堆。对于在函数内临时拼接短字符串的场景，TStringBuilder<256>往往能彻底消除堆分配：

TStringBuilder<256>Builder;Builder.Append(TEXT("Position: "));Builder.Appendf(TEXT("(%.1f, %.1f, %.1f)"),Pos.X,Pos.Y,Pos.Z);FString Result=Builder.ToString();// Builder的256 TCHAR缓冲在栈上，不走堆

11.3.4 FString vs std::string

FString空串时的16字节开销全部在对象本身内（TArray的三个字段），堆上不分配任何东西。而std::string即使为空，也通常占32字节的本体空间来容纳SSO缓冲区。当需要存储大量可能为空的字符串字段时（如结构体中的可选描述字段），FString的空串成本反而更低。不过，对于大量1-22字符的短字符串，std::string的SSO避免堆分配的优势明显。

11.3.5 TCHAR编码与UTF-8转换的内存开销

UE在内部统一使用TCHAR（多数平台为UTF-16）来表示字符串。这意味着一段纯ASCII文本——变量名、文件路径、日志标签——每个字符占2字节而非1字节，是UTF-8编码的两倍。FName池对此有专门优化：FNameEntry通过Header.bIsWide标志区分窄字符和宽字符，纯ASCII名字以ANSICHAR存储，只有包含非ASCII字符时才切换到宽字符格式。FString则始终使用TCHAR，无论内容是否为纯ASCII。

当引擎需要处理来自外部的UTF-8数据（解析JSON、接收HTTP响应、读取文本文件）时，FUTF8ToTCHAR转换器会分配一块临时缓冲区来存放转换结果。对于CJK字符，UTF-8编码（3字节/字符）与UTF-16编码（2字节/字符）的差异不算悬殊；但对于以Latin字母为主的文本，从UTF-8单字节转为UTF-16双字节确实会使内存翻倍。如果处理大块文本数据（如完整的对话剧本或本地化资源文件），这个膨胀值得留意。

// UTF-8 → TCHAR 转换示例FString ConvertedString=UTF8_TO_TCHAR(Utf8Source);// Utf8Source是100KB的纯ASCII JSON// ConvertedString的堆分配约200KB（每字符从1B→2B）

UE5逐步引入了FUtf8String和FAnsiStringView等窄字符类型，允许在明确知道编码的场景下避免不必要的宽化。在网络序列化等对带宽敏感的路径上，直接使用UTF-8字节流而不经TCHAR中转，可以同时节省CPU时间和内存带宽。

11.3.6 TArray的内存放大效应

当FString作为TArray或TMap的值类型使用时，内存放大效应值得警惕。一个TArray<FString>的每个元素是16字节的TArray头，加上各自的堆分配。如果存储10 000个平均20字符的FString：

TArray头： 16字节 × 10,000 = 160 KB 堆上字符串： ~42字节 × 10,000 = 420 KB（20个TCHAR + \0 + 对齐） 总计： ~580 KB

作为对比，如果这些字符串足以用FName表示（不需要修改、且作为标识符使用），TArray<FName>只需80 KB（8字节 × 10 000），外加名称池中的去重存储。差距接近一个数量级。

在函数参数传递中，const TArray<FString>&避免复制整个容器，但如果函数内部需要逐个处理字符串，每个FString的堆数据已经在各自的位置上——这一步不可避免。TArrayView<const FString>提供零拷贝的只读视图，在不需要转移所有权的场景下是传递字符串集合的首选方式。

11.4 FText——本地化文本

11.4.1 设计理念

FText不只是一个字符串，而是一个可本地化的文本单元。它可能指向不同语言的翻译表，支持格式化参数，有复杂的共享和重建机制。对UI文本而言，FText是唯一正确的类型——直接用FString显示给玩家的文本无法被本地化系统管理，也无法在语言切换时自动更新。

11.4.2 内存结构

classFText{TSharedRef<ITextData,ESPMode::ThreadSafe>TextData;// 取决于TSharedRef实现，8或16字节uint32 Flags;};

TextData指向ITextData的某个子类实例，该实例持有当前语言的显示字符串（一个FString）以及可选的重建历史。多个FText变量可以共享同一个TextData——赋值操作只增加引用计数而不复制字符串。当引用计数降为零时TextData才被销毁。

11.4.3 FText的共享机制

FText Text1=LOCTEXT("MyKey","Hello World");FText Text2=Text1;// 共享同一个TextData，引用计数+1// 格式化时创建新的TextDataFText Text3=FText::Format(LOCTEXT("Fmt","{0} points"),Score);

赋值和拷贝的成本极低——仅仅是增加一个原子引用计数。只有通过FText::Format、FText::AsNumber等方式创建的新文本才会分配新的TextData实例。在一个典型的UI面板中，大多数静态标签都指向同一个TextData，动态数值文本则各自持有独立的TextData。在内存层面，一个少量动态文本加大量静态标签的UI页面，其FText总开销主要取决于动态文本的数量和它们的DisplayString长度，静态标签的共享开销可以忽略不计。

11.4.4 LOCTEXT/NSLOCTEXT的内存

#defineLOCTEXT_NAMESPACE"MyModule"FText MyText=LOCTEXT("Key","Source Text");#undefLOCTEXT_NAMESPACE

LOCTEXT展开后，Namespace、Key和SourceString三个字面量存储在可执行文件的只读数据段（.rdata/.rodata），运行时不产生堆分配。FText对象持有指向这些字面量的指针，以及一个由本地化管理器创建或查找到的TextData。如果本地化表中没有该Key对应的译文，TextData的DisplayString直接指向SourceString——连一次堆拷贝都不需要。

11.4.5 FTextHistory与本地化重建

FText的一个独特设计是它不仅记住"当前显示什么"，还记住"这段文本是怎么来的"。这个来源信息存储在FTextHistory的子类层级中：

classFTextHistory_Base;// 基础文字：直接字面值classFTextHistory_NamedFormat;// 格式化：保存模式和命名参数classFTextHistory_OrderedFormat;// 格式化：保存模式和位置参数classFTextHistory_FormatNumber;// 数字/日期/时间格式化classFTextHistory_StringTableEntry;// 引用字符串表条目

当玩家在设置中切换语言时，FTextLocalizationManager向所有活跃的FText发出重建请求。对于持有FTextHistory_StringTableEntry历史的文本，管理器用新语言的键查翻译表，替换DisplayString。对于持有FTextHistory_NamedFormat的文本，管理器先获取格式模式的译文，再用之前保存的参数重新执行一遍格式化——因为不同语言的语序可能不同，参数的嵌入位置也不同。

这套机制的内存代价在于：每个带有格式化历史的FText除了DisplayString本身，还需要持有格式模式字符串和所有参数的副本。在UI密集的应用中——比如一个有数百个动态数值的HUD面板——格式化FText的累积内存不可忽视。

缓解方式有两种。对于不需要本地化重建能力的文本（如纯调试用的显示），使用FText::AsCultureInvariant()创建不保留重建历史的FText。对于需要占位符但暂时没有内容的场合，FText::GetEmpty()返回一个全局共享的空文本实例，避免重复分配。

11.4.6 FText在Slate中的内存表现

Slate控件中的文本属性（如STextBlock的Text）通常存储为TAttribute。如果绑定的是一个静态FText（通过LOCTEXT定义），多个控件共享同一个TextData，内存开销很低。但如果绑定的是一个每帧重新构造的Lambda：

SNew(STextBlock).Text_Lambda([this](){returnFText::Format(LOCTEXT("HP","HP: {0}/{1}"),CurrentHP,MaxHP);})

每次求值都会创建一个新的FText实例和对应的TextData。Slate的文本失效检测（通过比较FText的内部标识符）会检测到文本变化并触发重新布局和渲染。如果数值实际没有变化，这些分配和布局计算就是浪费。更好的做法是在值真正变化时才更新FText，将其缓存为成员变量：

// 类成员FText CachedHPText;// 仅在HP变化时更新voidOnHPChanged(){CachedHPText=FText::Format(LOCTEXT("HP","HP: {0}/{1}"),CurrentHP,MaxHP);}

11.5 三者之间的转换代价

在热路径（每帧执行的代码）中应尽量避免字符串类型转换。初始化阶段完成所需的转换，运行时直接使用目标类型，是最稳妥的策略。如果不得不在Tick中做FName到FString的转换（例如用于日志），至少应加上频率控制或条件检查，避免每帧都执行。

一个隐蔽的转换场景是日志宏中的FName：UE_LOG(LogTemp, Log, TEXT("%s"), *SomeFName.ToString())。ToString()创建了一个临时FString做堆分配，如果这条日志在关闭Shipping构建中被编译掉则无碍，但在Development构建的热循环里，这些临时字符串的分配和释放足以在分配器统计中留下痕迹。

11.6 内存监控

可以在运行时对字符串相关的内存做基本的度量。FName池的总字节数通过FName::GetNameTableMemorySize()获取，配合引擎的MemReport或LLM（Low Level Memory Tracker）标签可以追踪其增长趋势。FString没有全局统计接口（因为它们分散在各处的堆上），但Binned2分配器的Size Class统计能间接反映短字符串分配的密度——如果32字节和64字节的Size Class占用异常高，往往意味着大量短FString或临时字符串的创建回收。

在Unreal Insights的Memory Insights视图中，可以按分配标签过滤与字符串相关的内存，观察一段时间内的分配/释放模式。如果看到某个函数反复分配和释放长度相似的小块内存，多半是循环中的临时FString——正是Reserve或TStringBuilder能解决的问题。

11.7 选择指南

需要显示给玩家的文本用FText，因为只有它支持本地化和格式化重建。需要频繁比较或用作TMap键的标识符用FName，O(1)比较和8字节实例是它的核心优势。需要拼接、修改或格式化的临时字符串用FString。资产路径可以用FName或FSoftObjectPath。配置文件的键名用FName。日志输出用FString。

在实践中，三种类型往往共存于同一个系统中。一个典型的例子：UDataTable的行名是FName，某个需要显示给玩家的字段是FText，而序列化到JSON时又需要把它们都转为FString。理解各类型的内存成本和转换代价后，就能有意识地控制转换发生的位置和频率，避免在循环内部做不必要的类型来回。

另一个常见的模式是网络复制中的字符串序列化。FName和FString通过UPROPERTY参与复制时，序列化引擎会把它们转换为字节流发送到远端，远端再从字节流重建。FName的序列化会把字符串正文发送出去（而非索引，因为对端的名称池索引不同），接收端再调用FName构造器从字符串重建。频繁复制大量FName属性的Actor，每次接收都会触发O(N)的哈希计算和池查找，这在高频复制场景下可能成为瓶颈。避免将变化不频繁的FName标记为每帧复制，是减轻这一开销的常见做法。

11.8 小结

FName以8字节实例加全局去重池的设计，为标识符和键提供了最经济的存储和最快的比较速度。池中的条目永不释放，长时间运行后名称池只增不减，因此程序化生成大量唯一名字时需要谨慎——利用Number后缀或避免不必要的命名是有效的应对策略。FString是一条朴素的堆字符串，没有SSO，每次操作都可能触发堆分配，预分配、TStringBuilder和减少不必要的拷贝是关键优化手段；TCHAR的UTF-16编码使得纯ASCII文本的内存开销是UTF-8的两倍，UE5正在逐步补充窄字符支持以缓解这一问题。FText为本地化而生，内部通过共享引用减少重复存储，通过TextHistory支持语言切换时的自动重建，代价是格式化文本要额外保存参数和模式的副本——在UI密集场景下需要注意缓存策略。三种类型之间的转换都有成本，在热路径中应将转换前置到初始化阶段。

理解这三种字符串的内存模型，实质上是理解三种不同的设计权衡：FName用池的不可回收换取比较的极速；FString用缺失SSO换取空串的紧凑；FText用历史链的内存开销换取本地化的透明重建。没有“最好”的字符串类型，只有最匹配当前场景的字符串类型。