Unity ECS(一)了解ECS与DOTS

本文转自Unity Connect博主 EntherVarope

ECS是什么？可以做什么？为什么ECS成为我的选择？

什么是ECS（实体组件系统）？

其实ECS的概念早就诞生了，但是它是因为守望先锋才逐渐被人所知。（暴雪的守望先锋是基于ECS模式设计的，用于改善在大场景下多角色运算的效率）

ECS是一种软件架构模式，由三个元素组成：实体(Entity)，组件(Component)和系统(System)（看起来和MVC很相似）。游戏程序分为这三个主要元素，并且通过定义每个系统的责任和关系来管理游戏。

实体代表游戏世界中的事物。实体本身没有特定功能，它们将会被组件填充来成为一个实体。

组件是附加到事物的数据。重点不是对象，而是数据，没有办法操纵它。比如操作游戏的角色时，位置，速度和体力等每个状态都将成为一个组成部分，并与称为“角色”实体相关联。另外，实体中的字段信息也被表示为组件部分。

系统是游戏世界的法则。给定与实体关联的某些组件作为数据输入源，或者更新某些组件的值（可能与输入的组件相同）。随着整个系统更新每一帧，游戏世界也在不断进行。我认为最容易想象的是物理定律。例如，想象一个刚体实体。它的运动基于利用位置和速度两个分量的系统来更新坐标。

粗略地说，系统负责处理，组件负责数据，而实体是一组组的组件，用于过滤系统正在处理的内容。由于系统和数据是完全分开的，因此它与面向对象不兼容。

Unity也具有类似于ECS的架构（自Unity2018.2起已提供ECS）。实体是已经削减到极限的游戏对象功能，组件是组件的序列化数据部分，其余部分是系统。Unity ECS是对纯ECS的改进。

ECS可以做什么？

UnityECS正在围绕这一设计模式开发新的“面向数据技术堆栈”(DOTS),如果经常关注Unity的发布会，就或多或少对它有所了解。但是事先写在前边，ECS并不能加速任何类型的游戏/程序。

ECS有望加速游戏的类型

弹幕游戏

有海量单位的大型RTS

开放世界/沙盒

集群模拟（例如新出的“动物星球”）

此类具有大量“遵循同一运算规则”对象的程序，便可以利用ECS来加速。

为什么ECS成为我的选择？

答案很简单：因为它十分的快！效率非常之高，比起传统的面向对象编程，它对内存的利用率是成几何倍数的增长，还有一些其他的优点：

轻松并行化--------清晰的系统输入输出和小粒度

良好的缓存效率------通过顺序访问组件数组获得空间局部性（动态场景读取十分方便）

耦合度低---------因为系统仅交换数据

易于测试---------因为系统没有状态

当然ECS也有它自身的一些缺点：

对于习惯了面向对象编程的人，需要改变编程思维模式

在Unity推出完善的工具集前，管理内存是一件困难的事

至于为什么ECS如此之快，内容比较多，感兴趣的可以继续往下看，跳过也无妨。

传统的Unity GameObject与组件工作流

在传统的流程中，我们制作物体，为其添加脚本。这种做法有一些固有的缺点和性能缺陷。首先，数据和处理它们的方法是紧密耦合的，代码重用率较低。此外，系统非常依赖引用类型，引用错误屡见不鲜。

最重要的是，在上图的示例中：Gun与Player所引用的Transform、Rigidbody、Collider等这些关键脚本被分散在堆内存中，数据将不会转换成可由更快的SIMD（单指令多数据流）矢量单元进行操作的形态。

游戏对象、其行为及其组件之间分散的内存引用

上图显示了这种数据存储方法的随机偶发性质。每一个单引用，在使用时都有可能会将其所有的成员变量从系统内存中全部拉出，举个例子，当我命令Gun进行开火，子弹飞出，对子弹的坐标进行运算让它飞行，表面上看起来仅仅是对子弹这个对象的Transform中的position进行了操作，但实际上，子弹的rotation，gameobject属性，还有等等等等其他成员也一并拉出来操作了。

绿色项目表示实际用于移动操作的成员，其余都是浪费空间

绿色块表示开发想象中认为操作引用的成员，而实际上，硬件听从脚本的命令从内存中获取数据时，缓存中会填充许多无用的数据（红色的块），如果将为要移动的GameObject设置成一个独立的只有位置与旋转成员的矩阵，那么系统就能够在很短的时间内执行操作。

在ECS中，整个的流程将会是：

具有JobSystem的ECS

只需要考虑每一种GameObject所包含的数据实体，而不用考虑自己的组件集合（抛弃了Transfrom，Rigidbody等），将处理与各个对象类型完全分离。实体仅仅是一个句柄（或者说是一个标识符）永远索引它表示的不同数据类型的集合(ComponentDataGroups)系统可以通过这些句柄来对所有组件进行过滤和操作，而不需要将系统与实体类型明确结合。这种工作机制有很大优势，它不仅能提高缓存效率，缩短访问时间，它还支持现代CPU中的使用数据对齐的先进技术（自动矢量化 即：SIMD），这种技术带来的效率提升是极为可观的。在Unity的DOTS中，还可以使用Brust Complier跳过中间语言的编译，使得性能进一步的提升。

关于数据对齐与SIMD

传统的内存块与进行了数据对齐的ECS内存块

