《誅仙手游》小游戲：重度游戲在小游戲平臺下的探索與實踐

在 2025 年 5 月 24 日的 Unity User Group 北京站活動中，完美世界《誅仙手游》客戶端負責人劉彥麟帶來分享《重度游戲在小游戲平臺下的探索與實踐》。本文為演講全文實錄，點擊閱讀原文，可下載演講 PPT 資料。演講視頻可通過下方鏈接地址觀看。

https://www.bilibili.com/video/BV1rzj9zVEGd/?spm_id_from=333.788.videopod.sections&vd_source=6ad5666ecbc7fe0e80d963da7e237d92

我來自完美世界《誅仙手游》項目組。本次分享的內(nèi)容聚焦于完美世界小游戲開發(fā)的經(jīng)驗，特別是小游戲下 WASM 和堆內(nèi)存的優(yōu)化方案，以及團結(jié)引擎對于小游戲的技術(shù)支持。

我們的小游戲移植工作啟動于 2023 年中旬。然而，早在幾年前，嘗試小游戲的想法就已經(jīng)萌生，并且進行過技術(shù)嘗試。這其中包括對 Unity 和其他 H5 引擎的探索，但由于未能達到預期的綜合目標，這些嘗試最終未能繼續(xù)推進。

隨著 2022 年和 2023 年小游戲市場快速發(fā)展，以及大量“爆款”涌現(xiàn)，其中不乏 MMO（大型多人在線）、SLG 等中重度游戲也表現(xiàn)出色。無論從產(chǎn)品、運營，還是從技術(shù)角度來看，都促使我們決定再次嘗試小游戲平臺。

經(jīng)過約半年的調(diào)研和分析，發(fā)現(xiàn)無論是市場前景還是技術(shù)承載能力來看，都存在機會。因此，我們在 2023 年 6 月正式啟動小游戲的項目。經(jīng)過約半年時間的移植工作和產(chǎn)品調(diào)優(yōu)，項目從 2024 年的 1 月開始對外進行多輪 CCB 測試，今年 1 月，在微信小游戲平臺開啟正式 OB。目前，開發(fā)團隊也正在進行抖音平臺的性能調(diào)優(yōu)，后續(xù)還會發(fā)行到更多小游戲平臺。

MMO 類游戲因其固有的特性，即使在硬件資源豐富的端游或手游平臺上，如果技術(shù)方案欠妥，亦可能產(chǎn)生相當大的性能問題。這因為此類游戲需要更大內(nèi)存，更大的計算承壓（包括 CPU 與 GPU），且部分功能需要多線程支持，而這些問題在小游戲平臺上將進一步放大。這其中，內(nèi)存和 CPU 是相對關(guān)鍵的要素，亦是攻克小游戲平臺性能瓶頸的關(guān)鍵點。

在小游戲平臺上，iOS 設(shè)備的內(nèi)存普遍限制在 1.4G。然而，在手游平臺上，1.4G 僅是部分低端機型的內(nèi)存閾值，且此類機型在 APP 平臺上的占比極小。此外，小游戲平臺的 CPU 性能大約僅為手游的 1/3，并且不支持多線程，這使得小游戲平臺對密集性運算更為敏感。然而，重度游戲恰恰需要大量計算，以及運行時的內(nèi)存支持。同時，Unity 中的許多功能也依賴多線程支持，例如動畫、蒙皮、粒子系統(tǒng)和物理系統(tǒng)。一些功能甚至會借助 Job System 來加速計算。然而，在小游戲平臺上，這些功能都會轉(zhuǎn)為主線程上的線性計算，不僅無法利用多線程優(yōu)勢，還會搶占主線程資源，進一步加重運算壓力。

小游戲內(nèi)存主要分為幾個方面，其中影響最大是 UnityHeap、WASM 以及 GPU 顯存，這三者是移植后造成小游戲平臺內(nèi)存暴增的主要因素，只要妥善處理這三方面，整體內(nèi)存使用基本就能達標。

