Xen*_*oRo 7 architecture oop unity-game-engine data-oriented-design entity-component-system
由于 Unity ECS，我最近阅读了很多有关 ECS 的文章。
ECS架构有很多明显的优势：
ECS 是面向数据的：数据倾向于线性存储，这是系统访问它的最佳方式。在体面的 ECS 实现中，数据是按顺序存储和处理的，对于任何给定的系统处理它的组件集几乎没有中断。
ECS 非常分割：它自然地将数据与行为分开，强制执行“组合而非继承”（google it）等。
ECS 对并行处理和多线程非常友好：由于事物的结构方式，许多实体和组件可以避免冲突并与其他系统并行处理。
然而，ECS 的缺点（与 OOP 或实体组件 [没有系统] 相比，直到最近在包括 Unity 在内的游戏引擎中很常见）很少被谈论，如果有的话。它们存在吗？如果他们这样做了，他们是什么？
以下是我从研究中收集到的几点：
系统非常依赖于它们的排序。在现有系统之间引入新系统可能是一个挑战。
您还需要尽可能提前计划您的数据，因为它们可能会被很多系统使用。更改组件的内容可能会破坏很多系统。
尽管调试系统流程很容易，但调试单个组件的更改并且没有实体的所有组件发生的情况的全局视图也更难。我不确定 Unity 是否为此引入了新的调试功能。
如果您计划在团队中使用 ECS，向不熟悉 ECS 的开发人员引入新范式可能是一个挑战。入职时间可能会更长，开销更多。
希望这能给你一个好的起点。
小智 2
当谈到 Unity3D 时，我想到的一个缺点是 ECS 非常受限于 Unity 类（例如 MonoBehaviour）和生命周期。这意味着组件不容易与其他 C# 代码共享，而设计良好的 OOP 类可以由 Unity 以外的其他平台重用。
我想到的另一点是，在 Unity 中使用带有组件的接口有时并不容易，因为只有最新版本才支持接口序列化。如果没有序列化，则不会出现在检查器内部。