实际编程中，对内存的管理总是不可能达到完美利用，总会有或多或少的内存块处于闲置状态，闲置内存不仅没有任何用处，系统仍然要访问它们增大访问开销（浪费时间）。传统的面向对象下虽然降低抽象门槛了，但是对内存来说实际上是很不友好的（构建对象时，数据引用总是杂乱无序的）。面向数据编程将数据提取出来，不用关心他们实际上的联系，仅仅是由实体这个索引来引用，这就代表，对于同类型的数据，可以将他们放在同一个内存块里，无论是对内存的利用或者是系统的访问都是十分便利的。

（PS:就算是数据对齐了，也不能彻底消除闲置内存，但是比起传统的内存结构来说，闲置内存的数量会大为减小）。

SMID：

SIMD全称Single Instruction Multiple Data，单指令多数据流，能够复制多个操作数，并把它们打包在寄存器的一组指令集。

传统的CPU使用SISD来完成逻辑运算，过程可以笼统的概括为一个执行单元先访问内存，根据命令找到第一个操作数，再一次访问内存，找到第二个操作数，才能根据命令进行逻辑运算(在查找操作数的过程中，由于数据的引用是杂乱无序的，执行单元只能遍历每一个内存块，这就造成了性能瓶颈)。

新世代的CPU所采用的SIMD则是由数个执行单元同时访问内存，一次性找到所需的操作数进行运算，事实上，由于进行了数据对齐，每一个执行单元查找内存的效率比SISD的查找要高出不少，这就好比将无数的快递按照地区分门别类，一旦CPU发出“拿出上海地区的快递“指令，每一个快递员（执行单元）都会直奔存放上海快递的货架而不用一个货架一个货架的搜索。这样的特性非常适合大数据运算。

SISD与SIMD

以上内容都是关于ECS本身的优势，接下来将阐述Unity基于ECS进一步开发的面向数据技术栈工具DOTS。

UnityDOTS（Data-Oriented Technology Stack）

Burst Complier

爆发式编译器（？）

爆发编译器是UnityECS为了更高效地组织数据所产生的后台性能增益开发的。从本质上讲，突发编译器将根据玩家设备上的处理器功能优化代码操作。例如，您可以通过填充未使用的寄存器来执行 16、32 或 64次浮点预算，而不是一次只进行 1 次浮点运算。

新的编译器技术基于 Unity 的新数学命名空间（Unity.mathematics）和 C# 作业系统(JobSystem)以及改进过的高性能C#(HPC)，基于系统知道数据已经通过实体组件系统正确设置的事实。英特尔 CPU 的当前版本支持英特尔® SIMD 流指令扩展 4（英特尔® SSE4）、英特尔® 高级矢量扩展指令集 2（英特尔® AVX2）以及用于浮点和整数的英特尔® 高级矢量扩展指令集 512（英特尔® AVX-512）,AMD的支持3D Now的CPU等都是能支持爆发式编译器的（除非是在十分老旧的电脑上运行，否则不需要考虑兼容性问题，因为自动矢量化技术已经成为现在与未来的CPU主流标准）。该系统还支持在每种方法中使用不同的精确度，以过渡方式应用。例如，如果您在低精度的顶级方法内使用余弦函数，则整个方法也将使用余弦的低精度版本。该系统还根据当前运行游戏的处理器的功能支持，通过动态选择适当的优化功能为 AOT（前期）编译做准备。

这种编译器的另一个优势是确保游戏的未来适用性。如果一款全新的处理器产品线上市，其中包含一些令人惊叹的新功能，Unity 可以在后台为您完成所有费力工作。只需对编译器进行升级，以获取优势。编译器是基于软件包的，无需 Unity 编辑器更新即可升级。该爆发式编译器软件包将以自己的节奏进行更新，因此您将能够利用最新的硬件架构改进和功能，而无需等待代码升级到下一个编辑器版本。

C#JobSystem

C#作业系统

大多数使用多线程代码和通用任务系统的人都知道编写线程安全代码很难。线程争用情况虽然很罕见，但仍然可能会发生。如果编程员没有想到这个问题，可能会导致潜在的程序严重错误。除此之外，上下文切换的成本，Debug的成本很高，因此学习如何平衡工作负载以尽可能高效地跨核心运行是很困难的。最后，编写 SIMD 优化代码或 SIMD 内联函数是一种深奥的技能，有时最好交给编译器去完成。新的 Unity C# 作业系统为您解决所有这些难题，以便您可以在现代 CPU 中放心地使用所有可用的内核和 SIMD 矢量化。

总而言之，C#的JobSystem提供一系列的多线程解决方案，让编写多线程程序更为安全方便。

传统的Unity程序如果不使用外部程序集执行的是单线程

常规的Unity如果要开发多线程，不仅要引入外部的实现方式，Debug过程也是繁琐不可视的，而引入C#JobSystem，可以让系统智能化管理安排多线程任务，使用Unity自身封装的多线程安全集合（例如：NativeArray<>）可以有效防止线程冲突的问题。

使用C#JobSystem来安排任务至每一个核心

在接下来的文章中，我会告诉你如何利用DOTS来编写一个ECS程序。

原文链接：https://connect.unity.com/p/unityecs-yi?app=true

戳上方链接下载官方app即可提前了解接下来的文章，还有技术社区在线答疑，更多学习资源等你来发现