cocoscreatorjs優化的簡單介紹

本文目錄一覽：

• 1、不止想做遊戲，老牌引擎 Cocos 帶著新的Flag出發了
• 2、cocos creator 2.4.0 渲染流程詳解（七：ForwardRender）
• 3、cocoscreator 2.4.x版本 drawcall優化 第一期（掌握控制drawcall數量的必要知識）
• 4、cocos creator視頻播放器載入太慢
• 5、如何評價cocos creator，與unity比的優劣勢
• 6、Cocos Creator 最簡易例子，場景切換，節點掛載腳本

不止想做遊戲，老牌引擎 Cocos 帶著新的Flag出發了

2021年即將過去，對於 遊戲 行業來說，這是概念盛行的一年。人們對於新形態內容的渴望，不僅是對創作者們的視野提出挑戰，更是對他們手上的工具——解放想像力的關鍵技術提出的剛性需求。

對於在全球市場份額佔比超過20%的 Cocos 引擎來說，2021也是碩果累累的一年。不止2D，他們的3D版本一年進行了五次大更新，新功能的添加馬不停蹄；不止 遊戲 ，重新挑戰生態結構，在其他內容領域上開疆拓土。

「數字化內容正在滲透到不同的行業裡面去，這對於 遊戲 引擎來說是一個機遇大於挑戰的時代。我們會以 遊戲 行業的建設為基礎，再拓展到其他領域中去。」這是 Cocos 的聯合創始人兼CTO林順在與我們的交流中告訴我們的，打破過往或許存在的單一印象和定位限制，是這個有著十年 歷史 的引擎團隊的下一步。

1、Cocos 的升級打怪之路

從2010年誕生至今，Cocos 基本上可以說是與整個移動 遊戲 市場的風潮同步發展的。從《夢幻西遊》到《亂世王者》，從《劍與遠征》到《最強蝸牛》，用 Cocos 引擎製作的產品一直沒有遠離市場最閃亮的鎂光燈之下，在中國手游市場40%的份額佔比和全球30 萬的月活躍開發者，是其一路以來打下的地基。

同時，對於一部分開發者來說，Cocos 在2D 遊戲 方面的廣泛應用也讓他們把Cocos 放進了某個固有印象的盒子當中——打破這個盒子，也是 Cocos 今年所努力在做的。

在今年年初，Cocos 發布了Creator 3.0版本， 這個版本融合了幾乎所有 Creator 2.x 與 Creator 3D 1.x 版本的功能，將此前2D和3D兩套產品進行合併， 是 Cocos 為開發者提供兼具輕量與重度 遊戲 的開發體驗、往更引擎一體化建設方向的開始。

到了5月份，Creator 3.1正式亮相，該版本包含了華為HMS CG Kit團隊貢獻的延遲渲染管線，以及PhysX 物理後端的支持，意味著光照計算能力和物體運動邏輯都更加逼真寫實， 這對於 Cocos 來說是邁向3D旅途的新起點，標誌著Creator引擎的計算能力踏上一個新台階。

v3.4 的延遲管線 FrameGraph

緊接著6月，隨著華為 鴻蒙系統的發布Cocos也迅速升級到Creator 3.2版本，讓開發者搭配HarmonyOS的多設備協同能力， 成為全球首家支持 HarmonyOS 的 遊戲 引擎。

華為鴻蒙多設備協同

到了8月份，Creator3.3版本在2D和3D同時發力，在2D小 遊戲 平台啟動性能直接提升了60%，促進了小 遊戲 產品的買量轉化；3D方面完善了物理系統，加強了陰影效果。 這在整體上為 Cocos 在接下來的年度收官版本做了紮實的鋪墊。

前段時間，Cocos 終於扯下Creator 3.4版本的神秘面紗，在這個研發和測試周期都是全年中最長的版本中，Cocos 大量優化了內容生產體驗和效率，其中包括新增的動畫狀態機、光照模型和渲染表現優化、底層的前向和延遲渲染管線也基於FrameGraph和 subpass 進行了重構。 對自身 3D 技術進行了大幅的加強和優化，是 Cocos 引擎發展中里程碑的一步。

以下視頻來源於 COCOS，時長 01:27

