我是一名在校大学生，因在学校体验一次云服务器后，便喜欢上了这种随时存储文件的感觉。又因一次机缘巧合下我在B站上看见了关于ECS服务器一些使用方法，便想自己搭一台服务器。但是因为各种服务器昂贵的价格，使我放弃了这个想法。随后又在知乎大佬的帮助下了解了阿里云的“飞天加速计划”，在获得第一台服务器的时候，我就在想怎么用到它，也是换了好多个系统，毕竟不用怕被折腾坏，大不了重置。当时想的第一件事就是想搞一个自己的小网站，于是又去买了几个域名，发现域名要进行备案，于是又折腾了一段时间进行备案，当一切准备完成后，开始了建站的道路。跟着网上的教学视频一点一点的做，用宝塔面板来进行管理啥的。宝塔面板提供了很多一键部署的插件，很适合我这种小白。跟着教程一步一步走，也是搭建了自己的第一个网站，但是后面也不经常用，就把他晾在了那，也就荒废了，不过这是一次不错的学习经历和体验，在这次暑假中也收获了很多学校里上课学不来的东西，也是很有益的一件事。阿里云的ESC总得来说，是对新手玩转服务器来说是非常简单的操作体验，2C2T 1M的服务器可以实现非常多的东西，比如搭建一个网站，搭建属于自己的云上blog，作为一个存储小型文件的云存储空间。并不用担心服务器各种参数把服务器整坏，因为你只需要在外部点一下“重置”便可以重新进行搭建。飞天加速计划确实是对在校大学生第一次使用服务器很好的一种体验和经历，可以让自己充分的把书本上、课堂上学来的知识进行一次总得使用和梳理。也是对大学生从无到有的一次很好考验。
一. 初步理解
ECS，Entity(实体) Component(组件) System(系统)，是一个gameplay层面的框架，它是建立在渲染引擎，物理引擎之上的，主要解决的问题是如何建立一个模型来处理游戏对象的更新操作，是对数据集合的操作。
Entity，有点类似于Unity中的Game Object，在ECS中，它仅仅是一个Component的组合，不具有任何代表意义，它的意义就在于对其上的Component进行生命周期管理。
而Component和System则是这个框架的核心，Component是一个只包含数据的组件，将每个可能单独使用的对象属性归纳，里面只有数据没有任何方法，如角色的生命值蓝量就是一个Component，每个Entity是由多个Component组合而成，共享一个生命周期。
而System则是用来处理数据的系统，里面只有方法，没有任何数据，每个System只关注于干好一件事情，它只关心那件事作用于游戏世界里同类的一组对象的每单个个体，或是这类对象的某种特定的交互行为。
而游戏的业务循环就是在调用很多不同的系统，每个系统自己遍历自己关心的对象，只有使用预定义组件部分可以被子系统感知到，这样的系统具有很强的内聚性。
二. ECS作用
ECS的设计就是为了管理复杂度，其指导方法就是：Component是纯数据组合，没有任何操作数据的方法；而System是纯方法组合，它没有自己的内部状态，它要么做成无副作用的纯函数，根据它所见到的对象Component组合计算出某种结果；要么用来更新特定Component状态。
在System之间也不用相互调用（减少相互耦合），是由游戏外部框架来驱动若干System的。这样一来每个System都可以独立开发，它只需要遍历框架提供给他的组件集合，做出正确的处理，更新组件状态就够了。而编写Gamplay的人只需要清楚每个System到底做了什么，操作本身对哪些Component产生影响，正确书写System的更新次序就可以了。这样一来容易管理复杂度，二来哥并行处理留下了优化空间（是不是感觉和Unity3D有种莫名的相似感？实际上Unity中大量地方采用了ECS设计思想）。
三. ECS的数据处理
由于System只是对定义好的Component状态的加工过程，那么就会有多个System中处理同一个问题，涉及到相同的Component的情况。当这个问题只相关到一个Entity时，还可以设计出一个System逐个把结果计算出来存为Component的状态；但是当这个问题涉及到多个Entity时候，或者这个行为并不想额外修改Component的状态，保持无副作用。
这个时候就需要引入Utlity函数概念，Utility函数是共享给不同的System调用。为了降低系统复杂度，就要求函数是无副作用的，或是仅仅在很少的地方调用；如果副作用实在存在，又会在很多System中触发，那么就先将行为发生时需要的状态保存起来，放在一个队列里，由一个单独的System在独立环节来处理，推迟到当前帧末尾或下一帧开头来做。
四. ECS的优劣
相比于传统的OOP1，ECS在写法上要复杂很多，一个对象可以集中的数据来用多个Component来管理，还要额外的System来处理逻辑。但是，ECS它做到让设计分离了，由此的影响如下：
- 减少多人开发时出问题的概率
如果有一个非常复杂的对象，许多人的工作都和这个对象有牵连，当A在进行逻辑处理时，他不得不传整个对象，还要考虑修改对其他人的影响；但是拆离后，A可以把自己的数据封在特殊的Component里，用自己的System处理，减少出问题概率（但是这样会增加代码复杂度）；
- 基于组合优于继承原则
组合优于继承2，这是设计层面上的原则，而ECS的Entity则是Component的组合，提高了复用性，也方便我们只关注处理对下对象的某个局部；且当我们对某个功能进行拓展时，几乎不会影响到其它功能模块，因为每个部分都是几乎不关联的；
- 容易预测和回滚
ECS的初衷就是为解决预测和回滚的，因为数据和状态都存储在Component里面，因此记录关键帧的数据和状态非常方便，这就使得实现预测和回滚容易许多；
- 适合游戏开发层面做逻辑表现分离
同一套逻辑处理系统，加了表现组件就有了表现，可以放在客户端，不加的话就是纯逻辑，放在服务端确认客户端回传的数据。一套代码又能做服务器又能做客户端；
- 提升性能
ECS这种面向数据的方式，使得内存排列天然紧密，非常适合现代CPU的缓存机制，极大增加了CPU的缓存命中率3，大幅提升了性能。
- ECS的劣势
ECS在处理大批量数据上有明显的优势，但是在处理小数据上如UI层面，网络层面上等就不太适合使用。而且Component本身不知道哪些System关注它，System也不知道什么时候关注的Component发生改变，即无法做到自驱动，必须有外部的东西来驱动这些System去工作，其实还需要许多Utility来辅助工作。
————————————————
版权声明：本文为CSDN博主「夏日蛙鸣」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xiegy_august/article/details/105557655
