和從前說再見

看完前面兩篇文章，開發(fā)者們不淡定了，有很多朋友私信麒麟子說：
“加了這么多東西，性能能行嗎？”

能行，不僅沒降，反而在某些方面有大幅提升！

因為“性能提升”也是 3.6 作為重要的 Cocos Creator 里程碑版本規(guī)劃中需要完成的目標。

這篇文章我們就來看看 Cocos Creator 3.6 中關于性能方面改進。

Cocos Creator 3.x 自推出以來，一直就被開發(fā)者們催更性能優(yōu)化。 主要集中在幾個方面：

• 原生性能

• 粒子性能

• 2D渲染性能

關注這幾個問題的朋友們，是時候打開香檳，啟動 Cocos Creator 3.6 ，和它們說再見了！

接下來，我們從實測結果數(shù)據(jù)，以及引擎為此所做的改動這兩個層面，分別講解 3.6 中帶來的性能提升。

原生性能

測試數(shù)據(jù)

為了盡可能模擬復雜的執(zhí)行環(huán)境，引擎組選擇了靜態(tài)場景+動畫模型混合的測試用例。

從上圖中可以明顯地看到，同樣的測試用例， v3.6 比 v3.5 高出了50%以上。

引擎原生化

在和引擎組交流后，得到的答復是：“方法比較簡單，就是將原來處于TS層的場景管理、資源管理等模塊，用C++重新實現(xiàn)了一遍”。

方法簡單但并不表示工作量小，引擎組為此付出了一年多的努力。

但從結果上看，這一切努力都是值得的，自 Cocos Creator 3.6 版本開始， Cocos 引擎可以稱得上 “雙核引擎”了，即在原生平臺為C++內(nèi)核，在非原生平臺為JS/TS內(nèi)核。

這種做法在業(yè)內(nèi)并不多見，因為它成本極高。需要使兩套引擎核心保持對等架構，并且維持相同的渲染效果。

但也只有這樣，才能更好地服務相應平臺，在極端情況下為相應平臺做最精細的優(yōu)化。

V3.3 vs. V3.6

左圖為 Cocos Creator 3.3 原生化狀態(tài)，藍色為C++部分，紅色為TS部分，可以看出 v3.3 的狀態(tài)為：

• TS模塊：SeneGraph、Data Driven、AssetManager、Assets

• C++&TS模塊：RenderScene

• C++模塊：RenderPipeline、GFX、FrameGraph

右圖為 Cocos Creator 3.6 原生化狀態(tài)，綠色為C++部分，藍色為TS部分，可以看出 v3.6 的狀態(tài)為：

• TS模塊：AssetManager

• C++&TS模塊：Assets、Data Driven

• C++模塊：SeneGraph、RenderScene、RenderPipeline、GFX、FrameGraph

從這個對比中可以看出，RenderScene 和 SceneGraph 模塊的完全原生化，應該對此次的性能提升起到了主要作用。

從進展來看，目前 Assets、Data Driven 的原生化即將完成，AssetManager 也應該會在后面的版本中得到解決。 離完全原生化的目標實現(xiàn)不遠了，相信屆時 Cocos Creator 的原生端性能又會提升不少。

粒子性能

上面的截圖，來自于團隊同事用 Cocos Creator 做的一個項目，里面的每一根蠟燭，地上的每一團火焰，都是由若干個粒子發(fā)射器組成的。 在 v3.5 中，這個場景跑起來特別吃力，只能關閉一些粒子特效。 但在 v3.6 版本中，場景特效全開的情況下，依然特別流暢。

開發(fā)者們也不只一次提到過，粒子系統(tǒng)的性能限制了美術的發(fā)揮空間，導致游戲效果受限，希望能夠加入粒子合批，提升性能。

3D渲染中的合批有兩種方案：

• 網(wǎng)格合并（Merging Vertex Buffers）

• 幾何體實例化（GPU Instancing）

由于幾何體實例化需要硬件和系統(tǒng)支持，在前幾年的系統(tǒng)中，引擎會選擇在支持的設備中采用幾何體實體化方案，在不支持的設備中退回到網(wǎng)格合并方案，以確保最大的可用性。

但 DrawCall 導致的性能瓶頸本身就以 CPU 側(cè)為主，而網(wǎng)格合并又是以增加 CPU 運算負擔為代價的，用網(wǎng)格合并換 DrawCall 無異于 CPU 資源換 CPU 資源，在某些情況下可能適得其反。

隨著硬件的增強和新版圖形API普及率的提升，幾何體實例化的覆蓋率已接近100%。因此此次粒子系統(tǒng)的合并選擇了幾何體實例化作為合批方案。

注意：Cocos Creator 3.6 及以上版本的 CPU 粒子和 GPU 粒子均支持幾何體實例化（GPU Instancing）方式合批。

與此同時，Mesh 粒子也支持合批了，對于粒子系統(tǒng)而言，不管是 Billboard 還是 Mesh，二者在合批處理上并無差別。

麒麟子用引擎組給的測試用例測試了一下， CPU粒子在545個的情況下，依然能夠保持在30幀以上，如下所示：

想要親自嘗試的朋友，可以自行下載測試案例：https://github.com/cocos/cocos-benchmark?10?，從?lobby?場景進入。

2D渲染性能

