在 2025 年 5 月 24 日的 Unity User Group 北京站活動(dòng)中，殼木游戲的 CTO 鄺圣凱帶來《團(tuán)結(jié)引擎的 H5 項(xiàng)目優(yōu)化實(shí)踐分享》。本文為演講全文實(shí)錄，點(diǎn)擊閱讀原文，可下載演講 PPT 資料。

點(diǎn)擊圖片，觀看演講視頻

感謝大家，我們作為團(tuán)結(jié)引擎的用戶方，今天也很榮幸得到 UUG 的邀請(qǐng)，介紹我們通過團(tuán)結(jié)引擎做一個(gè)手游項(xiàng)目時(shí)向 H5 遷移實(shí)踐方面的經(jīng)驗(yàn)。

游戲介紹

今天分享一些研發(fā)當(dāng)中的優(yōu)化細(xì)節(jié)和最佳實(shí)踐。先介紹一下我們的游戲《Dreamland（DL）》，它是 SLG 題材游戲，它的主城家園有類《饑荒》的外圍包裝，后面再引導(dǎo)進(jìn)入大世界地圖。

先介紹一下主要場景，游戲當(dāng)時(shí)立項(xiàng)面向手游，目標(biāo)是在 Native APP 里面榨干手機(jī)所有的性能，還引入了光影系統(tǒng)。 雖然是 2D 游戲，但規(guī)模是比較大的，從下方視頻可看出 算是一個(gè)重 CPU 規(guī)格的手游。

我們的大地圖戰(zhàn)斗規(guī)模還是比較大的，支持英雄的種類、Spine 體量比較大，戰(zhàn)斗達(dá)到 200vs200 同屏最高規(guī)格，英雄 Spine 50vs50，每個(gè)英雄帶 3 個(gè)小兵 UV 動(dòng)畫 150vs150。

下方視頻中展示了比較極端的戰(zhàn)斗場景。我們當(dāng)時(shí)決定把這個(gè)游戲遷移到 H5 版本時(shí)也做了比較久的權(quán)衡，進(jìn)行了不少可行性分析。

挑戰(zhàn)和痛點(diǎn)

總體痛點(diǎn)如下：

第一是進(jìn)游時(shí)間，對(duì)于 Native APP 用戶可以到 App Store 下載，然后進(jìn)行游戲，游戲大部分前期資源都是已經(jīng)準(zhǔn)備完成的，不存在 H5 進(jìn)游的時(shí)候零占用開始準(zhǔn)備加載的過程。

第二個(gè)突出問題是內(nèi)存問題。這個(gè)游戲面向 Native APP 設(shè)計(jì)，內(nèi)存是比較超標(biāo)的，到 H5 方面，比如做微信小游戲，可用的空間只有 1 點(diǎn)幾 G。這個(gè)游戲在 Native 版內(nèi)存峰值可以達(dá)到 1.8G 接近 2G，在一些比較老的 iOS 設(shè)備上就會(huì)崩掉。

第三是功能響應(yīng)速度，H5 算力并不差，但有些資源是后置加載，一些前期功能用戶在用到的時(shí)候可能資源還沒有下載完，如果安排不好就有加載響應(yīng)的問題。

最后是幀率問題。H5 雖然 GPU 沒有太多折損，但 CPU 能力大概是 Native APP 的三分之一，包括多線程不能被支持，這是比較不利的地方。

介紹一下宏觀思路。解決內(nèi)存問題一個(gè)比較重要的是通過微信代碼的分包機(jī)制，再就是開啟團(tuán)結(jié)引擎設(shè)計(jì)的高性能+的模式，以及 Spine 優(yōu)化、游戲業(yè)務(wù)相關(guān)的優(yōu)化，后面會(huì)詳細(xì)介紹。

OOM 問題解決之后，運(yùn)行期方面我們主要重點(diǎn)是在 Spine 性能優(yōu)化上。包括 Spine 拆面主要解決內(nèi)存問題，運(yùn)行時(shí)的效率問題也能夠得益。我們根據(jù)機(jī)型限制 Spine 動(dòng)畫的 Update 頻次，根據(jù)兵種大小降到 15fps、20fps，在有些比較小的角色上是看不出來的，對(duì) CPU 是很大的節(jié)省。還有 2D 管線優(yōu)化。預(yù)加載預(yù)實(shí)例會(huì)用到異步的實(shí)例化。再就是特效裁剪、相機(jī) SkipCulling 等等。