WebAssembly性能優(yōu)化與內(nèi)存挑戰(zhàn)

WebAssembly 并非旨在替代 JavaScript（JS），而是通過擴展 Web 的能力提升其性能上限，從而更好地支持 3D 游戲、vr/ar 圖像/視頻編輯等類似的需要高性能計算要求的任務(wù)，其主要作用在于彌補 JS 在算力方面的不足。JS 作為解釋性語言，運行效率相對較低；而 WASM 則是編譯型的字節(jié)碼，性能更接近原生。

在一篇關(guān)于 WASM 與 JS 能耗對比的論文中，對比了在安卓平臺下，不同的手機瀏覽器中 WASM 與 JS 的能耗表現(xiàn)，可以清楚地看到，JS 的能耗遠遠大于 WASM，最大能耗差異接近三倍。這意味著將 WebAssembly 用于 Web 應(yīng)用能顯著降低對移動設(shè)備的能耗，最直接的影響就是降低發(fā)熱。

盡管 WASM 的性能接近原生，但兩者之間仍存在一定差距。下面這篇論文對多種 WASM 獨立運行時的程序進行了表征性研究，并從內(nèi)存、機器指令、緩存命中等方面與原生程序進行了性能對比。最終的結(jié)論就是在獨立運行時下，wasm 就會比原生程序降低 1.5～9.5 倍的性能。以上兩篇論文發(fā)表于 2022 年，具有很高的參考價值。

WASM 調(diào)用 WebGL API 時，同樣也需要遵守瀏覽器的安全模型和策略。 WebGL 中每次調(diào)用 API 都會伴隨著一定開銷，這主要是由于安全驗證所引入的。 在重度游戲中，WebGL API 調(diào)用極為頻繁，這意味著在 Web 平臺下，狀態(tài)切換的代價會更高。 因此，有必要盡可能減少 SetPass 調(diào)用以及與 WebAPI 的交互。

WASM 雖然解決了 JavaScript 在高性能計算的問題，但也帶來了內(nèi)存挑戰(zhàn)。 在小游戲中，編譯后的 C++ 代碼會再次通過 emscripten 編譯成 WASM。 在運行時，WASM 代碼會被再次編譯并實例化，而編譯+實例化的過程將會產(chǎn)生近 10 倍 wasm 文件大小的內(nèi)存占用。

例如，在誅仙第一個 Chrome 版本中，WASM 文件大小為 90M，這意味著在運行時產(chǎn)生了 900M 的內(nèi)存。 鑒于 iOS 小游戲內(nèi)存限制為 1.4GB，WASM 占據(jù)了 900MB，僅剩 500MB 可用空間，這對于 MMO 游戲而言是遠遠不夠的。 這部分內(nèi)存的實際最終大小與平臺、內(nèi)核版本也有關(guān)系。 我們在不同的手機及不同瀏覽器上進行過詳細測試，結(jié)果顯示，盡管內(nèi)存大小存在一定浮動，但最終結(jié)論都接近于 10 倍。 因此，對 WASM 進行縮減是必要的。

WASM 是代碼編譯的結(jié)果，因此，縮減 WASM 的本質(zhì)就是縮減代碼的使用。 Unity 項目的代碼主要由引擎代碼、package、第三方庫，以及游戲邏輯代碼組成。 可以通過 Player settings 對引擎代碼和托管代碼進行剔除，但這種剔除并不徹底，部分代碼可能被引擎誤判為已使用，或因錯誤操作產(chǎn)生引用，此時便需要進行手動剝離。 其中，最常見的就是 package 和第三方庫，特別是對于僅在 editor 下使用的代碼庫，要正確設(shè)置其程序集平臺，保證其只在 editor 環(huán)境下使用。