Cocos Creator 3.x 的 2D 渲染性能一直備受關注，開發(fā)者最希望的就是有一天 3.x 的性能能夠趕上 2.x 版本。

令人驚喜的是，在 7 月 22 日的社區(qū)公測版本中，就已經(jīng)包含了原生平臺 2D 渲染性能優(yōu)化。如下圖所示：

忍不住要摘抄一下：2D性能在原生平臺各項性能測試已趕上2.x。

從下圖中我們可以看出，在低端設備（HUAWEI-榮耀v9 Android 、iPhone 6s iOS）和中端設備（XIAOMI8 Android、iPhone 11 iOS)上，都取得了滿意的表現(xiàn)。

數(shù)據(jù)來源于Cocos引擎測試報告

費了好大的力氣，麒麟子找到了負責這一次2D渲染優(yōu)化升級的引擎工程師之一，鴨舌同學。了解到了一些2D性能提升的主要工作。

引擎原生化

受益于引擎原生化，許多計算由 TS 改為了 C++，僅從語言運算能力層面的就提升了不少性能。

當模塊改為C++后，C++本身的語言特性，使引擎團隊可以用更多的方法去優(yōu)化性能。 這一部分又帶來了不少提升。

內(nèi)存優(yōu)化

各位沒看錯，2D的內(nèi)存使用量也優(yōu)化了。之所以內(nèi)存優(yōu)化出現(xiàn)在性能優(yōu)化這里，是因為內(nèi)存優(yōu)化也是受 C++ 語言特性而帶來的。

在使用了一些字節(jié)對齊（Byte Alignment）和聯(lián)合體（Union）之后，2D對象的內(nèi)存使用量僅為原來的一半。

TS層優(yōu)化

引擎原生化后，TS層變得更加簡潔了，同時也帶來了一次優(yōu)化結構的機會。 在這個過程中，去除了一些冗余的運算，加入了惰性更新機制。當一個組件的某屬性沒有變化時，不會做運算。

管線優(yōu)化

為了保持統(tǒng)一，減少故障率，3.x 版本中早期的 2D 對象渲染是共享的3D 對象渲染流程，但由于 3D 對象渲染流程的復雜度，無論從CPU開銷，還是內(nèi)存開銷都比純2D高出不少。

在做原生化的同時，也對這個問題做了優(yōu)化，重新梳理了專門的 2D 管線，2D 對象與 3D 對象的渲染完全獨立，確保了 2D 渲染以最小的開銷進行，在CPU運算開銷、DrawCall、內(nèi)存使用量、IO過高導致的耗電和發(fā)燙等方面均有顯著提升。

總結

性能的提升是一個常態(tài)化工作，是每一個版本都會迭代增強的部分。

Cocos Creator 3.6 并不完美，如在包體、內(nèi)存、加載速度等方面還有很大的提升空間，官方的性能測試也不能覆蓋所有的項目情況，更多實際的數(shù)據(jù)還需要開發(fā)者自行驗證并給予反饋。

不過，麒麟子相信，只要持續(xù)不斷地優(yōu)化，將來肯定會全方位超越 2.x，成為一個優(yōu)秀的2D&3D一體化雙核引擎。

不管是?原生性能?、粒子性能還是2D渲染性能，都是開發(fā)者在項目中經(jīng)常遇到且無法繞過的坎，只有引擎將此完善，開發(fā)者才能將自己的產(chǎn)品做得更好。

在這個移動、便攜、可穿戴設備日益精細化發(fā)展的年代，追求性能與效果的極致，成為了最矛盾卻又最剛性的需求。

很高興看到 Cocos Creator 始終在不遺余力地完善編輯器功能、提升開發(fā)效率，與此同時，在增強渲染特性、提升渲染效果的同時依然保持了它雙核引擎（Native與Web）、伸縮性架構（高性能、低功耗，易定制）的優(yōu)勢。

不管是“讓游戲開發(fā)變得更簡單”，還是“以技術驅(qū)動數(shù)字內(nèi)容行業(yè)效率提升”。 在提升生產(chǎn)效率這個關鍵點上，Cocos 始終初心未改，砥礪前行。

寫在最后

至此，關于 Cocos Creator 3.6 新特性的盤點就結束了。

如前文所說，做這個 3.6 版本特性盤點的初衷，是希望給沒有時間去分析新特性的朋友們一個詳細的解釋，挖掘 3.6 中的重要特性、功能改進的價值并呈現(xiàn)到大家面前，以供項目選型和升級決策提供一個有根據(jù)的參考。

值得驚喜的是，通過這一次的盤點，麒麟子也收獲不少。

在盤點的過程中，麒麟子認真學習并梳理了相關細節(jié)，全方位的了解了 3.6 的升級過程以及覆蓋的要點，在以后和開發(fā)者的交流中會更高效、更準確。

在對細節(jié)進行梳理的過程中，也遇上過許多缺失的信息、問題，在與相關同事交流的過程中，更加熟悉了同事們的工作狀態(tài)和方案考量因素，更能理解引擎的發(fā)展路線和下一步規(guī)劃。 同時也特別感謝被我打擾過的同事們，每一位都是知無不言，有的人還手把手教會了我如何使用新特性。

期待下一個引擎版本，這樣的文章，麒麟子還想繼續(xù)寫！