近期在游戲demo中試驗ECS， 深入研究Unity官方的ECS框架和第三方Entitas框架， 分享下使用ECS的心得。

Unity在2018版中加入了ECS系統， 但處于小白鼠階段。默認不是Unity的一部分， 需要手動下載代碼并導入Packages（新特性）。官方提供海豚例子， 但除此之外例子和資料非常少。所以完全無法，也不敢在demo中貿然引入這種系統，所以放棄官方ECS系統。

第三方的Entitas（https://github.com/sschmid/Entitas-CSharp）ECS框架從2015年就開始在各地演講中介紹。整體框架基于代碼生成， 能解決一部分的代碼爆炸問題， 而且性能也要好一些。例子，介紹非常豐富，例子雖然基于不同版本的Entitas，特性支持和最新版差不太多， 只是寫法有細微差異， 對于理解來說無礙。

經過1~2天的改造， 終于將demo從傳統Unity寫法改造為ECS標準寫法，新增了46個文件， 而傳統邏輯一共只有16個文件，大概對比下ECS的特點和差異。

Entitas的ECS系統

1. 本來在一個對象中添加一個類字段的過程，ECS需要添加一個類代表Component，并且代碼生成。

這個字段一般用于描述對象的資源，處理顯示的GameObject， 表示對象的類型等。

2. 本來一個對象的業務邏輯處理過程直接用方法解決的， ECS需要新加一個System，而操作對象需要使用Filter或Group查詢獲得。

3. 一系列的操作， 需要拆分為多個System和Component拆分處理。如果System順序不對， 會造成一些詭異的bug。

4. Component不僅僅是Model承載體， 也可以是參數的數據結構。參數Component通過Entity傳遞到System處理。 例如： 通過ECS創建一個方塊的過程，使用CreateTileComponent，包含創建Tile的位置， 創建Entity并添加CreateTileComponent， 在CreateTileSystem中處理就創建了Tile，處理完成時， 需要將傳入的Entity.Destroy掉。

6. Entity上修改Component的過程， 會觸發事件。修改的過程需要使用RelaceXXX，XXX表示組件名。組件可以頻繁修改， 不用擔心添加和刪除組件過程的性能， Entitas底層處理性能只相當于指針賦值的性能。

ECS像什么？

1. ECS中的System類似觸發器系統（Event-Condition-Action），其中，Event對應Entitas的GetTrigger+Collector，表示觸發事件。Condition對應Filter表示在事件來源對象中找到需要的對象。 Action對應Execute，表示實際的操作。

2. ECS中的Component類似不用lua擴展的Redis或者不用存儲過程的MySQL， 純粹純數據， 而不能對數據有任何封裝操作。沒有lua和存儲過程支持的db寫起來還是比較費勁的，但ECS就是那么的純。

3. ECS中的Entity很尷尬，因為Component是按類別連續存儲的以保證性能。 邏輯又需要Entity組合成邏輯需要的復合對象。 兩邊都要照顧，所以這種設計就讓代碼量巨增，可讀性下降。

ECS企圖用一套框架滅掉設計模式

1. 單件（Singleton）在Entitas用Unique標簽標記Component， 在Context中就是唯一的， 其實也就是Singleton。

2. ECS干掉了傳統的工廠模式，底層統一對對象（Entity）和屬性（Component）統一管理。需要按Component中的值找回Entity時， 可以使用EntityIndex。

3. Entity攜帶不同的組件時，整個創建和銷毀過程被記錄并恢復，其實就是Command模式

ECS適合做UI框架（類似MVVM，MVC,MVP）么？

ECS不是專用的UI框架，但是可以對不同系統和數據間解耦。傳統代碼中數據修改后的Callback，ECS也可以用Listener做， 但Listener因為能保存數據， 就需要用Component保存。 所以你需要面對的是，一個Button，響應創建一個參數用的Component和System，還要為數據改變寫一套ListenComponent和Listener處理的System，酸爽吧？

Minecraft適合ECS來做么？

可以，性能應該能提升不少，但是代碼會更繁瑣，特別像Java這種啰嗦語言配上ECS這種啰嗦框架，估計代碼量翻翻還是很輕松的。MC屬于特殊類型的游戲，適合特殊領域特別優化，也就是專門為方塊做出特別的設計來做優化。ECS屬于通用框架，即便性能OK，但是代碼未必能有良好的可讀性。

體量小的游戲適合用ECS來做么？

可以，但不建議。特別是只有幾個人維護的工程，貿然上ECS系統，會讓系統變的極為復雜。當然你會說，如果開發到后期，傳統開發模式會導致代碼會亂，ECS會好些吧。掌握ECS也不是一天兩天的事情，不熟悉ECS的程序員設計出來的系統獲得的優勢可能還不如用傳統設計方法好呢。

架構解決的是人的問題， 人都有問題，用什么框架都沒辦法。

到底什么項目適合用ECS？

1. 大量的小個體不斷的生成和銷毀以及顯示，例如： 攻城戰中，要體現每個角色的移動，戰斗。

2. 多于5個人編寫核心戰斗邏輯。互相協作和模塊切分，需要一個大家都能信服的框架，ECS可以選擇。

P.S.

不要造ECS的輪子！

很多同學看了ECS基本原理，在沒有深入使用過任何ECS系統時馬上操刀造輪子。ECS系統確實看起來簡單。實際造下來你會發現，性能非常糟糕以及不知道一些邏輯如何用ECS來解決。

總結：

1. ECS確實為性能而生，沒有并發加持性能的ECS都是耍流氓，要快就要快到極致。

2. Unity中，ECS并發能擴展CPU的利用率，但是GPU的性能依然還是DrawCall優化那一套，別期望ECS會顛覆Unity，性能也不會快到飛起，關鍵還是要看具體的項目和人。

3. ECS是萬能框架，但不全能。傳統架構和設計思想也不是一無是處，熟啥用啥，怎么快怎么來！

無恥的廣告鏈接，請各位支持

《Go語言從入門到進階實戰（視頻教學版）》(徐波)【摘要 書評 試讀】- 京東圖書