除此之外，還有一些需要注意的方面。例如命名空間，小游戲中無法使用多線程，盡管使用多線程的代碼編譯無誤且運行結(jié)果正確，但最終還會以單線程方式執(zhí)行，這會導致性能差異。因此，需要剔除線程類的命名空間。

對于 Job、Task 等與線程相關(guān)的，由于無法發(fā)揮其多線程優(yōu)勢，也應(yīng)該直接代碼中剔除，并相應(yīng)的將功能改為單線程實現(xiàn)，同時基于單線程優(yōu)化代碼算法。

另外，關(guān)于共享庫的使用，例如 json，在微信和抖音小游戲 SDK 當中都包含一份 json，而一些第三方庫或 package 也可能包含或引用一份 json。對于此類問題，需要進行手動修改，確保項目存在一份 json。

關(guān)于代碼設(shè)計模式，優(yōu)秀的設(shè)計模式固然能提高項目的可擴展性和可維護性，但是過度設(shè)計則會影響開發(fā)效率，尤其在小游戲環(huán)境中，過度的設(shè)計模式會使 WASM 變得更加臃腫。

WASM 作為相對低級的編譯目標，不支持泛型或模板等高級語言特性，生成的 wasm 代碼是針對具體類型的具體實現(xiàn)。雖然在編譯時，可以設(shè)置編譯參數(shù)，進行編譯優(yōu)化，但對于過度復雜的設(shè)計模式，編譯優(yōu)化也無能為力。

舉例來說，將屬性寫為訪問器形式，編譯后會額外產(chǎn)生 2 個函數(shù)。 此外，foreach 循環(huán)還會額外產(chǎn)生包含 try-catch 的語句，這些都會增大 WASM 的體積。

除編譯問題，代碼方面還有許多值得注意的地方。比如，對于 string，運行中產(chǎn)生的并且頻繁使用的 string，最好使用 intern 把它強制放到常量池。能使用常量就使用常量，比如 vector.one，沒必要再 new vector(0,0,0)。類似的問題還有很多。因此，需開發(fā)人員更加了解 IL2CPP，和 WASM 的機制，以便編寫出更高質(zhì)量的代碼。

再說回到編譯的問題，編譯時可以導出一張符號表，如右上這張圖 symbols.json 就是導出的明文符號表，左下就是該符號表的內(nèi)容。利用這張符號表就可以對其文件進行解析，從而統(tǒng)計代碼中每個類的占比。圖右下，顯示了對符號表處理的結(jié)果，例如 uilabel 約占整個 WASM 的 0.1%。開發(fā)團隊會根據(jù)解析結(jié)果，從占比最高的類入手，逐步進行分析和優(yōu)化，進而實現(xiàn)代碼的剝離。圖右下的是我們最開始生成的 wasm 分析文本。

目前，此功能在團結(jié)下已經(jīng)得到了非常大的改進，能夠可視化查看和對比兩版本的差別，極大地提高了研發(fā)效率。

經(jīng)過上述處理，WASM 文件已從最初的 90MB 精簡至目前的 51MB，相當于節(jié)省了 400MB 的內(nèi)存空間。

從圖右側(cè)可以看出，前述的每一步 WASM 精簡方法，都對 WASM 內(nèi)存產(chǎn)生了顯著的影響，然而，目前仍有 500 兆的 WASM 編譯內(nèi)存，這仍然是一個相當大的數(shù)值。

即使通過代碼剔除，在游戲的實際運行中，仍會存在一部分使用不到的函數(shù)。 事實上，每個小游戲平臺目前都提供了代碼分包的能力，可以將運行時使用的函數(shù)收集到主包，未收集到的函數(shù)劃分到子包。 主包中所包含的函數(shù)，才是整個游戲生命周期所使用的函數(shù)。 通常情況下，大部分游戲的主包代碼占比不會超過 50%，這意味著在最差的情況下，可以通過代碼分包將 WASM 的編譯內(nèi)存再次減半。

