DOTS是什么？
?
DOTS是給幾項(xiàng)優(yōu)化技術(shù)打包起了個(gè)名字，主要還是為了宣傳考慮。
它主要包含3個(gè)技術(shù)：
DOTS系統(tǒng)成熟以后，游戲的腳本邏輯部分會(huì)和現(xiàn)有的組件式系統(tǒng)完全不同。原有腳本寫法和ECS寫法的區(qū)別，比兩種語(yǔ)言的差別要大得多。所以起個(gè)好名字逐步發(fā)展新體系也是必要的。
3、ECS是什么？
首先ECS并非一種全新的技術(shù)，也不是Unity首先提出的。
這種技術(shù)的出現(xiàn)非常早，而近幾年突然火爆，是因?yàn)楸┭┑摹妒赝蠕h》。《守望先鋒》的服務(wù)器和客戶端框架完全基于ECS構(gòu)建，在游戲機(jī)制、網(wǎng)絡(luò)、渲染方面都有非常出色的表現(xiàn)，這種技術(shù)上的巨大成功，必然會(huì)引領(lǐng)一波ECS的潮流。
這篇GDC分享3年前火了一陣
ECS不屬于某種“設(shè)計(jì)模式”，之前我們常說(shuō)的“設(shè)計(jì)模式”是在面向?qū)ο蟮目蚣苤掠懻摰?#xff0c;而ECS完全是另一種面向?qū)ο蟮木幊谭椒?/strong>，它對(duì)傳統(tǒng)編程方法的顛覆性比Actor模式更強(qiáng)。至少目前來(lái)看，ECS僅適合于游戲開發(fā)領(lǐng)域。
系統(tǒng)是程序邏輯的載體，游戲中有很多System會(huì)反復(fù)執(zhí)行。每個(gè)System執(zhí)行時(shí)它不管什么Entity，而只做兩個(gè)步驟：
一個(gè)游戲中，大量的Component每一幀被很多System修改，就形成了游戲邏輯。
那為什么說(shuō)ECS非常厲害呢？關(guān)鍵是：
4、ECS目前的發(fā)展阻力是什么？
通過(guò)前面的介紹可以看出，ECS可不是什么“易學(xué)易用”的新技術(shù)，它對(duì)現(xiàn)有的開發(fā)模式，甚至現(xiàn)有的Unity編輯器來(lái)說(shuō)都是顛覆性的。
不僅如此，ECS對(duì)初學(xué)者來(lái)說(shuō)有著巨大障礙：除了游戲技術(shù)圈，人們很難在任何其它地方學(xué)到ECS編程方法。
無(wú)論你在什么地方學(xué)習(xí)編程，能搞清楚傳統(tǒng)的面向?qū)ο笠呀?jīng)很不錯(cuò)了，ECS只能在你有一定編程基礎(chǔ)后，通過(guò)網(wǎng)絡(luò)資料實(shí)踐自學(xué)。這一問題在ECS的推廣方面是致命的。
因?yàn)镋CS這一技術(shù)本身還是比較新穎的，高手們都還沒有把ECS系統(tǒng)摸透，沒有系統(tǒng)化，更別提能夠在不誤人子弟的前提下教會(huì)新人。
但是話說(shuō)回來(lái)，ECS雖然是一種全新的編程思想，但對(duì)于一些專業(yè)開發(fā)者來(lái)說(shuō)并不難，比如咱們專欄里已經(jīng)有寫過(guò)一些實(shí)踐分享：
ProcessCA：Unity 實(shí)體組件系統(tǒng)（ECS）——性能測(cè)試
zhazha chen：Unity ECS 高性能探索
對(duì)于專業(yè)開發(fā)者來(lái)說(shuō)，目前在Unity中實(shí)踐ECS，阻力來(lái)自于：Unity官方對(duì)于DOTS依然是緩慢開發(fā)中，還遠(yuǎn)遠(yuǎn)談不上成熟。
例如，由于ECS的游戲?qū)ο蟛辉偌嫒菰瓉?lái)的GameObject，導(dǎo)致ECS物體在場(chǎng)景編輯器中看不到。如何解決官方給出了至少兩種方案：加個(gè)代理適配，或是徹底換成新編輯器窗口（比如Entity Debugger之類的工具）。但是這些方案都還不完善…… ：）
還有ECS在渲染方便和原系統(tǒng)存在兼容問題，雨松Momo的ECS分享視頻中，用了較多篇幅解釋在DOTS技術(shù)棧下如何妥善渲染。可以看出問題還很多，針對(duì)不同項(xiàng)目要考慮不同的方法。
5、我們應(yīng)該如何看待DOTS？
重點(diǎn)是，雖然Unity的DOTS技術(shù)存在巨多問題，無(wú)論Unity ECS還是Burst，說(shuō)起來(lái)都是各種吐槽。但作為專業(yè)的軟件工程師，應(yīng)當(dāng)以最大程度的積極性擁抱這些新技術(shù)。
縱觀歷史，新技術(shù)出現(xiàn)時(shí)總是帶著一身毛病——還沒馬車跑得快的汽車，還沒蒸汽機(jī)好用的內(nèi)燃機(jī)，還沒滑膛槍可靠的線膛槍，感覺隨時(shí)會(huì)核爆的核電站。一切當(dāng)今習(xí)以為常的東西，在當(dāng)年都被無(wú)情地嘲笑過(guò)。
就算發(fā)展慢、就算發(fā)展中出現(xiàn)下滑和反復(fù)。ECS技術(shù)在內(nèi)存布局、緩存友好性、多線程友好性等方面達(dá)到了傳統(tǒng)編程模式望塵莫及的高度。甚至可以說(shuō)，很常規(guī)的ECS代碼就已經(jīng)能達(dá)到某些深度優(yōu)化過(guò)的傳統(tǒng)代碼的性能。
所以從發(fā)展趨勢(shì)看，我們沒有理由故步自封、拒絕這一新技術(shù)。
PS：話說(shuō)回來(lái)，現(xiàn)在學(xué)DOTS并不是現(xiàn)在就要用到商業(yè)項(xiàng)目里。在商業(yè)項(xiàng)目中，采用這種尚不成熟的新技術(shù)一定要得到團(tuán)隊(duì)的一致同意和Leader的支持，否則就是非常不負(fù)責(zé)任的決定。 ：）
?
?
瀉藥，個(gè)人觀點(diǎn)有3條：
ECS的思想其實(shí)從十幾年前機(jī)能嚴(yán)重不足的時(shí)候，到現(xiàn)在都一直在影響游戲開發(fā)行業(yè)，無(wú)論是里邊有過(guò)程式編程的影子，還是函數(shù)式編程的影子，亦或是針對(duì)緩存和CPU密集運(yùn)算的優(yōu)化思想，都是在切實(shí)的解決游戲邏輯和渲染中的痛點(diǎn)，而且即使不是純ECS，許多團(tuán)隊(duì)的框架也在向這個(gè)方向靠攏。Unity的ECS一方面完成度太低，之前看到版本號(hào)還是0.x，就比較尷尬，另外從我個(gè)人自私的角度分析（本人是個(gè)寫渲染的）就是沒大有和渲染層接壤，比如VLK和DX12這種現(xiàn)代的API是可以直接并行產(chǎn)生PSO，并行準(zhǔn)備CommandBuffer（CommandList) 等等，在這些方面Unity只提供了SRP這種很上層的封裝，很難將Job System和ECS靈活的應(yīng)用上去。
Job System這種線程調(diào)度方式，應(yīng)該是同步多線程中速度最快的方法，因?yàn)殛?duì)列數(shù)量提前可知所以幾乎不存在高消耗的鎖和等待，同時(shí)一次性觸發(fā)不會(huì)涉及到上下文，線程啟動(dòng)消耗等。但是官方的Demo好像有涉及到一些異步多線程，個(gè)人認(rèn)為Job System這種一次性觸發(fā)的設(shè)計(jì)模式并不適合異步多線程，平時(shí)我在開發(fā)時(shí)也經(jīng)常會(huì)用到Job System這種多線程思想，對(duì)性能的提升大有裨益。
之前有人問Job System，Unreal的Task Graph有什么關(guān)系和區(qū)別，看起來(lái)Task Graph在設(shè)計(jì)時(shí)更多的考慮了異步能力，而不是這么注重一口氣憋住的同步能力，而且Unreal官方似乎推薦使用Task作為延時(shí)的邏輯觸發(fā)，而Unity推薦使用協(xié)程做等待，讓其他線程做純運(yùn)算，在設(shè)計(jì)理念上應(yīng)該存在一些不同，本人在此不置褒貶。
Burst據(jù)說(shuō)是處理SIMD的效果很好，經(jīng)過(guò)一些測(cè)試發(fā)現(xiàn)效果也確實(shí)不錯(cuò)，但是平常這種優(yōu)化手寫也是能做到的，所以究竟和平常手寫的帶_m128這種的數(shù)學(xué)庫(kù)，比如DX提供的DirectX::XMVECTOR DirectX::XMMATRIX有多少提升，這一點(diǎn)還有待探索，這里持保留態(tài)度。
?
引用：https://www.zhihu.com/question/363824849/answer/1069372037
總結(jié)
- 上一篇： 动态规划算法——最长公共子序列求法
- 下一篇： Java算法训练：沙盘上的字符串