ECS（Entity-Component-System）模式详解

ECS（Entity-Component-System）模式详解

ECS（Entity-Component-System）模式是一种在游戏开发中广泛应用的设计模式，它通过将实体分解为组件并由系统处理这些组件，实现了高度的灵活性和性能优化。本文将从个人实践出发，深入探讨ECS模式的基本概念、特点以及其在游戏开发中的优劣势。

前言：

在使用Cocos Creator开发弹幕游戏的过程中，由于项目中出现的单位过多，导致项目的性能并不是特别理想。当时研究这个问题时发现，使用ECS模式可以解决这方面的问题，因此将其应用进项目中。实践后发现，ECS这种模式在Unity下配合插件使用效果最佳，在Cocos上效果则相对有限。上线后，系统勉强还能承受。目前的性能对比显示：Unity环境下能处理10000单位并保持30帧，Cocos环境下处理10000单位只有20帧，而什么都不用的情况下处理10000单位只有15帧。需要注意的是，目前对ECS模式的学习还不算完善，后续会继续补充，如果有错误，欢迎各位专业人士指正。

简介：

ECS（Entity-Component-System）模式通常被归类为一种组件化设计模式，主要用于构建游戏引擎和其他需要高度灵活性和性能的软件系统。尽管ECS模式在一些领域中非常流行，但它并不像传统的设计模式那样具有普遍性和标准化。在一些设计模式的分类中，ECS可能被归类为结构型模式或行为型模式的一种变体，具体取决于它是如何被应用和实现的。

ECS模式的基本思想是将实体（Entity）分解为组件（Component），并通过系统（System）来处理这些组件。每个实体由一组组件构成，系统根据组件的类型和数据来执行特定的逻辑。这种模式的优势在于它的高度灵活性、可扩展性和性能优化，特别适用于需要处理大量实体和复杂逻辑的场景，比如游戏开发中的物体管理和行为控制。

尽管ECS模式在特定领域中非常有用，但由于它的特殊性和定制性，通常不被纳入传统的设计模式范畴之中。

个人理解

E就是entity ，一个不代表任何意义的实体;
C就是各自脚本，Component 一个只包含数据的组件：（这里采用了黑板的形式来存储对应的数据，采用状态机来实现AI模块）

S就是整个游戏框架，包含所有Manager组成的游戏框架
其主要特点在于是面向数据编程，利用组合优于继承的思想，关注数据类型，关注系统的运行和状态，不关注具体某个对象的细节。数据与逻辑处理完全解耦。

优劣性：

相比于传统的OOP，ECS在写法上要复杂很多，一个对象可以集中的数据来用多个Component来管理，还要额外的System来处理逻辑。但是，ECS它做到让设计分离了，由此的影响如下：

优势：

• 减少多人开发时遇到的问题
  如果有一个非常复杂的对象，许多人的工作都和这个对象有牵连，当A在进行逻辑处理时，他不得不传整个对象，还要考虑修改对其他人的影响；
• 基于组合优于继承原则
  组合优于继承，这是设计层面上的原则，而ECS的Entity则是Component的组合，提高了复用性，也方便我们只关注处理对下对象的某个局部；且当我们对某个功能进行拓展时，几乎不会影响到其它功能模块，因为每个部分都是几乎不关联的；
• 容易预测和回滚
  ECS的初衷就是为解决预测和回滚的，因为数据和状态都存储在Component里面，因此记录关键帧的数据和状态非常方便，这就使得实现预测和回滚容易许多；
• 适合游戏开发层面做逻辑表现分离
  同一套逻辑处理系统，加了表现组件就有了表现，可以放在客户端，不加的话就是纯逻辑，放在服务端确认客户端回传的数据。一套代码又能做服务器又能做客户端；
• 提升性能（在Cocos中的作用不是特别大）
  ECS这种面向数据的方式，使得内存排列天然紧密，非常适合现代CPU的缓存机制，极大增加了CPU的缓存命中率，大幅提升了性能

劣势：

ECS在处理大批量数据上有明显的优势，但是在处理小数据上如UI层面，网络层面上等就不太适合使用。而且Component本身不知道哪些System关注它，System也不知道什么时候关注的Component发生改变，即无法做到自驱动，必须有外部的东西来驱动这些System去工作，其实还需要许多Utility来辅助工作。