首次進行代碼分包是一個相對耗時的過程，需要進行充分的函數(shù)收集，以避免因收集不全導致函數(shù)被劃分到子包。頻繁地遠程拉取子包函數(shù)，會使游戲運行變得異?？D。以上便是我們針對 WASM 文件的所有優(yōu)化方法。

小游戲中的Unity堆內(nèi)存

小游戲中的堆內(nèi)存結(jié)構(gòu)與 APP 基本一致，兩者均通過貝母 GC 進行管理，但在細節(jié)上存在差異。

在 web 平臺，UnityHeap 被實現(xiàn)為一個連續(xù)的線性內(nèi)存空間數(shù)組，這部分內(nèi)存是通過瀏覽器分配的，并且在生命周期內(nèi)不會返還給瀏覽器。

在初始化階段，需要為 UnityHeap 設(shè)定并設(shè)置一個大小，即預留內(nèi)存。 當內(nèi)存不足的時候，系統(tǒng)會通過 CopyArray 的方式進行擴容，此過程會產(chǎn)生一個內(nèi)存峰值，極有可能導致內(nèi)存崩潰。 例如，若預留內(nèi)存設(shè)置為 600 兆，由于內(nèi)存對齊，實際可能匹配到 608 兆，當內(nèi)存不足進行擴容時，該幀的內(nèi)存峰值可能達到 1.4GB，此時極易發(fā)生崩潰。 多數(shù)中重度游戲崩潰的原因，都是未能設(shè)置合理的預留內(nèi)存，從而在內(nèi)存擴容時發(fā)生崩潰。

通常對于重度游戲，推薦的預留內(nèi)存值為 768 兆。 然而，并非必須嚴格遵循此值，只要確保內(nèi)存峰值不超過預留內(nèi)存即可，即使略大于 768MB 也無妨。 同理，如若游戲內(nèi)存峰值肯定達不到 768 兆，也可設(shè)置得更小，將內(nèi)存讓給其他空間，比如 js。 因此，設(shè)置預留內(nèi)存的目的是在合理的范圍內(nèi)使用內(nèi)存，避免觸發(fā)內(nèi)存擴容和內(nèi)存浪費。

托管內(nèi)存方面，與 APP 不同，托管堆（Managed Heap）來自于 Unity 堆，釋放后也只會返回給 Unity 堆，而不會返回給系統(tǒng)。 尤其在 Web 平臺下，托管堆具有只增不降的特性，這是一個顯著的差異。

托管堆不只一塊，會根據(jù)實際的內(nèi)存使用，在 Unity 堆中開辟多塊，那么就會產(chǎn)生托管堆的碎片。 盡管 Unity 沒有提供相關(guān)的設(shè)置或者相關(guān)的編譯參數(shù)，來提前預留托管內(nèi)存，微小抖小平臺也沒有提供相關(guān)的接口進行設(shè)置，但可以利用托管堆只增不降的機制，提前開辟一大塊托管堆內(nèi)存進行復用，以減小內(nèi)存碎片，提高內(nèi)存的整體使用率。 通過對比圖示可以看出，上圖未進行托管內(nèi)存預留時，內(nèi)存分布較為分散； 而下圖進行預留后，內(nèi)存碎片明顯減少，整體內(nèi)存消耗也隨之降低。

在內(nèi)存管理方面，GC（垃圾回收）在移動平臺和 Web 平臺也存在顯著差異。 移動平臺上，GC 在觸發(fā)后會立即執(zhí)行，而在 Web 平臺，GC 僅在兩個特定時機觸發(fā)： 每幀結(jié)束時會執(zhí)行少量 GC，以及切換場景時會執(zhí)行一次完整的 GC。 因此，在 Web 平臺的單場景尤其是單幀內(nèi)，對內(nèi)存的使用要注意以下幾個方面：

一是設(shè)置合理的預留內(nèi)存： 避免因為預留內(nèi)存不足而造成 Copyarray。