為什么選擇使用團(tuán)結(jié)引擎？我們立項(xiàng)的時(shí)候做 Native APP 使用的是 Unity。轉(zhuǎn)團(tuán)結(jié)引擎是因?yàn)閳F(tuán)結(jié)專門對(duì) H5 做了大量的優(yōu)化，包括剛才說的進(jìn)游時(shí)間、內(nèi)存優(yōu)化、WebAssembly 內(nèi)存峰值等當(dāng)時(shí)使用 Unity 不可逾越的問題。我們等了大概半年時(shí)間，團(tuán)結(jié)引擎 1.0 release 之后馬上跟進(jìn)，確實(shí)能夠達(dá)到很好的效果。如果大家計(jì)劃做 H5，建議使用團(tuán)結(jié)引擎。

下面分幾個(gè)方面展開：資源、管線、啟動(dòng)、運(yùn)行時(shí)優(yōu)化、上線前部署。

資源管理

資源管理，分幾個(gè)角度展開：

首先是顆粒度的問題。APP 版打 Bundle 是好幾個(gè)資源放在一起，但 H5 版資源是按需下載，用到 A 的時(shí)候才下載 A，前期沒有辦法把所有的資源都下下來。如果下載的 A 資源處在比較大的 Bundle 中，會(huì)占用比較長的下載時(shí)間。所以我們把資源切到一個(gè)非常細(xì)粒度的層次，確保每個(gè) Bundle 非常小，缺點(diǎn)是要下載 Bundle 的數(shù)量更多。不過 HTML 連接是復(fù)用的，實(shí)踐中比合并打 Bundle 的策略要好，做 H5 項(xiàng)目的時(shí)候可以考慮嘗試，Bundle 的粒度盡量控制得比較小。

第二，我們做微信小游戲用的是 WXAssetBundle，相對(duì)于 Unity Bundle 會(huì)做一個(gè)基于磁盤的局部檢索，加載里面某一個(gè)資源的時(shí)候只會(huì)讀取中間某一段資源的數(shù)據(jù)，而不是把整個(gè) Bundle 放到內(nèi)存里面去做讀取，對(duì)內(nèi)存的占用比較有好處，也是微信小游戲、抖音小游戲官方推薦的機(jī)制。

資源壓縮也是老生常談了，關(guān)閉 Read/Write, Generator Mipmaps 選項(xiàng)，使用特定的壓縮規(guī)格。

具體的資源管理使用的是 AssetGraph 對(duì)每個(gè)資源進(jìn)行壓縮規(guī)格的管理。

使用 SpriteAtlas 變體。因?yàn)槲覀円贿呍陂_發(fā) Native APP，一邊做 H5 版本，兩條線并行，所以 H5 方面我們對(duì)某些圖集做一些 Scale 壓縮，通過修改 AtlasVariant Scale 來實(shí)現(xiàn) H5 的更加輕量化，同時(shí)保持跟 Native APP 相對(duì)穩(wěn)定的鏈接。

再就是 Secondary Texture，有些 sprite 設(shè)置或使用了一些第二貼圖，但第二貼圖有時(shí)候是不必要的，這也是一個(gè)檢查點(diǎn)。

資源下載方面，之前已經(jīng)講過推薦使用 WXAssetBundle。

卸載的時(shí)候需要特別注意，之前的 Bundle 在卸載時(shí)一般會(huì)基于引擎做一些輔助管理，做一些半自動(dòng)的回收。比如保守的策略，在資源有可能在被占用的時(shí)候引擎就不會(huì)真正的卸載。但是到 H5 這樣對(duì)內(nèi)存要求比較嚴(yán)苛的平臺(tái)，我們建議完全強(qiáng)制管理資源卸載，使用強(qiáng)制卸載的選項(xiàng)。缺點(diǎn)是某一處引用可能還在，沒有注意到，可能卸載之后游戲產(chǎn)生錯(cuò)誤。建議讓這個(gè)階段在測試期盡可能暴露出來，并且修復(fù)，以此來換取比較干凈的或者更加受控的內(nèi)存管理，這是策略上的選擇。

URP管線定制

