最近官方发布了《黑客帝国：觉醒》的试玩游戏，观看演示视频后备受震撼。视频中提到了街头海量人群是通过mass ai框架实现的，这套框架在实现如此逼真的效果上功不可没。尽管mass代码的公开版本尚未发布，但实际上它已经在github的ue5-main分支上存在了很久。我之前也浏览过该代码，并且近期它还在不断更新。因此，我想借此热度总结一下其内部实现原理。如果你熟悉ecs（实体-组件-系统），阅读下面的内容将会非常轻松，因为mass实际上就是ue5实现的ecs框架。
在拉取最新代码并编译后，启动闪屏显示的版本号是5.1.0：
Mass框架分为几个库，以插件形式存放在引擎源码中，因此即使是低版本也相对容易使用。默认情况下这些库是关闭的，需要手动开启。以下是在引擎插件目录中手动开启的方式：
其中，MassEntity是基础库，还包括MassGameplay、MassAI、MassCrowd等。各库之间的关系如下图所示：
MassEntity是整个Mass框架的基础。先来看一下MassEntity中的代码文件：
仅从代码命名就能猜出这是一套ECS框架。如果你对Unity的ECS和UE的渲染框架比较熟悉，看到这套代码的结构会觉得非常熟悉和亲切。Archetype对应于Unity的ECS中的Archetype，其实现与Unity的ECS非常相似。而CommandBuffer则类似于UE渲染线程中的CommandBuffer。
之前UE渲染管线的效率非常高，很大程度上是因为面向数据的设计，并且紧密结合TaskGraph利用多线程渲染的优势。现在在逻辑层也搭建了一套类似的管线，就是为了让逻辑处理也能发挥出UE5的性能优势。官方已经提供了实机演示成品，你肯定能感受到其卓越的运行效率。
接下来具体介绍内部实现：
Entity和Archetype与Unity的ECS除了名称不同外，实现完全一致。Entity在Mass中的名称是struct FMassEntityHandle，只有两个成员变量Index和SerialNumber，共占8字节。看到这样的结构，肯定知道有一个全局的大数组，这个Index就是数组下标，而序列号用于数据校验，可以说与FWeakObjectPtr的原理相同。
这个大数组保存在MassEntitySubsystem中，如下图所示：
这个大数组的类型是TChunkedArray，默认16K一个Chunk，每个元素类型是FEntityData。16K是因为大部分CPU的L1缓存都是16K的倍数。参考我之前的一篇文章，详细说明了：UE4/UE5的LockFreeList - 知乎 (zhihu.com)
内部有一个智能指针，指向实际的数据结构FMassArchetypeData。除了Index外，还有一个序列号SerialNumber，其作用是当某个Index上的Entity被删除后，再创建一个新的Entity，如果原来Index指向的EntityData和EntityHandle的序列号不匹配，就可以明确EntityHandle指向的是旧的Entity而不是新的，这样就避免了只用Index标记Entity导致的冲突问题。
FMassArchetypeData结构如下：
可以看到，这个其实定义的是Entity数据的Archetype。什么是Archetype（原型）？可以简单这样理解：类是对象的原型，结构体是结构体实例的原型，UClass中的CDO是对应UObject的原型。我们游戏要创建很多Entity，这里就需要先有Entity的原型定义，可以描述内存布局等信息。总之，创建Entity前肯定需要原型信息。
在定义原型时需要以下四种信息作为参数：
一般情况下使用FMassFragment就好了，这个就是定义每个Entity内部的数据结构，在传统的ECS中这个FMassFragment其实就是Component。而FMassTag不能有实际的成员变量，只是作为ECS执行时的标记，可以认为是传统ECS中的额外过滤器标签，而UE中的过滤器称为Query。FMassChunkFragment是Chunk的额外内存数据，每个Chunk内共享一份。FMassSharedFragment是共享的布局，相当于Unity的ECS中的共享Component。如果FMassFragment可以理解为Entity的成员变量，那么FMassSharedFragment就可以理解为Entity的static成员变量，而FMassChunkFragment可以理解为每个Chunk的static成员变量，Chunk具体是什么接下来会说。这四种结构，在创建原型时都会分别记录下来，保存在FMassArchetypeCompositionDescriptor中。
可以看到，这里提供了联合计算Hash的函数，也就是说通过这些原型，就可以得到一个唯一码。最终也会和Entity一样保存到MassEntitySubsystem中：
在FMassArchetypeData初始化时，就会根据这个描述符来生成内存布局和相关变量，具体可以看FMassArchetypeData::Initialize函数。这里也会解释清楚上面四种基类的区别。
其中FragmentSizeTallyBytes是每个Entity的大小，是由sizeof(FMassEntityHandle)加上每个FMassFragment子类的大小总和。而Tags本身不占Entity大小，只保存在Archetype中。FMassSharedFragment是多个同类型Entity共享的Fragment，所以也保存在Archetype中，不占用Entity内存。
实际的Entity数据保存在FMassArchetypeData的Chunks这个成员变量里：
内部会一次创建一个固定64K大小的Chunk，给多个Entity使用。
为什么是64K？同样是因为大部分CPU的L2缓存是64K的倍数（Unity一个Chunk是16K），这里L1和L2都是CPU单核的独立缓存，所以都很快，如果到了L3因为涉及到多核共享，就会显著降速。所以根据Entity本身的大小不同，每个Chunk可以容纳64K / EntitySize个。当删除掉其中一个Entity时，内部的其他Entity并不会移动，所以这个Entity会在Chunk中空出来，这时如果再Add新的Entity会复用这个空出来的内存，当删除掉Chunk中所有Entity时，Chunk的内存会自动释放掉。整个数据结构实现，相当于是TSparseArray和TChunkedArray的结合，因为UE没有自带这种泛型容器，所以这里就单独实现了。
在定义ArchetypeData时，暴露给业务的其实是FMassEntityHandle。就像FMassEntityHandle一样。具体对应关系如下图所示：
这里要注意的一点是，EntityHandle中的Index，并不是Archetype中实际Entity的下标，而是System里Entities的下标。这两个下标会通过Achetype中的一个Map做映射，如下图所示。Entity中的Index是全局唯一的，而Archetype中的Index是在当前Archetype内唯一，多个Archetype中是会有相同的下标，所以需要这样一个映射才能确定实际的Entity数据是什么。
关于实际的Entity存储：
实际数据存储在RawMemory中，具体大小在AllocSize里。可以看到每个Chunk内还有一个ChunkFragmentData的。这个就是前面说的每个Chunk一份的static数据。
示例上面这样描述对于不了解ECS的读者来说可能有些晕，下面用我具体写的这个例子说明更直观一些。我们先定义一下FMassFragment，这个就是Entity的内部数据结构。这里我准备创建3种类型的Entity，第一种内部数据是float的，第二种是int32的，第三种是float和int32组合在一起的。
Entity具体创建和删除示例如下：
可以看到上图，在创建前，我先定义了原型，原型其实就相当于是在运行时定义数据结构，这里需要强调的是运行时，自己手写一个struct其实是在编译期定义数据结构，因为都是使用的UScriptStruct，所以理论上可以使用蓝图定义的结构体。上图也可以看到，定义好了Entity的Archetype后，也可以随时修改，相当于ECS的ReplaceComponent。
我这里分别创建了100个，200个，150个。实际创建的就是下面这样的数据，在第一次创建的时候是连续的，连续创建和删除有可能产生空洞。
注意上图只是个示意，实际会分到Chunk里。借用一下Unity的ECS老图，具体结构是下面这样，我就不自己画了，原理和Unity的ECS是完全一样的。
本章主要介绍了Mass内部的内存布局，后续章节会继续讲解具体操作。