二是避免內(nèi)存碎片：特別針對托管內(nèi)存，可以提前申請合理的使用空間并善用對象池來有效預防。

三是避免幀內(nèi)內(nèi)存峰值：在移植過程中，曾出現(xiàn)過單幀內(nèi)加載多張配置文件導致托管內(nèi)存暴增的情況。對于 native 內(nèi)存的暴增，最常見的原因是對 AssetBundle 的加載。避免單幀內(nèi)存峰值的最佳方法是拆分數(shù)據(jù)，分幀加載。

尤其值得注意的是，強烈推薦使用小游戲平臺提供的 AssetBundle 接口，例如微信的 WXAssetBundle 和抖音的 TTAssetBundle。盡管早期項目曾嘗試不依賴小游戲平臺接口，但效果不佳。實踐證明，WXAssetBundle 或 TTAssetBundle 能真正利用文件系統(tǒng)，從而顯著減少內(nèi)存占用。

四是，避免不當使用像代理、匿名 lambda、閉包等，這些不規(guī)范的使用方式會頻繁產(chǎn)生堆內(nèi)存，進而造成內(nèi)存碎片，降低堆的利用率。

基于Unity的優(yōu)化策略

許多常用的 Unity 優(yōu)化方法在小游戲和手游上同樣適用，對于優(yōu)化來說，可以把小游戲視為對性能要求更為嚴苛的手游，以下是一些手游和小游戲開發(fā)中被驗證實用的優(yōu)化方法。

首先，針對 Unity 資源件，可根據(jù)項目的實際需求進行進一步精簡。 比如 anim，Unity 下，anim 可以針對不同文件，設(shè)置不同的誤差，采用不同的壓縮率。 但在相同的骨骼點下，它們所需的精度有所差異； 這意味著相同的誤差對于不同的骨骼點會產(chǎn)生不同的影響。

對于站立動作，其通常是新玩家進入游戲創(chuàng)角場景后看到的第一個動作。 較大的壓縮誤差會使腳步與地面產(chǎn)生較大的位移。 通過對比 error 1.0 和 0.5 的設(shè)置，可以觀察到模型腳步與地面之間存在顯著差異。 盡管有些項目為了給新玩家提供更好的體驗，會在創(chuàng)角場景采用獨立的資源以保證更優(yōu)質(zhì)的效果，但這會額外增加包體大小，并可能導致頻繁的下載。

在《誅仙》項目中，我們采用了程序化方法對動畫文件進行組合性壓縮，針對不同動作、不同肢體部位采用不同的壓縮誤差，以此實現(xiàn)效果與性能的平衡。可以看到經(jīng)過組合壓縮的站立動作，腿部與地面的相對位移幾乎很小。

具體來說，對于于站立動作，在腿部會采用更低的誤差以減少滑步現(xiàn)象，而其他部位則會采用高誤差低精度的方式進行處理，從而平衡整個動作文件的大小并保障局部動作效果。 經(jīng)過這種處理，動作文件在腿部組合壓縮后會擁有更多的采樣點，確保了腿部的精度。

同時，在不影響手臂效果的前提下，組合壓縮會盡可能減少手臂的采樣點，從而平衡了整體文件的內(nèi)存占用。

通過下圖可以看出，組合壓縮會更加擬合原始動作文件，而 Error 1.0 和 Error 0.5 的文件則與原始動作文件存在明顯的曲線偏差。

這種組合壓縮方法不僅能達到預期的效果，而且壓縮后的文件大小也非常理想，甚至在某些情況下會比 Error 1.0 的文件更小。

除了 AssetBundle，全局光照（GI）數(shù)據(jù)也是重度游戲，尤其是 MMO 類游戲消耗內(nèi)存的重要部分。在大場景中，目前通常通過光照貼圖（Lightmap）和光照探針（Light Probe）的方式實現(xiàn)效果。光照探針作為一種實現(xiàn) GI 的方式，相比 Lightmap，它更容易規(guī)避單幀內(nèi)申請過多內(nèi)存，也更便于實現(xiàn)離散的分幀加載，并且在制作 TOD 時更為便捷，顯著增加了靈活性。