3.4版本中最搶眼的新功能要數動畫系統Marionette（意為提線木偶）的添加，通過對狀態機、狀態切換、子狀態機、動畫混合 等角色動畫必要功能的支持，讓動畫師可以更加方便定義動作順序，而不必關心底層代碼的實現。這從核心上增強了開發者在 遊戲 中通過角色敘事的能力。

回顧 Cocos 的這一年，其 在2D應用領域立足腳跟、持續優化的同時，在3D方面的自身突破和長足進步是給到開發者最大的驚喜。作為一款全球性的引擎，二維和三維皆應是主場，對於依然在升級打怪的 Cocos 來說，2021無疑是充滿了里程碑和成就解鎖的一年。

晝轉夜動畫演示

2、不止 遊戲 ，坐穩出發數字內容世界的新列車

但對於 Cocos 來說，在 遊戲 引擎方面的進步只不過是他們今年升級的一部分。如果你仔細觀察，就會發現除了 遊戲 外，這家有著10年 歷史 的數字互動內容開發平台在其他領域的布局也已逐漸成型。

談到近兩年來 遊戲 行業相關的熱門議題，哪幾個關鍵詞會排在隊列首位？工業化、多平台、雲 遊戲 、元宇宙……這些攪動市場新浪潮的風向標都有著共同的特點：預示著萬物互聯成為不可避免的趨勢，以及 對數字內容的開發提出極高的要求。

數字內容的生產從來都離不開技術，而在新形態內容發展的初期，技術更是能起到奠基和領導的作用。在上世紀90年代初期，id Software就通過自己的技術力開啟了3D 遊戲 的革命時代：其在1992年的作品《德軍總部3D》成為第一款有3D FPS 遊戲 ，而引擎改良後在次年推出的《毀滅戰士》更是以其 革命性的3D效果衝擊了整個 遊戲 工業的發展進程。

其之後的《雷神之錘》所使用的Quake引擎，則是當時第一款完全支持多邊形模型、動畫和粒子特效的引擎的3D引擎，這直接催生了整個行業3D 遊戲 技術和FPS這個 遊戲 類型的急速發展。id Software還通過將引擎面向市場商用， 直接催生了現代「 遊戲 引擎」的概念， 大名鼎鼎的《半條命》和《反恐精英》系列都是使用了該引擎所製作的作品。

雷神之錘（1996）

不難看出， 在工業發展的關鍵節點技術不僅是驅動創新內容生產的基石，更是解放創作者的未知想像力的鑰匙。 而當下即將到來的萬物互聯時代，就正如當年從2D躍進3D，同樣是行業的一個新起點。

Cocos 的聯合創始人林順告訴我們，「數字內容的發展對於立體畫面表現力和交互的形態要求都很高， 遊戲 引擎在這製作這方面內容是天然的、最適合的工具， 行業的發展趨勢對於引擎來說是一個非常巨大的機遇。 」

正如他所說的，Cocos 引擎憑藉其高性能、小包體、可熱更的特點，已經廣泛「入侵」各種應用場景。

在教育場景下，Cocos 基於引擎能力推出面向教育行業的 Cocos ICE，作為一款無需編碼，即可快速上手的互動課件編輯器，同時因為強大的兼容性，其可定製化的特性更是能滿足大部分教育機構的需求，獲得多家教育領域龍頭企業青睞。

Cocos ICE

在VR 方面，Cocos 已經做好相關引擎能力的儲備，目前XR的項目可以通過Cocos 引擎以源碼的方式來開發，未來將會推出雙目渲染技術方向的插件，幫助開發者快速完成3D 遊戲 向VR版本的轉化。

Cocos 和華為 AR Engine 合作示例 遊戲 《AR 指尖戰爭》

在 IoT 方面，如今中國多數智能電視的互動界面都是基於 Cocos 開發，在智能手錶上也已經實現了虛擬偶像落地的場景；在 車機 方面，Cocos 也已經實現完美適配，在人與人、車與外界的不同場景上實現了功能互動。

這個互動性視頻不僅可以從劍俠情緣手游中作為副本進入，也可以在微信小 遊戲 上直接體驗，任意門的「入口」無處不在。

《劍俠情緣之忘憂酒館 – 不下線戀人》