接下來講 URP 管線定制。我們的游戲雖然是 2D 游戲，但對(duì)光影方面做了相當(dāng)大的工作，有自己的光照系統(tǒng)。中間有一些流程管線的簡化都是共通的，比如移除 XR 相關(guān)、刪除不必要的 Graph 組件、3D 光影系統(tǒng)等。

接下來是我們針對(duì)這個(gè)游戲光影系統(tǒng)做的優(yōu)化。SortingLayer 我們用得比較少，對(duì)游戲排序跟光影控制有我們自己的算法去實(shí)現(xiàn)，單獨(dú)做光影烘焙，包括對(duì)象排序都是自己實(shí)現(xiàn)的，所以光照相關(guān)的 SortingLayer 我們?nèi)∠袅恕?/p>

混合模式管線里面帶了 4 種，我們都去掉了，只留下簡單的 Multiply，輔以美術(shù)對(duì)貼圖的控制處理來做集中方式的表現(xiàn)。視錐體的 culling 我們基于游戲本身的邏輯自己去做，對(duì)復(fù)雜的光照和視錐 cull 選擇性取消，也是一個(gè)可能的優(yōu)化點(diǎn)。所有光源烘焙成小的光照?qǐng)D，相當(dāng)于緩存機(jī)制，實(shí)時(shí)布燈在場景里面，但布燈操作不是特別頻繁，通過 DrawMeshInstanced 把它渲染出來。

啟動(dòng)速度 - 首包優(yōu)化

接下來進(jìn)入到首包優(yōu)化方面的介紹。首包很影響游戲速度，分為資源包和代碼包兩部分。

通過 AssetStudio GUI 工具分析首包場景，可以發(fā)現(xiàn)一些明顯體積比較大的包體資源，包括一些不合理的引用進(jìn)包，這是最容易忽視的。

進(jìn)一步剔除掉一些沒有用的 Package。DL 剔除了 analytics、unityanalytics、recoder、android-logcat、uielement、androidjni、physics2d、terrain、unitywebrequestwww、vehicles、wind、remote-config、test-framework、xr、terrainphysics、remote-config、jobs、TeshMeshPro、Burst、Mathematics 也是不需要的。

接下來介紹團(tuán)結(jié)引擎專有的 Wasm Inline Threshold。Inline 即內(nèi)聯(lián)函數(shù)，把一些函數(shù)實(shí)現(xiàn)注入到調(diào)用的函數(shù)里面去，會(huì)增大代碼體積，但能夠顯著運(yùn)行時(shí)期的性能，少了入棧出棧的操作。團(tuán)結(jié)引擎這個(gè)選項(xiàng)我們目前會(huì)做一個(gè)控制，適當(dāng)設(shè)置 Threshold 閾值，對(duì)運(yùn)行期有幫助，這是一個(gè)可以參考的優(yōu)化點(diǎn)。

代碼編譯選項(xiàng)設(shè)置，除非資源特別大，一般選擇 Faster Runtime。

然后是代碼的 Strip，團(tuán)結(jié)引擎針對(duì)引擎代碼提供 Strip Advice 建議選項(xiàng)，對(duì)于一些不用的模塊可以勾上。

有的時(shí)候 Strip 比較多的時(shí)候團(tuán)結(jié)引擎提供 DryRun 方式，可以在運(yùn)行時(shí)把 strip 掉的并且仍然在調(diào)用的函數(shù)打印出來。

Lua 方面，我們使用了 Lua & xLua，也做了一些相關(guān)的 Lua Binding 的優(yōu)化，對(duì)一些不需要用 API 的 Binding 通過黑名單去掉，精簡一部分代碼體積。

最后是 Wasm Analysis 工具，可以統(tǒng)計(jì)每個(gè)函數(shù)的指令數(shù)量及影響程度。對(duì)于一些不尋常的系統(tǒng)調(diào)用，或者一些間接的調(diào)用，可以通過這個(gè)工具發(fā)現(xiàn)有沒有剔除到位。

分包是微信開發(fā)者工具里面提供的代碼分包機(jī)制，把加載期的代碼跟后期使用的代碼或者不需要用的代碼分割或者剔除，這是非常重要的一個(gè)減少首包大小的方式。而且減少游戲加載之后的 WASM 編譯時(shí)間。