然而，光照探針的靈活性也伴隨著內(nèi)存的問題。 一個 Lightmap 中的采樣點可視為一個 RGB 值（即 3 個 float），而 Unity 中的光照探針使用的是三階球諧函數(shù)（3rd order Spherical Harmonics），這需要 9 個系數(shù)，共計 27 個 float。 對于 GI 而言，采樣點越多，效果自然越好。 但是，過多的光照探針相比 Lightmap 內(nèi)存勢必也會翻倍。

鑒于球諧函數(shù)用作 GI 通常是低頻信號，其在空間中的變化是平滑且連續(xù)的，因此相鄰球諧函數(shù)的系數(shù)也極為相似?；谶@一特性，可以對場景中的探針進行基于特征空間的降維壓縮，從而有效優(yōu)化內(nèi)存占用。

在二維空間中，可以通過找到一個特征軸來表達平面內(nèi)點的特征。同理，在三維空間中，也可以通過多個特征軸來表達三維空間的特征。因此，可以提取所有球諧函數(shù)的特征數(shù)據(jù)，并將其映射到特征空間，再根據(jù)前 n 個特征來重構(gòu)原始數(shù)據(jù)，從而實現(xiàn)高保真度的壓縮與還原。

從上圖右側(cè)可以看出，在不同特征數(shù)量下所表達的平面結(jié)果：特征數(shù)越多，越接近原始效果。在三維空間中，對于光照探針、環(huán)境光遮蔽（AO）等具有方向性的數(shù)據(jù)，均可通過這種方法進行降維壓縮。

上圖左側(cè)的圖像展示了三階球諧函數(shù)的原始效果。中間的四幅圖是經(jīng)過降維并還原后的結(jié)果，其中特征是疊加的。當特征數(shù)量為一時，它表達的是最主要的特征。隨著特征數(shù)的增加，細節(jié)也隨之增多。在中間的四張圖中也可以觀察到，隨著特征數(shù)量的增加，綠色部分變得更加明顯。當特征數(shù)達到 13 時，整體效果與原始球諧采樣幾乎一致。

當然，也可以直接使用二階球諧函數(shù)，但它會產(chǎn)生明顯的差異。從上圖左側(cè)的兩張圖可以看出，盡管二階球諧函數(shù)的色調(diào)與三階一致，但在明度上存在較大差異，并且這種差異會隨著建筑結(jié)構(gòu)、光源等空間復雜度的增加而愈發(fā)明顯。但是當特征 =13 的時候， 與三階球諧相比，無論從色調(diào)還是明度，幾乎感受不出差距。

利用特征空間進行降維的目的不僅是為了實現(xiàn)高還原度，更在于其在內(nèi)存方面具備顯著優(yōu)勢。

通過左上的兩個公式可以更直觀地看出，在大量探針的應(yīng)用場景下，基于特征空間的降維顯著降低了球諧階數(shù)對內(nèi)存的影響。具體而言，三階球諧函數(shù)每增加一個探針將穩(wěn)定增加 108 字節(jié)。而基于特征空間的壓縮方法，每次增加的字節(jié)數(shù)是特征數(shù)乘以 4。當特征數(shù)等于 13 時，每個探針僅增加 52 字節(jié)。并且此時幾乎可以還原原始探針的全部效果。

鑒于球諧函數(shù)主要用于表達 GI 的低頻信號，在實際應(yīng)用中可以適度縮小特征數(shù)。這樣做既能有效減少內(nèi)存占用，又能確保 GI 效果的質(zhì)量。

以上闡述了針對數(shù)據(jù)壓縮的方法。如前所述，小游戲?qū)?Draw Call 和 SetPass 更為敏感。在保證效果的前提下，LOD 是降低 Draw Call 和面數(shù)的最佳方法。

