大规模内容的性能保障：虚幻引擎4.26中的Sequencer

 
分段通常包含关键帧数据和其他属性，定义其时间轴中每个变换、属性或动画的所需状态。当在游戏中运行一个序列时，引擎的作用就是读取所有这些轨道与分段，并将正确的状态和属性应用到从游戏场景中解析得到的所需对象。

在4.26之前，这些轨道和分段都有各自的运行时实例，其中包含在特定时间进行评估并将属性应用于解析对象所需的数据和逻辑。这些实例是使用传统的对象导向范式设计的，而且要通过虚拟API访问。虽然这种做法在轨道数量很少的情况下能产生可接受的性能，但是随着轨道数量及其相关复杂性增加，它的伸缩性就会显得很差。不仅如此，并行运行大量动画或序列还会产生为每个实例初始化管线的高级性能成本。

通过研究各种用例的CPU分析数据可以明显看出，由于固有的虚拟函数调用开销和糟糕的缓存局部性，优化努力的收益会随着规模增大而递减。此外，变换轨道之类的轨道也受累于不断增加的各种职责，例如混合、不完全动画变换、相对变换原点、附件、组件速度，等等。

很显然，为了实现必要的优化，使这样的内容也能在游戏机和/或移动硬件上和其他所有游戏系统一样实时运行，就必须进行更系统的重新设计。
 

为速度而设计

在考虑为Sequencer运行时设计新的基础时，我们主要着眼于下列设计目标：

可伸缩性
如果使用新的运行时，应该能够编写包含成百上千个轨道或序列的内容，并且将这些内容作为一个整体来优化求值逻辑。这包括：

• 分配和组织数据，使性能不会随着活动Sequencer轨道的增加而快速恶化。
• 能够完全删除已知不再需要的逻辑和分支，不必在每一帧都为它们付出成本。没有代码就是最快的代码。这条原则应该适用于Sequencer求值代码的所有方面，而不仅限于最高级。
• 求值逻辑应该能够直接、高效且不受阻碍地批量访问必要数据，而不必通过复杂或低效的抽象与内存交互。

并发性
写入求值逻辑应该很简单，而且天然就能安全而高效地扩展到多个核心，包括上游/下游依赖性的表达定义（例如，并行地对所有曲线求值）。由于具备仅设置一次管线的综合优点，这不仅能让许多轻量级的小型动画受益，也有益于非常大的序列。

可扩展性
应该可以在内置功能的基础上构建逻辑，而不必重新实现核心系统。添加与核心系统交互的上游或下游功能应该是可以合理实现的。这包括：

• 在管线中的任何位置，当前帧的所有数据都应该是透明且可改变的。
• 可靠的依赖性管理。

这些设计目标，再加上Sequencer本身的各种问题，使得采用数据导向的设计原则成为自然而然的选择，理由如下：

• 大部分Sequencer数据是同质的，可以循序布局。
• 每种数据变换的逻辑通常具有非常高的独立性，与情境无关（即运行函数f(x)来得到曲线）。
• 控制和数据流是非常线性的，没有循环或递归的依赖性（也就是说，没有一种逻辑会要求重新计算已经计算出的数值）。
• 只有初始设置和最终属性设置器才有线程限制。

在4.26版中，我们重新设计了Sequencer的基础运行时，通过一个基于实体-组件-系统模式的求值框架，以高效利用缓存且透明的方式对求值数据进行布局。轨道实例（在内部被称为模板）不再是求值所必需的（不过旧的运行时仍然会和新的系统一起执行）。每一种轨道的数据和逻辑都已解耦：现在实体代表与源轨道数据相关的组件部分，系统代表与特定组件或组件组合相关的一种逻辑数据变换。现在系统会批量操作与其查询匹配的所有数据。例如，这种做法可以实现所有变换属性的缓存高效应用，或者只需要一次虚拟函数调用就能对所有浮点信道求值，无论动画中有多少变换属性，缓存未命中现象都非常少。

因此从4.26版开始，对于迁移后轨道类型的大型内容，Sequencer的求值开销将会显著降低。 

此外，我们还通过这种方法将许多序列或窗口控件动画的求值数据合并在一起，使得整套运行动画有了更大的优化潜力。因此与以往相比，现在可以让更多窗口控件动画一起运行，还可以在必要时将多个独立的动画或序列混合在一起。

管线示例 
我们来看一个对所有变换轨道求值的示例管线。Sequencer中的一条变换轨道可以包含一到九个关键帧信道，对应其复合浮点——X/Y/Z轴位置、Roll/Pitch/Yaw旋转和X/Y/Z比例。要将变换应用到对象，我们必须先在当前时间对这些曲线求值，然后使用结果调用“USceneComponent::SetRelativeTransform”。在4.26版之前，系统会将信道数据复制到一个模板对象，其中包含最多九个信道和用于对这些信道求值并将其应用到对象的逻辑：

新的方法实现了显著的改进，原因如下：