分包涉及到調(diào)用函數(shù)的收集，理想的情況下我們會(huì)把不需要調(diào)用的 API 或函數(shù)去掉，如果有新的函數(shù)調(diào)用增加進(jìn)來，通過這個(gè)收集捕捉到，追加到名單里。它提供的 Profile 分析包就是用來收集的，在游戲中統(tǒng)計(jì)哪些函數(shù)可以調(diào)用到就把它保留下來，如果哪些函數(shù)沒有調(diào)用到就去除掉。有的時(shí)候一開始去的比較激進(jìn)，調(diào)用失敗的時(shí)候會(huì)把日志打印出來，最終補(bǔ)充進(jìn)去，最后通過 release 的方式生成和發(fā)布。

啟動(dòng)速度 - 啟動(dòng)優(yōu)化

啟動(dòng)優(yōu)化，是進(jìn)入游戲之前先代碼下載、代碼編譯、資源下載，再進(jìn)入啟動(dòng)畫面的階段。

啟動(dòng)畫面出現(xiàn)之前的預(yù)下載階段比較重要，微信會(huì)在這個(gè)階段提供比較多的下載隊(duì)列，可以同時(shí)進(jìn)行多個(gè)隊(duì)列下載。因?yàn)槟J(rèn)這個(gè)階段 CPU 渲染占用比較低，比較重要的資源建議放在這里下載。

鴻蒙預(yù)下載機(jī)制目前有一些問題，后期可能會(huì)修復(fù)。

啟動(dòng)速度優(yōu)化的一些策略，首先第一個(gè)場景盡量小，最好只要一個(gè)背景圖，盡快讓用戶能夠看到你的游戲畫面。Shader 是很大的加載負(fù)擔(dān)，所以 Include Shaders 盡量能刪就刪，Preloaded Shaders 盡可能清理干凈，否則會(huì)顯著增加第一場景的進(jìn)場時(shí)間。

關(guān)于 Shader 變體 warmup，Unity 默認(rèn)提供了 Shader 變體 Warmup 機(jī)制，我們建議采用 WarmUpProgressively，或后面會(huì)推出的 WarmUpAsync 異步 Warmup 機(jī)制。因?yàn)?Unity 默認(rèn)的 Warmup 是阻塞的方式，會(huì)導(dǎo)致 H5 在加載時(shí)卡很久。當(dāng)時(shí)我們做的時(shí)候還是內(nèi)部接口，后面應(yīng)該會(huì)放開。通過異步的方式預(yù)熱 shader，避免游戲阻塞。

運(yùn)行時(shí)優(yōu)化

運(yùn)行時(shí)優(yōu)化分為以下幾個(gè)方面：

下載方面，可以考慮做一個(gè)任務(wù)池。后臺(tái)下載對(duì) H5 非常重要，可以把一些高優(yōu)先級(jí)的任務(wù)、必須立即下載的任務(wù)、非高優(yōu)先級(jí)的任務(wù)等做隊(duì)列的管理。

文件 IO，跟 Warmup 一樣非必要不同步。H5 里面能不阻塞的調(diào)用盡量不要阻塞，包括 IO 一鍵讀取也會(huì)容易掉幀，推薦采用異步存取的方式。

字體方面，為了提高加載速度我們做了幾個(gè)層次的優(yōu)化。剛開始進(jìn)入游戲使用 2M 的只包含游戲內(nèi)部使用的字體；后期需要加載較完整的字體，因?yàn)樯婕暗接脩粜彰土奶斓娘@示，會(huì)使用微信字體。

但微信字體在 iOS 18 后目前有一個(gè) BUG 暫時(shí)不能使用，未來會(huì)修復(fù)。在這之前我們會(huì)提供一個(gè)全字體 fallback 機(jī)制，在加載失敗之后會(huì) fallback 到全字體，所以目前是有三套。

再就是一些針對(duì)機(jī)型分辨率降低的適配方式。微信提供了 API，能夠獲取機(jī)器的等級(jí)。Benchmarklevel 是一個(gè)絕對(duì)的值，目前是不超過 50，它不會(huì)隨著時(shí)間推移改變，機(jī)器是多少級(jí)永遠(yuǎn)是多少級(jí)。

ModelLevel 表示相對(duì)于當(dāng)前年代，機(jī)型屬于當(dāng)前的高端機(jī)、中端機(jī)、或低端機(jī)。它會(huì)隨著時(shí)間變化，比如今年的高端機(jī)型，過了五年變成中端或者低端。大家根據(jù)具體的范疇使用這兩個(gè)參數(shù)做相應(yīng)的適配。

