标签：框架 系统 Component System ECS 组件 设计 数据
ECS，Entity(实体) Component(组件) System(系统)，是一个gameplay层面的框架，它是建立在渲染引擎，物理引擎之上的，主要解决的问题是如何建立一个模型来处理游戏对象的更新操作，是对数据集合的操作。
- Entity（实体），有点类似于Unity中的Game Object，在ECS中，它仅仅是一个Component（组件）的组合，不具有任何代表意义，它的意义就在于对其上的Component（组件）进行生命周期管理。
- Component（组件）是一个只包含数据的组件，将每个可能单独使用的对象属性归纳，里面只有数据没有任何方法，如角色的生命值蓝量就是一个Component（组件），每个Entity（实体）是由多个Component（组件）组合而成，共享一个生命周期。
- System（系统）则是用来处理数据的系统，里面只有方法，没有任何数据，每个System只关注于干好一件事情，它只关心那件事作用于游戏世界里同类的一组对象的每单个个体，或是这类对象的某种特定的交互行为。
ECS的作用
在System（系统）之间不用相互调用（减少相互耦合），是由游戏外部框架来驱动若干System（系统）的。这样一来每个System（系统）都可以独立开发，它只需要遍历框架提供给他的组件集合，做出正确的处理，更新组件状态就够了。
而编写Gamplay的人只需要清楚每个System（系统）到底做了什么，操作本身对哪些Component（组件）产生影响，正确书写System（系统）的更新次序就可以了。这样一来容易管理复杂度，二来给并行处理留下了优化空间
ECS的优劣
相比于传统的OOP，ECS在写法上要复杂很多，一个对象可以集中的数据来用多个Component（组件）来管理，还要额外的System（系统）来处理逻辑。但是，ECS它做到让设计分离了，由此的影响如下：
1. 减少多人开发时出问题的概率
如果有一个非常复杂的对象，许多人的工作都和这个对象有牵连，当A在进行逻辑处理时，他不得不传整个对象，还要考虑修改对其他人的影响；但是拆离后，A可以把自己的数据封在特殊的Component（组件）里，用自己的System（系统）处理，减少出问题概率（但是这样会增加代码复杂度）；
2. 基于组合优于继承原则
组合优于继承，这是设计层面上的原则，而ECS的Entity（实体）则是Component（组件）的组合，提高了复用性，也方便我们只关注处理对下对象的某个局部；且当我们对某个功能进行拓展时，几乎不会影响到其它功能模块，因为每个部分都是几乎不关联的；
为什么组合优先于继承_Hopefully Sky的博客-CSDN博客_组合优于继承
3. 容易预测和回滚
ECS的初衷就是为解决预测和回滚的，因为数据和状态都存储在Component（组件）里面，因此记录关键帧的数据和状态非常方便，这就使得实现预测和回滚容易许多；
4. 适合游戏开发层面做逻辑表现分离
同一套逻辑处理系统，加了表现组件就有了表现，可以放在客户端，不加的话就是纯逻辑，放在服务端确认客户端回传的数据。一套代码又能做服务器又能做客户端；
5. 提升性能
ECS这种面向数据的方式，使得内存排列天然紧密，非常适合现代CPU的缓存机制，极大增加了CPU的缓存命中率，大幅提升了性能。
6. ECS的劣势
ECS在处理大批量数据上有明显的优势，但是在处理小数据上如UI层面，网络层面上等就不太适合使用。而且Component（组件）本身不知道哪些System（系统）关注它，System（系统）也不知道什么时候关注的Component（组件）发生改变，即无法做到自驱动，必须有外部的东西来驱动这些System（系统）去工作，其实还需要许多Utility来辅助工作。
标签：框架,系统,Component,System,ECS,组件,设计,数据 来源： https://blog.csdn.net/weixin_38051797/article/details/120660108
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。