• 更好地分离了关切、数据和指令缓存局部性，在成规模的情况下，速度明显加快； 
• 虚拟函数调用次数随活动系统类型的数量而非个别轨道的数量增减； 
• 缓存未命中的次数与组件数据的组合数量成正比，而与整体数据大小无关； 
• 这些增益有可能对整个数据集都实现，优化不必局限于每个轨道。 
• 现在可以在不对逻辑做重大修改的情况下，使部分管线并发运行。

例如，以上示例中的“对浮点信道求值”系统能够并行地对当前帧的所有浮点信道求值，不论它们的动画是什么属性，也不论它们要如何组合或应用。

不仅如此，引入中间数据变换的操作（例如将多个变换混合成一个对象）也变得更简单、更分隔化了。

在4.26版之前，此功能是在一个专用类中实现的，它会存储和处理所有属性类型的所有输入/输出。由于小分配优化和动态调度的成本，这会产生存储器和CPU开销。它还要求以一种理解混合代码路径的方式表达属性的应用，这就进一步提高了复杂性，导致通用（无混合）代码路径的降级。

内存布局

我们再稍微深入地了解一下Sequencer内存中的求值数据。我们设计了各种数据布局方法的原型，最后选择了下列数据模型，因为它在内存大小、缓存效率、再分配成本和并发访问之间做了很好的趋势。 

实体被分组为多个批次，称为实体分配，每个分配包含至少一个实体。关键是，一个分配中的所有实体都必须有相同数量和类型的组件。在一个特定实体中添加或删除组件时，该组件就会迁移到一个不同的（或新的）分配。分配的大小是动态设置的，并且有保留的容量，因此不必调用malloc就能添加新的实体（只要初始化组件数据即可）。

你可以看到，在一个分配中，相同类型的所有组件都是循序布局的。假设一个分配包含组件A、B和C，那么就会产生AAA..A、BBB..B、CCC..C的布局，每种类型都对应一条缓存线。通过以这种方式组织数据，我们可以控制实体数据的位置而不影响其实体ID，还可以控制对每个组件数组的读写访问（目前仅仅是通过互斥的方式来实现，不过未来如果有了争用问题，也许可以扩展为专门的调度器），同时在各类型之间保持良好的包装。如果某个系统要读取组件A和B的所有组件数据，那么它只需要检查分配的类型（由一个位掩码决定）。然后系统就会立即知道其中（数量可能成千上万的）实体是否与它感兴趣的类型匹配。 

这种模式匹配方法使数据转换逻辑与数据的构成完全解耦，让系统能够在不了解非相关部分的情况下并行操作许多不同的组件数据组合，同时仍然保证内容上规模以后的性能。如果要对以上示例进行扩展，插入一个能够相对于变换原点生成所有变换轨道的系统，那只是小菜一碟，并不需要对任何核心变换系统进行侵入式更改。

线程

因为我们现在能够按照逻辑所读写的组件类型来定义逻辑，所以也可以定义组件数据的上游和下游依赖性，这样一来就可在有必要的情况下安全而自动地将这些数据变换异步分派到任务图表。在对大型数据集（例如有许多复杂关键帧曲线的内容）求值时，这些曲线的求值现在能够与其他计算一起异步运行，在平台允许的情况下实现并发性。这只有在情境切换或线程抢占的潜在成本合理的情况下才有益，但Sequencer的线程安全设计现在允许在内部或由用户自主做出这一决定。

我们将在适当的时候为使用Sequencer的程序员更全面地详细阐述该架构。
 

从4.26版起相对于旧运行时系统的行为变化

一般而言，你应该不会体验到任何行为变化；可生成项、附件、变换和其他属性应该都会继续像以前一样运作。但是，也存在一些细微的行为变化，概括如下：

• 同一类型的活动序列现在都会同时在一起求值。在4.26版之前，如果有两个独立的活动序列对同一对象上的同一属性生成动画，由于它们是分别求值的，就会争夺该属性的控制权。在4.26版中，这些序列将会一起求值，因而可以自然地混合在一起。将来我们还会扩展这一设计，允许用户控制序列混合或相互覆盖的方式。
  • 所有活动窗口控件动画现在都会一起求值。
  • 所有活动关卡序列现在都会一起求值。
• 如果手动播放、停止或设置序列或窗口控件动画的位置，现在可能无法在该函数调用中对序列同步再求值。播放或移动序列播放头的请求可能被延迟到下一帧。
  • 可以通过在序列上禁用“异步求值”选项来为特定序列禁用这一功能，但需要付出性能成本。这样做会强制进行同步再求值，并且禁用（1）中描述的混合行为。

 

• 导致相对于序列求值的重入的事件轨道（例如播放其他序列、更改播放状态或移动播放头的事件）现在仅限于求值后位置（即不允许出现在“生成前”或“生成后”）。这是现在新事件轨道的默认设置。在4.26版之前，事件轨道默认在“生成后”。虽然现有轨迹将会保留“生成后”设置，但新的轨道将默认设置为“求值后”。 

 
我们希望你觉得这些信息既有趣又有用。要了解关于Sequencer的更多信息，请查看该工具的文档页面。