LOD 的優(yōu)勢在于可以通過全局劃分顯著減少 Draw Call 和面數(shù)。但值得注意的是，單場景、單幀內(nèi)對內(nèi)存的申請也會隨之增大。

我們重寫了 LODGroup 組件，在切換不同物體的同時，能夠使其以流式的方法逐步加載卸載對應(yīng)的資源，這意味著僅加載當前可見的資源，而非一次性加載所有資源。這種做法能夠平衡 LOD 帶來的內(nèi)存增加，有效管理和利用模型資源，從而達到平衡內(nèi)存、Draw Call 和面數(shù)的目的。

值得注意的是，由于 web 環(huán)境下不支持多線程，所以 Unity 自帶的的流式紋理也是無法正常工作。所有資源的流式加載都需要手動重新實現(xiàn)。

除了實體，我們也對粒子做 LOD。 如上圖，隨著 LOD 等級變化，部分粒子發(fā)射器會被直接剔除，而另一些粒子并不會被剔除，但其粒子的產(chǎn)生速率與生命周期會明顯的縮短。 這種優(yōu)化方式在團戰(zhàn)等特效密集的的場景中效果明顯，能在保證整體視覺效果的同時，進一步降低粒子消耗，優(yōu)化場景性能。

對于草地特效這類同質(zhì)物體群落，使用 LODGroup 無法達到理想效果。LODGroup 主要表達的是單個物體隨距離遠近的變化，而植被群落則表達為一個面。因此，我們通過 CullingGroup 的方式，基于距離實現(xiàn)不同密度的實例化繪制。使用 CullingGroup 的主要目的是彌補實例化合批無法被剔除的問題。后面我也會介紹一種在團結(jié)引擎下能夠進行剔除的實例化合批的方法。

對于大型場景，還可以根據(jù)地塊和距離調(diào)整特征數(shù)，讓不同的地塊使用不同的特征數(shù)，可以進一步降低探針內(nèi)存。比如近處使用 13 特征的 GI，盡可能還原效果，而中距離、遠距離逐步降低特征數(shù)，減少內(nèi)存消耗。

團結(jié)引擎支持下的優(yōu)化與實踐

團結(jié)引擎對小游戲的支持是開發(fā)團隊當前正在利用的重要引擎功能之一。借助團結(jié)引擎，我們能夠進一步降低內(nèi)存消耗。在將項目從 Unity 切換至團結(jié)引擎后，開發(fā)團隊在所有配置（包括 projectsetting，playersetting 等引擎層面的參數(shù)設(shè)置）均保持相同的前提下進行了內(nèi)存對比。結(jié)果顯示，直接使用團結(jié)引擎能夠為項目額外節(jié)省約 60 兆的內(nèi)存，這一優(yōu)化效果非?？捎^。

在團結(jié)引擎中，托管代碼精簡新增了“extreme”模式。相較于“high”模式，“extreme”模式在代碼剔除方面更為激進。對于 MonoBehaviour 和 ScriptableObject，該模式僅保留項目中實際使用的類及函數(shù)。在我們的項目中啟用此選項，能夠?qū)⒆罱K的 WASM 文件大小進一步縮小約 10 兆字節(jié)，這相應(yīng)地意味著可以節(jié)省約 100 兆字節(jié)的內(nèi)存。

Unity 中 Skinned Mesh Renderer 是一個性能消耗較高的組件，但在 MMO 類游戲中又必不可少。小游戲平臺 CPU 性能大約只有 APP 的三分之一，因此需要盡可能減輕 CPU 的壓力。為應(yīng)對此挑戰(zhàn)，我們將場景中可進行合批的角色通過“Instancing + VAT”的方式進行繪制，取得了較為理想的效果。