音頻方面也比較簡單，注意不要同時(shí)播放太多音效，盡量能夠自己去管理。我們除了背景音樂以外音效控制在 3 個(gè)以下，如果特別多會(huì)關(guān)閉一些音效。

Spine 是我們這邊 CPU 最大的瓶頸。首先是資產(chǎn)優(yōu)化，再就是一些規(guī)格的優(yōu)化。骨骼數(shù)同屏不超過 3000，單個(gè) Spine 骨骼數(shù)不超過 70。但是我們角色比較復(fù)雜，為了讓骨骼數(shù)降低，我們對(duì)角色朝向進(jìn)行了拆面。本來每個(gè)英雄所有朝向都在一個(gè) Spine 里面，現(xiàn)在我們把各個(gè)朝向的角色拆成了不同的 Spine，可以節(jié)省運(yùn)行期的內(nèi)存和性能。

對(duì)一些比較小的個(gè)體不使用 Spine，我們把 Spine 烘焙成 GPU 動(dòng)畫的方式，把 Spine 每一幀頂點(diǎn)信息存儲(chǔ)在貼圖里，然后在 GPU 里面根據(jù)這個(gè)時(shí)間去插值每個(gè)頂點(diǎn)的位置，把頂點(diǎn)繪制出來。這個(gè)方式有一個(gè)局限，必須要求 Spine 是純頂點(diǎn)動(dòng)畫，如果 Spine 包含頂點(diǎn)之外的動(dòng)畫變化就不能用這個(gè)方法。這個(gè)方法對(duì)性能有比較大的提升，特別是對(duì)屏幕數(shù)量特別多的小兵，優(yōu)化還是非常大的。

再就是 Spine 讀取，使用 NativeArray 代替 TextAsst.byte，提升性能。

延遲加載是把英雄的動(dòng)作進(jìn)行拆分，每次按需加載一部分動(dòng)作，而不是把所有動(dòng)作都加載進(jìn)去，可以減少內(nèi)存的占用。我們本身項(xiàng)目角色動(dòng)作會(huì)占用比較大的內(nèi)存，多達(dá) 200M。

再就是視口裁剪等常規(guī)的手段，超過視口的 disable 掉，不讓它更新和計(jì)算。

其他優(yōu)化，首先包括 UI 優(yōu)化。整屏 UI 彈出來以后讓背景場景的渲染暫停。

第二，相機(jī)的 Culling 優(yōu)化。團(tuán)結(jié)引擎提供了 Skip Culling 功能，我們會(huì)做一些自己內(nèi)部的 Culling，把 Culling 放在選項(xiàng)里面去，在需要自己 Culling 的時(shí)候就跳過相機(jī) Culling，減少相應(yīng)的開銷。

還包括做一些減法，比如 Native 中一些植被的動(dòng)畫，我們?cè)?H5 里面把它變成靜幀。

還包括 UI 方面做了一些比較大的精簡、特效刪減等。

Texture2DArray 無法正常支持，所以我們做光影烘焙的時(shí)候用的是 Texture 方式代替 Texture2DArray。

上線前部署

最后講一下上線部署。如果大家考慮要熱更的話，因?yàn)橘Y源是通過 URL 去標(biāo)識(shí)的，同一個(gè) URL 會(huì)有緩存的問題，如果 URL 不變，文件內(nèi)容變了，有可能會(huì)緩存到舊的，所以需要注意把版本號(hào)資源號(hào)放到文件名里，或者下載目錄包含版本號(hào)的信息，以作區(qū)分。

最后是 CDN 預(yù)熱。大家部署的時(shí)候可以在服務(wù)器這邊做 CDN 預(yù)熱機(jī)制，也會(huì)提高前期下載效率。

因?yàn)槲覀兪且粋€(gè)比較新的項(xiàng)目，在開發(fā)過程中跟團(tuán)結(jié)引擎團(tuán)隊(duì)、微信團(tuán)隊(duì)有密切的合作，謝謝大家。

Unity 官方微信

第一時(shí)間了解Unity引擎動(dòng)向，學(xué)習(xí)進(jìn)階開發(fā)技能

每一個(gè)“點(diǎn)贊”、“在看”，都是我們前進(jìn)的動(dòng)力