有說的不正確或者不准確的地方歡迎留言指正

如果你有感覺不錯的相關文章也可以留言推送給我，不勝感謝~

有什么有趣的寫作技巧或者想法歡迎大家給我留言，大家的幫助是我寫下去最有效的動力

參考資料【有時間強力建議看一下】。。。。。這些資料里面講述的概念筆者很多不怎么理解，哈哈哈

下面是筆者看完這些參考文章后對ECS的理解或引用其中文章的部分解釋

一：在Unity中筆者對ECS的理解

Entity：實體，筆者更喜歡說數據的小集合，例如transform中的、Position、Roitation、Scale，這三個數據組成的集合就可以稱為實體。而且實體可以自由的組裝拆分，例如可以拆分為Position與Roitation、Position與Scale、Roitation與Scale甚至自己編寫的數據集合。
Component：組件。這里提到的組件與傳統組件可不一樣，傳統的組件有點Entity+業務邏輯的意思，里面包含很多數據，但是在ECS中的Component 只是一條單一的數據，例如Position單一的數據是一個Component，Roitation單一的數據也是一個Component，不包含任何的業務邏輯，有點像傳統類中的字段，僅僅就是一個數據。
System：系統，這里的作用就是做行為邏輯操作的地方了，通過對Component自由的組裝成Entity，然后根據規則篩選出Entity獲取到對應的對象，之后進行邏輯操作。而且在ECS中的System是不分場景的，例如有一個負責移動的System，他真的是負責所有場景中對應的移動，不像以往僅僅負責一個場景中一個物體或者子彈單類的移動。

二：一個有關CPU處理數據的概念：CPU多級緩存

什么是CPU緩存???

更詳細來說，結構應該是：CPU<---->寄存器<---->CPU緩存<---->內存
可以看到CPU緩存是介於內存和寄存器之間的一個存儲區域，此外它存儲空間比內存小，比寄存器大。

為什么需要CPU多級緩存:

CPU的運行頻率太快了，而CPU訪問內存的速度很慢，這樣在處理器時鍾周期內，CPU常常需要等待寄存器讀取內存，浪費時間。
而CPU訪問CPU緩存則速度快很多。為了緩解CPU和內存之間速度的不匹配問題，CPU緩存則預先存儲好潛在可能會訪問的內存數據。

CPU多級緩存預先存的是什么：

時間局部性：如果某個數據被訪問，那么在不久的將來它很可能再次被訪問。
空間局部性：如果某個數據被訪問，那么與它相鄰的數據很快也能被訪問。
CPU多級緩存根據這兩個特點，一般存儲的是訪問過的數據+訪問數據的相鄰數據。

CPU緩存命中/未命中：

CPU把待處理的數據或已處理的數據存入緩存指定的地址中，如果即將要處理的數據已經存在此地址了，就叫作CPU緩存命中。
如果CPU緩存未命中，就轉到內存地址訪問。

提高CPU緩存命中率

要盡可能提高CPU緩存命中率，就是要盡量讓使用的數據連續在一起。

冷數據/熱數據分割

有人可能認為這樣能最大程度利用CPU緩存：把一個對象所有要用的數據（包括組件數據）都塞進一個類里，而沒有任何用指針或引用的形式間接存儲數據。
實際上這個想法是錯誤的，我們不能忽視一個問題：CPU緩存的存儲空間是有限的
於是我們希望CPU緩存存儲的是經常使用的數據，而不是那些少用的數據。這就引入了冷數據/熱數據分割的概念了。

熱數據：經常要操作使用的數據，我們一般可以直接作為可直接訪問的成員變量。
冷數據：比較少用的數據，我們一般以引用/指針來間接訪問（即存儲的是指針或者引用）。

三：原來的OOP模式為什么越來越慢了？

oop模式的主要的思想就是萬物皆對象，調用的方式幾乎都是以對象為基礎，以模塊化編程的帶來優勢的同時，也有他的負面效果：冗余數據過多，包袱過重。舉個例子：在旅行時是一個人帶一張信用卡去還是帶一堆的生活用品去會更方便呢？答案當然是前者，只需要帶着有用的東西就可以了，無用的都可以丟掉。oop其實也是這個樣子，在進行數據傳輸的時候（數據讀取）總會帶着一些無用的數據，不僅僅零零散散（傳統方式的內存管理是離散式的），而且還占用空間（上文提到的CPU多級緩存），隨着現在游戲的規模越來越大，摩爾定律的失效，單純的提高主頻達到好的計算效果變得越來越力不從心。

四：ECS為什么快？

傳統方式的內存管理是離散式的，即物體和它的組件(Component)並非在同一個內存區段，每次存取都非常耗時。而ECS會確保所有的組件資料(Component Data)都緊密的連接再一起，稱為Archetype，這樣就能確保存取內存資料時以最快的速度存取（也提高命中率）。
數據量身定制化，不會有多余的數據，例如Position原有的Vector3換成了現在Float3，列表等換成了unity重新定的Native開頭的數據結構，分為並發和非並發執行。IJob、IJobParallelFor或 IJobParallelForTransform會根據是否單核還是多核分別選擇接口，SharedComponentData和ComponentData等等。這種量身定制或數據也帶來了更多的選擇性和靈活性，隨之通用性也就降低。
這種多核心並行計算也符合現在硬件的發展趨勢，摩爾定律的失效，以增加核心數量帶來的計算力不斷的提升是現在主流的現象。

五：ECS目前能做多好

根據官方介紹，此項目包含450萬網格渲染，5000輛動態汽車，10萬種獨特的聲音效果，每棟建築的零件達到20萬個，並且還能以60fps的幀率穩定運行。另外，視頻的結尾部分還公開了一段手機平台的演示，官方特別指出這絕不是使用手機播放了一段視頻，而是真正用Unity生成APP，再在手機上運行的畫面。這款demo和所有資源將於2019年發布。

視頻地址：https://pan.baidu.com/s/1PyS3dAi3JJ0WTuPlAIyrRQ?fid=361764147543922
地址：https://blogs.unity3d.com/cn/2018/10/24/a-peek-at-the-new-visual-effect-graph-cinecast-our-first-sample-game-and-more-from-unite-los-angeles/

作者：su9257_海瀾
鏈接：https://www.jianshu.com/p/fd2d221cad9f
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 GBDT理論知識總結 JWT理論知識 DDD領域驅動設計基本理論知識總結數據庫理論知識點總結域控理論知識 java基礎理論知識的一些總結 NLP - 糾錯理論知識一 APPIUM基本理論知識關於I2C的理論知識帆軟FCRA理論知識

Unity Entity Component System 理論知識總結