在驍龍 660 設(shè)備上，開發(fā)團隊分別使用 GPU 和 CPU 兩種方法為 140 個角色進行隨機動畫播放測試。結(jié)果顯示，完全依賴 CPU 播放的幀率僅能達到 21 幀，而采用 GPU 播放動畫則能穩(wěn)定保持在 30 幀。

在 2023 年中旬開始小游戲移植時，缺少團結(jié)引擎和 gpu skinning，因此 VAT（vertex animation texture）是一個相對性價比很高的解決方案。 目前，團結(jié)引擎已經(jīng)能夠通過 GPU skinning 在 GPU 端實現(xiàn)蒙皮計算，同樣可以減輕 CPU 壓力，并達到理想的性能標準。 因此，我們已經(jīng)用 GPU skinning 替代了原有的 VAT 方案，也節(jié)省了額外的工作量。

從上圖中可以看出，在 108 個角色同屏的情況下，通過 GPU skinning 能夠穩(wěn)定達到 30 幀。而在相同場景下，使用 CPU skinning 的幀率只能維持在 10 幀以下。

WASM 調(diào)用 WebGL API 需遵循瀏覽器的安全模型和策略，每次調(diào)用 API 都會產(chǎn)生一定的開銷。這部分對開發(fā)者來說是黑盒的，我們唯一的辦法就是降低 dc 和 setpass，也就是降低游戲的復雜度。

在團結(jié)引擎下，可以對 Shader 進行優(yōu)化，包括直接通過引擎層面減少對 WebGL API 的調(diào)用。這種方法對于某些低系統(tǒng)設(shè)備效果非常顯著。我們在 iOS 16.4 系統(tǒng)上進行了不限幀測試，包括野外團戰(zhàn)和副本。開啟上圖所示選項后，幀率能夠提升大約 8 到 10 幀。

在合批方面，SRP Batcher 能夠通過排序，將使用相同 Shader 的物體放到一起去繪制，從而使每個批次僅調(diào)用一次 ApplyShaderPass，減少了重復設(shè)置 Shader 的時間消耗。

目前，項目主要采用的合批方式仍是 SRP Batcher。運行時相比 StaticBatch 會有一定的消耗，因為引擎每幀會根據(jù)可見的 renderers 生成 render nodes。然而經(jīng)過大量測試發(fā)現(xiàn)，在我們項目中，SRP Batcher 和 static batch 對于幀率的影響是相近的。鑒于靜態(tài)合批會額外增加內(nèi)存或包體大小，因此我們?nèi)詫?SRP Batcher 作為主要的合批方式。

后續(xù)團結(jié)引擎將推出一種更高效的合批方式，即 GPU Resident Drawer。目前團隊正配合團結(jié)的同學進行性能測試。理論上 GPU Resident Drawer 的執(zhí)行效率將高于 SRP Batcher，主要通過 BRG（Batch Renderer Group）進一步提高渲染效率，并且根據(jù)小游戲的特性，在單線程上做了特定的優(yōu)化。只要場景中的物體是靜態(tài)的，它的 buffer 就不需要更新，會長期駐留在 GPU 上。因此，與 SRP Batcher 相比，GPU Resident Drawer 在運行時也能減少一定的計算消耗。

GPU Resident Drawer 的主要目的是對于復雜場景的優(yōu)化，尤其適用于場景中存在大量可以實例化合批的分散物體的情況。如果直接使用實例化進行合批，由于缺乏剔除，反而可能導致負優(yōu)化。同樣，若在 CPU 端自己實現(xiàn)剔除后再調(diào)用 Graphic DrawInstance 進行繪制，也會加重 CPU 端的計算壓力，同樣可能造成負優(yōu)化。

而 GPU Resident Drawer 的一個重要特性就是解決了剔除問題。上方的表格是主城的測試結(jié)果，在 Drawcall、Setpass 以及功耗方面都有了非常明顯的降低。

以上就是我今天的分享 謝謝大家。

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發(fā)技能

每一個“點贊”、“在看”，都是我們前進的動力