林順表示：「圍繞著這些未來趨勢， 我們更多的還是做基礎的積累，讓我們的引擎能更好地去適應未來內容生產。 在工具鏈上我們可能會繼續完善，讓開發者在生產的時間、人力上的佔用降低成本，是我們今天正在做。」

在已經有著廣泛覆蓋率的 遊戲 和教育領域以外，Cocos 在其他領域也在造路修車，做好了擁抱數字內容世界新形態的準備。

3、在未來，屬於 Cocos 的位置

站在內容形態的下一站路口，引擎之間的競爭激烈程度絲毫不比內容製作間的競爭弱。面對這一點，林順表示在今天雖然引擎的競爭確實很激烈，但是不同的引擎擅長的領域還是有很大不同。

「我覺得對於 遊戲 引擎來講，大家未來共同發展的方向仍然是圍繞著如何去承接更多品類的數字內容的開發，如何去降低這些數字內容開發的門檻，去提供更加智能化的工具，讓開發者更加高效的生產這些內容，以及讓這些內容表現力上升到另外一個緯度。」他說道，「大方向一致的前提下，每個引擎廠商的布局不一樣的地方。 Cocos 還是會繼續發揮在2D 遊戲 、小 遊戲 和教育、IoT等方向既有優勢，同時在3D原生和其他方向不斷突破自己。 」

而當我們問到在下一個10年，Cocos 打算在整個國內行業中扮演一個怎樣的角色時，林順回答道：

「 Cocos 始終還是圍繞著以工具為平台來做的一個定位。無論是 遊戲 還是其他行業，我們會以工具為基礎來提供服務給所有的開發者，讓大家整個內容生產的效率得以提升。我們未來的規劃也會圍繞著這個目標所展開，同時不斷地去完善自己的工具鏈，讓行業的開發者有更好的體驗。 無論是今天還是未來，我們一直會是生態的建設者。 」

據悉 Cocos 引擎團隊將於12月23日晚19點半在B站開播，詳細解讀 v3.4 的重要更新，現場演示動畫系統 Marionette 的功能與使用方法，有興趣的讀者可搜索微信公眾號「 遊戲 陀螺」，找到文章點擊 [閱讀原文] 查看。

cocos creator 2.4.0 渲染流程詳解（七：ForwardRender）

全文共5000+字，分為8個章節，由本人歷時一周整理而來。由於篇幅問題，將本文分為8個章節分開發布。全文 （ 不 ） 詳細描述了cocoscreator 引擎的2.40版本中，web平台的js部分引擎的渲染流程。請將文章配合源碼一起食用！

由於我尚在學習引擎源碼中，文章可能有不正確的部分，所以我會不斷更新內容。如有錯誤或補充，請留言交流！

全部章節鏈接：

一： 渲染流程中用到的核心類

二 ： 渲染流程詳解

三： RenderFlow 的運行邏輯

四： Assembler 的作用

五： ModelBatcher 數據合批

六： 材質系統

七： ForwardRender

ForwardRender 繼承於 Base, 是與底層渲染最靠近的類型，當上面的流程處理完畢後，會在ForwardRender 的 render() 中處理當前場景的渲染狀態，材質,光照，通道，著色器，更新著色器的統一變數。並在 _draw() 中調用 device.draw()方法，進行繪製。

部分重要的繼承於 Base 的成員變數：

_device：根據運行平台對應的繪製圖形對象 gfx.Device 的實例，用於繪製圖形到屏幕，類型定義於 cocos2d\renderer\gfx\index.js。

_programLib ： 管理 shader 定義，獲取，檢查等相關的變數。類型定義於 cocos2d\renderer\core\program-lib.js。

_stage2fn：保存有不同渲染通道的名稱與其對應的不同渲染方法。ForwardRender 中設置有 shadowcast， opaque, transparent 三種渲染通道。

_viewPools：單個相機的描述數據類(View) 的對象池。一個View對應一個相機。

_drawItemsPools：渲染數據類的對象池，保存有每個渲染批次需要的model，effect 等數據。

_stageItemsPools：單個渲染通道需要渲染的數據的對象池，本質是對 _drawItemsPools 中的數據按照不同通道進行了分類。

