參考鏈接 :
https://connect.unity.com/p/part-1-unity-ecs-briefly-about-ecs
http://esprog.hatenablog.com/entry/2018/05/19/150313
已經推出了很久了, 貌似也有一些人開始使用, 我是在看守望先鋒的程式設計相關文章的時候看到 ECS 的, 從它的設計邏輯上看, 核心就是 Composition over inheritance (or composite reuse principle) 組合重用, 也就是對特定的資料組合, 使用特定的處理程序來處理, 跟我們一般的 OOP 有點差別, 它是以資料組合為物件的.
很多人都把它描述成高效運行的框架, 而我看守望先鋒它也是這樣定義的, 那么這個框架到底高效在哪里呢? 從我的主觀來看, 它只不過是換了一種程式設計思路, 就跟我們寫 UI 邏輯的同學之前把邏輯啊資料啊網路啊都寫在 UI 腳本中然后突然有一天他用了 MVC 的模式把資料和邏輯分開了一樣, 區別只在復用性和維護性上, 并不構成高效的保證. (2020.03.02 重新看了一遍, 守望先鋒那篇文章, 他們使用ECS的目的是為了解耦, 解耦, 解耦! 而不是為了提高框架效率, 這個應該可以簡單理解為一個強制MVC框架).
再看看它的處理資料的程序, 當資料都進行正確的分組之后, 可以經過處理邏輯一次性地處理批量資料, 這個叫 Batch Processing 的程序就有點渲染管線的味道了, 姑且不說這個批處理能高效多少, 至少在各種需要 Update 計算的邏輯上能物理上限制人為錯誤導致性能問題, 因為很多同學直接添加 Update 函式然后寫更新邏輯, 數量巨大的話呼叫開銷讓人受不了的.
來看看它現在提供的 ECS 的可能的擴展, 看出 ECS 大致有三種模式 :
1. Pure ECS
2. Hybird ECS
3. ECS on Job
真正能提供性能提升的應該就是 Job 系統了, 包含多執行緒, 記憶體 layout 之類的提升, 其實按照數量級來看, UI底層框架 / 影片 / 粒子特效 這些才是量級較大并且跟實際開發沒有太大關聯的東西, 我們真正開發中寫的上層邏輯比如戰斗, 除掉影片和特效也就只有人物位移之類的少量控制了, 即使用上 ECS + Job 也應該沒有很明顯的提升, 最近出了一個叫 UI framework for DOTS 的基于 ECS 的 UI 框架系統, 也有些 ECS 的影片系統, 應該大方向還是在修改這些上, 明天下載一些例子來看看.
{ 這幾天去考科目三, 教練簡直牛人, 考試前一天晚上18點去考場練習, 跑到第二天早上4點, 簡直了, 旅館睡3小時爬起來就去考, 加上回家坐車3個多小時, 一次來回讓人幾天都沒精神了, 然后科目四還掛了... (2020.01.02) }
PS : ECS系統沒有包含在Unity安裝包里, 是個插件, 要自己通過Package Manager下載或者修改Packages/manifest.json檔案讓編輯器去安裝, 有點像安卓庫.
==================== 繼續測驗(2020.01.08) ====================
按照常理來說, ECS 的框架設計應該是脫離引擎的, 它只需要對它要處理的資料負責, 所以就有了 Pure ECS / Hybird ECS 的區別, 我下載來兩個例子很有代表性, 先看最簡單的 Hybird ECS( 混合式 ECS) :
我們在場景中創建10000個自動旋轉的正方體, 用 ECS 的方式進行旋轉邏輯:
using UnityEngine; public class EntryScript : MonoBehaviour { public GameObject Cube; private void Awake() { if(Cube) { for(int i = 0; i < 10000; i++) { var copy = GameObject.Instantiate(Cube); copy.transform.position = UnityEngine.Random.insideUnitSphere * UnityEngine.Random.Range(1, 1000); } } } }
我們在 Cube 上進行添加 ECS 的組件 ( RotationComponent ) 和指定它為 Entity ( GameObjectEntity ) :
GameObjectEntity 是系統自帶的, RotationBehaviour 是我們自己添加的, 它充當了一個資料型別 :
using UnityEngine; public class RotationBehaviour : MonoBehaviour { public float speed = 135.0f; }
RotationComponent 就是 ECS 的資料集合 Component, 當 Entity 符合有這個資料集合的時候, 會有相應的 System 被呼叫 :
using UnityEngine; struct RotationComponent { public RotationBehaviour rotation; public Transform transform; }
這樣 Entity 和 Component 都有了, 我們要添加一個 System 來操作這個資料 :
using UnityEngine; using Unity.Entities; public class RotationSystem : ComponentSystem { protected override void OnUpdate() { foreach(RotationComponent component in GetEntities<RotationComponent>()) { component.transform.Rotate(0f, component.rotation.speed * Time.deltaTime, 0f); } } }
可以運行, 里面的正方體在旋轉.
不過感覺跟效率什么的沒什么關系, 這是混合ECS(Hybird)的特點: 使用方便, 符合用戶習慣, 對于理解上來說也很方便, 一個游戲物體掛上GameObjectEntity, 它就是一個ECS物體了, 當它掛上RotationBehaviour它就是有旋轉行為的物體了, 我們要實作這個旋轉邏輯, 在RotationSystem里面寫就行了, 很清晰.
不過凡事還是要分兩面看, 一個效率又高, 開發又快的框架, 它的 開發/維護 難度在哪呢? 我覺得是在需求變更上, 如果一個系統它需求經常變更, 就不適用ECS. 反之比如UI系統, 它的坐標計算, 組件功能都是確定的, 沒有太多的變化, 就很合適使用ECS, 然后ECS的組件沖突在實際開發中是否會大量出現, 很依賴于程式設計, 初期設計不好, 后期需求變更后牽一發動全身. 如下在上面的基礎上B同學寫了另一個旋轉邏輯:
運行斷點, 發現兩個System都進來了, 因為旋轉相反, 正方體都不動了. 這種全域的系統最先想到的就是程式設計沖突, 本來相同的資料(Transform + RotationBehaviour)在不同的地方有不同的意義, 這就是面向物件的思維, 而這個系統是全域的, 它只要有這兩個組件在, 它就運行, 如果一個同學想用它旋轉特效(主要Y軸), 一個人想做個UI旋轉(主要Z軸), 那就特效和UI都在Y軸+X軸旋轉了. 為了解決這個沖突, 有那么幾種修改方案:
1. 給RotationBehavuour添加繞哪個軸旋轉的功能, 然后在RotationSystem里面去判斷, 也就是說B同學在已有的基礎上進行修改.
這樣修改的話, 就可以符合兩個人不同的需求了, 并且在原代碼的基礎上做修改, 比較簡單. 可是放在專案中, 就沒那么簡單了, 這個依賴于序列化的功能, 數量可能很大, 在后期有變更的時候維護起來能煩死人, 特別是一些開發到一半的專案.
并且, 在使用ECS系統的時候, 它并不按照組件的生命周期進行ECS的生命周期管理, 比如我在某個物體上運行時洗掉RotationBehaviour這個腳本, 也不影響它被ECS參考的事實, 并且導致"null"物件
這里運行時刪掉了腳本
斷點能夠看到, 它被洗掉了, 可是參考仍然被ECS參考過來, 成了"null"物件
所以可以看到ECS如果作為上層邏輯它是有很多缺陷和不足的, 特別是需求無限變更的專案組, 打個比方就像拿 Compute Shader 來做所有的計算一樣不一定合適.
PS : 有個很可怕的問題, 在修改了哪個軸向旋轉之后, 我想到按照這個邏輯我動態添加Y旋轉和X旋轉的話我要怎么寫代碼才能實作?
果然, 如果同一個Entity使用兩個相同的組件, 就報錯了 : ArgumentException: It is not allowed to have two components of the same type on the same entity. (RotationBehaviour and RotationBehaviour)
這是一個問題, 改一下看看:
結果就是覆寫式的了, 如果我們不執行Delete操作, 直接改變軸向, 只是產生了新的Entity, 老的Entity沒有執行Exit操作的話, 是否會導致一些記憶體泄漏就不知道了, 這個還需要測驗. 這種情況下繞軸旋轉的功能就無法疊加了, 只能繞某個軸旋轉, 所謂的擴展性受限. 當然解決的辦法很多, 可是單從這個例子就看出問題了.
這樣看來它也能做類似決策樹這樣的結構, 比如A, B, C三種debuff, AB同時存在時角色被減速, AC同時存在時角色被定身, BC同時存在時角色死亡, 這樣每次加debuff的時候就AddToEntityManager, 關聯資料就自動被相應系統處理了哈哈.
2. 另外添加一套旋轉系統, 就叫RotationBehaviour_UI, 系統就叫RotationSystem_UI之類的, 這樣不會影響到已有的系統, 減少耦合性. 可是一個系統就變成兩個了, 如果隨著開發越疊越多, 兩個變四個, 四個變八個, 求解2的N次冪.
好了上面就是通過混合型ECS的例子能想到的對于開發的影響, 東西是好, 可是用在刀刃上才是好. 因為ECS有學習成本并且跟我們的開發習慣有差別, 如果是一個封閉的系統比如尋路, 蒙皮, 粒子等肯定很好, 如果是上層邏輯, 這就要小心使用, 因為對某些功能是些理論上無解的.
下來是Pure ECS的例子, 它已經使用了Job系統了, 感覺比較混亂, 估計也是對ECS on Job不是太明白.
PS : 比較老的版本(2018.3)例子, 新版本有變更, 比如 [ComponentDataWrapper and SharedComponentDataWrapper have been renamed to ComponentDataProxy and SharedComponentDataProxy] 這些.
先來看看運行時的情況:
它在一個圓圈范圍上生成了一些正方體, 正方體的Prefab如下:
可以看到, 正方體它是沒有MeshRenderer組件的, 只是有個MeshInstanceRendererComponent組件對相關資源有參考. 也就是說Prue ECS它是脫離引擎組件來運行了, 下面還有各種PositionComponent, RotationComponent等代替了引擎原有的組件系統, 這樣做有什么好處呢? 先看它運行時Entity Debugger的資訊 :
最終這些Entity沒有GameObject物體, 它們是通過EntityManager進行實體化的, 所以只在Entity Debugger面板中能查看到, 并且顯示了它被多個System控制的情況, 那么它脫離引擎組件的好處在哪呢? 下面通過代碼來分析:
看看RotationSpeedComponent / RotationComponent組件的組合作用, RotationComponent代替Transform的旋轉, 和渲染系統一起作用來渲染物體的旋轉, 而RotationSpeedComponent組件跟它組合的時候, 受到RotationSpeedSystem這個系統的控制, 隨時間改變物體的旋轉.
至于它的繼承關系的說明, IComponentData指示了更高效的存盤結構, 所以IJobProcessComponentData系統的輸入輸出直接使用 IComponentData, 必須繼承它, 可以看到Rotatoin類是ECS自帶的, 它的旋轉變數quaternion使用了 Unity.Mathematics 庫, 我對它比較疑惑, 雖然說為了BurstCompile能提高NativeCode的效率, 因為看代碼沒有什么高效性的東西除了一堆 [MethodImpl(MethodImplOptions.AggressiveInlining)] 屬性.
然后是自旋系統RotationSpeedSystem已經繼承于JobComponentSystem了, 這是專門提供給ECS用的Job擴展, 它的OnUpdate函式跟ComponentSystem有點不同, 回傳的是一個JobHandle, 看檔案它應該就是一個Task之類的, 因為我還沒看Job系統的介紹, 估計是多執行緒的吧, 因為它脫離了引擎的組件嘛. 這里看到了高大上的 [BurstCompile] 屬性, 提高編譯后代碼質量的......
這里的旋轉邏輯寫到了RotationSpeedRotation里面去了, 它繼承于 IJobProcessComponentData 也是Job系統提供的, 應該在計算上提升最大的點就在這里了, 所以配上了 [BurstCompile] 屬性吧... 接下來就是旋轉系統怎樣使用它了, System通過OnUpdate回傳它的JobHandle來完成計算, 經過測驗System的OnUpdate在主執行緒中運行, 而 RotationSpeedRotation的Execute是在多執行緒中運行的.
這樣就明白了Pure ECS的作業原理和性能暴力的點了, 首先通過脫離引擎自帶的一些組件, 提供了在多執行緒上運行能力, 解放了主執行緒, 然后是它Job系統和BurstCompile, PHC之類的提高運行效率的能力. 總之很好很強大, 希望Unity能把引擎自帶的性能大戶改成ECS的吧, 這樣開發者就可以不那么頭大了.
說回來ECS因為沒有物體, 并且在Debugger面板上看到的物體串列沒辦法跟渲染出來的東西一一對應啊, 哪個是哪個根本不懂, 就跟Shader一樣, 哪個像素我不知道...... 打斷點的話也和跟蹤行為樹一樣有時候找不到頭腦的樣子.
然后是有點讓人疑惑的地方, 從Hybird ECS那里就一直有的: 系統是怎樣知道這個系統在處理哪些資料的呢? 或者反過來哪些資料被哪個系統處理的? 看下圖:
這個系統就跟普通MonoBehaviour一樣, OnUpdate是每幀呼叫的, foreach之中的函式才是處理資料的, 然而在Entity Debugger中能顯示出來Entity是被這個系統控制的, 其實挺有意思的:
(2020.03.04)
漏了另外一種直接使用ECS的方式了, 這個在工程中也有使用, SpawnRandomCircleSystem它被用來創建那些正方體. 看看代碼上它是怎樣使用的, 這個用法在Unity Connent上有文章說 :
https://connect.unity.com/p/part-1-unity-ecs-briefly-about-ecs
這個Group是當前系統的資料集合, 說明當前系統處理這些資料組合, 資料都要繼承于IComponentData或者ISharedComponentData介面, 這里的 [Inject] 屬性就是我上面說的, 你怎么知道當前系統處理的是哪些資料的問題, 有了Inject標簽才能解釋的通啊......
然后是它的陣列型別, SharedComponentDataArray<T>, ComponentDataArray<T>, 陣列也要符合繼承于IComponentData或者ISharedComponentData介面, 所以需要這兩個容器.
然后是 [ReadOnly] 屬性, 說明是 : The ReadOnly attribute lets you mark a member of a struct used in a job as read-only. 是一些多執行緒的問題, 為了高效性的話, 使用SharedComponentDataArray<T>容器.
SharedComponentDataArray不是 [NativeContainer], Job系統需要NativeContainer才能操作記憶體, 可能只讀形式的記憶體不需要吧..
コピーするデータはBlittableデータ型 (マネージコードとネイティブコードの間で渡されたときに変換を必要としないデータ型)のみで、JobSystemではこれに該當する型にしかアクセス出來ないという制約があります，
PS : 這樣看來, 單是資料型別的確定就已經比較糟糕了, 如果你希望系統在處理某些資料能高速并行訪問, 就要使用 SharedComponentDataArray 容器, 然后它要求的資料要繼承于ISharedComponentData介面, 這樣就需要在使用中根據需要反過來修改資料型別了, 而資料有多個系統共用的話, 就麻煩了......
PS : 這個例子里看出來, Unity把原組件拆分出來了, 可以減少不必要的組件, 比如Rotation, Position這些從Transform分離出來了, 你可以用可以不用... 喂喂喂, 難道Unity覺得我們都是做3A級游戲的嗎? 這種簡直像是重做一遍引擎框架的事情學渣們能做出來嗎? 或者說這個是為了以后走向電影市場做的準備嗎?
不管怎樣, 有人用在尋路上, 有人用在蒙皮上, 潛力很大, 使用設計上難度很高.
從這兩天看的官方檔案以及各個博客來看, 跨版本間的ECS系統差別很大, 至少API上差別很大, 從2018到2019至少有三個API版本, 估計還在開發中. (2020.03.04)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/6756.html
標籤：其他
下一篇：醫院時鐘系統的技術問答京準來解讀