ForwardRender 中定義的成員變數：

_lights：保存所有燈光數據。

_shadowLights：保存所有陰影燈光數據。

類名 ForwardRender 翻譯為前向渲染，泛指傳統上只有 Opaque 和 Transparent 兩個通道的渲染技術。cocos有三個渲染通道，渲染通道方法定義在 _stage2fn 中。

渲染管線具體詳解請參考unity官方文檔（對的，真要學cocos還得看unity的文檔）：

內置渲染管線中的渲染路徑

相關鏈接

cocoscreator 2.4.x版本 drawcall優化 第一期（掌握控制drawcall數量的必要知識）

1，測試環境

2，為何drawcall多會影響性能

3, 哪些組件支持渲染

4，影響drawcall的因素

5，一句話介紹如何減少drawcall

6，哪些渲染組件不會被渲染

7，減少drawcall的理論（放在第二期）

8，理論指導實踐，實踐印證理論，demo實操（放在第三期）

9，總結（放在第三期）

「測試環境」 :

1.Mac 系統

2.cocoscreator 2.4.x版本

「為何drawcall多會影響性能？」

Drawcall: 繪製調用，指cpu調用圖形繪製介面命令gpu進行圖形繪製

「每一次繪製前，CPU要準備繪製參數(狀態)比如色彩通道(color filter)，繪圖方式(shader)等複雜的數據處理，然後Drawcall,如果有大量drawcall，cpu會很「忙」,而gpu的處理能力很強，這時他可能閑置，不能充分發揮應有的能力，導致性能下降。」

「哪些組件支持渲染：」 因為一個drawcall是一次cpu調用圖形繪製介面命令 gpu進行圖形繪製渲染的過程，所以需要了解cocoscreator中哪些組件支持渲染，才能更好的控制drawcall

**

「影響drawcall的因素：」

1,層級(zindex)

2,材質(Material)（shander,貼圖（紋理），混合模式（blend））。只有擁有相同材質的渲染節點 才可能進行批處理，貼圖，shader 決定了材質，而層級則決定了相同的材質 是否能 進行合併處理 即合併網格（mesh） 合併drawcall.，

「一句話介紹如何減少drawcall：」 繪製狀態的變化 是導致drawcall增多的 主要原因。cocoscreator認為要以深度(zindex)優先的方式對渲染組件進行渲染，並且cocoscreator認為相同的材質可以被批量渲染。所以具有相同材質的並且連續的渲染節點 可以合併渲染 減少drawcall.

「連續：」

1,層級相同添加順序相鄰，

2,層級不同 中間層級沒有其他材質的渲染組件。比如 a的層級是1 b的層級是3 在 1-3層級之間沒有其他材質的 渲染組件.

「影響drawcall的因素:」

「1，渲染節點（zindex）層級」

zIndex是節點的層級是用來對節點進行排序的關鍵屬性，它決定一個節點 在兄弟節點之間的層級，和誰被優先渲染。

1） zIndex 的取值介於 cc.macro.M IN_ZINDEX 和 cc.macro.MAX_ZINDEX 之間

即 – math.pow(2,15). 和 math.pow(2,15)-1之間。

實際操作中一般是 -1 到 n n一般不會超過1000

2）父節點主要根據節點的 zIndex 和添加次序來排序，擁有更高 zIndex 的節點將被排在後面（後被渲染先被渲染的圖在後被渲染的圖下面)，如果兩個節點的 zIndex 一致，先添加的節點會穩定排在另一個節點之前。排在前面的節點先被渲染，也就是說兩張圖層級相同 先添加的會先被渲染 顯示出來的結果是 在後被渲染的圖的下面。

3）節點在 children 中的順序決定了其渲染順序。父節點永遠在所有子節點之前被渲染

4)node節點放在Canvas或者父節點的zindex默認值是0

5）決定節點層級的另一個因素是siblingIndex 他的權重低於 zIndex 當我們在編輯器上編輯借點的時候 兄弟節點之間的zIndex相同，為什麼會出現一個先被渲染一個後被渲染呢 ，就是因為 siblingIndex 不同，排在前面的siblingIndex要小一些後面的要大一些 最終後面的後選擇然 層級就在 前面的上邊。 也就是說 zindex 其決定性作用，zIndex相同 就比較siblingIndex來判定最終層級。

「2，材質」

1）紋理（貼圖）

2）shander：渲染器，能夠讀懂的點和顏色的對應關係的程序，簡單來說就是繪圖的方式)

只有擁有相同材質的物體才可以進行批處理。因此，如果你想要得到良好的批處理效果，你需要在程序中儘可能地復用材質和物體。

如果你的兩個材質僅僅是紋理不同，那麼你可以通過 紋理拼合 操作來將這兩張紋理拼合成一張大的紋理。一旦紋理拼合在一起，你就可以使用這個單一材質來替代之前的兩個材質了。

「哪些渲染組件不會被渲染」

cocoscreator 認為 透明度 === 0. 或者 active = false 的渲染組件 不會被渲染。

cocos creator視頻播放器載入太慢

可以優化首頁的載入速度。

開發組為了加快首頁的渲染速度，減少白屏時間，把邏輯代碼和首頁載入代碼做了徹底分離。首次頁面載入的只是一個相當於載入器的初始化文件，文件體積特別小，不像某些引擎，一開始就需要載入主邏輯js文件，一開始就給我來個上百kb的文件載入，然後才能顯示loading條，白屏時間當然會延長不少。

如何評價cocos creator，與unity比的優劣勢

你好，我做過UNITY也做過COCOS綜合來分析的話我覺得各有千秋。unity的優勢我覺得在於它開發的強大靈活度高而且所見即所得，這一點真的是很牛逼得。在編碼過程中可以實時查看所有Public變數改變反正就是很方便，而unity最大的問題個人覺得就是這個APK打包出來體積大的嚇人。。而相對於cocos就不太方便了，他的遊戲是基於一個個層或者一個個組建拼湊而成，寫起來的時候會需要有大量的東西去準備。但是這樣也有一個好處那就是只要構思好寫好所有的層級修改起來還算方便而且很多功能也是Unity無法實現的。其實他們各有各的好處看你喜歡那樣咯，unity現在傾向於3d遊戲這一塊和虛擬現實，而cocos終究還是2d遊戲的首選開發引擎。

Cocos Creator 最簡易例子，場景切換，節點掛載腳本

節點怎麼掛載腳本？

點選 層級管理器 中的任意 節點，查看 右側 屬性檢查器，拉到最下面，可以看到 添加組件 按鈕，點擊，選擇 用戶腳本組件，可以看到 當前所有的js腳本文件，選擇 想要 掛載 的腳本，完成 節點和腳本的 掛載。

資源管理器 中任何地方，滑鼠右鍵，新建–JavaScript。留意js文件放在統一的目錄下面，比如Script[目錄需要自行建立]

層級管理器 中任何地方，滑鼠右鍵，創建節點

SceneMain.js

Scene1.js

2.5.1 CanvasScene1節點【見文中20220317160146_1.png截圖】 首先掛載腳本Scene1.js

雙擊資源管理器中的 場景 Scene1【路徑Scene–Scene1】,層級管理器中，找到 CanvasScene1節點，點擊，查看右側 屬性檢查器，拉到最下面，點擊 添加組件 — 用戶腳本組件 — Scene1。完成掛載。

2.5.2 BtnGoToNextScene節點【按鈕類型】【見文中20220317160146_1.png截圖】 設置點擊響應函數

層級管理器中，找到 BtnGoToNextScene節點，點擊，查看右側 屬性檢查器，拉到最下面，

Click Events 中的值修改為1，表示有一個點擊事件響應。

最初第一個顯示框空著時，提示為 cc.Node ，表示，這個地方需要拖拽一個 節點類型。節點類型，在 層級管理器中，只有 CanvasScene1節點 掛載了腳本，而且掛載的腳本中，有我們需要的響應函數 onBtnGoToNextScene()。

這個時候，只能使用拖拽形式，把 層級管理器中的 CanvasScene1節點 拖拽到 這個 顯示框區域。完成之後，這個顯示框中，顯示的就是 CanvasScene1。

這一步做好之後，水平並列在後面的兩個下拉框就有選擇項了。一個選擇腳本，一個選擇響應函數。

–the end