《永遠的蔚藍星球》小游戲性能優化實戰

在 2026 年 1 月 24 日的 Unity User Group 深圳站活動中，詩悅網絡星辰工作室技術專項組負責人黎其桂帶來演講《永遠的蔚藍星球》小游戲性能優化實戰，與大家分享在保證高度還原 app 端的效果的前提下，主創團隊在包體、內存、渲染等方面付出的心力與經驗，以及如何利用團結引擎的優勢進一步減少引擎側的開銷。本文為演講全程實錄，點擊閱讀原文，可下載演講資料。

黎其桂：大家好，我是來自詩悅網絡星辰工作室技術專項組的黎其桂。很高興今天能來到這里，跟大家一起分享《永遠的蔚藍星球》這款微信小游戲的性能優化實戰經驗。

首先簡單介紹一下產品。《永遠的蔚藍星球》是一款隨機合成萌系塔防手游，好玩上頭，已于去年 6 月底公測上線。在完成 APP 端上線后，我們迅速投入到微信小游戲的適配與上線準備中。從 7 月到 8 月，游戲在微信小游戲平臺上取得了出色的成績，最高曾登頂暢銷榜第 4 名，目前穩定保持在暢銷榜前 20 名。

這次分享，我將重點介紹我們針對微信小游戲平臺所做的性能優化工作。在微信平臺開發，往往會遇到平臺本身的局限性，我們為此在包體、性能、渲染等多個方面投入了大量精力。

Part 1：WASM 包體

包體優化的第一步是常規手段：清理無用模塊，并開啟最高級別的代碼裁減。但開啟高級別裁減后，有時會錯誤地裁掉一些必要代碼。這時我們就需要結合 LinkXML 文件，將需要保留的關鍵代碼標記出來，同時將代碼裁減級別調到最高。

因為我們使用了 Lua 來實現系統和界面的邏輯，在 Lua 的封裝（Wrap）代碼中，往往存在一些在 Lua 端很少用到的 C# 接口或代碼。我們也將這部分內容進行了優化和裁減。具體做法是，先收集所有已導出 wrap 的類型和成員到一個列表中,再遍歷所有 lua 文件,通過字符串匹配的方式判斷已導出的 wrap 是否有調用,剔除掉未被調用的 wrap，最終把需要過濾的成員函數接入到 tolua 的導出過濾里面，最終把整包大小（webgl.wasm）優化到了 30m 以內。

最后，我們使用了Wasm Analysis工具（團結引擎中已經集成了此工具）來校驗裁減結果是否符合預期。這個工具非常好用，能夠幫助我們精準定位問題，高效解決包體體積的問題。

Part 2：WASM 代碼分包

第二，代碼分包。代碼分包在一定意義上來說，是小游戲平臺再進一步的代碼裁剪的手段，因為它是發布前，通過真實跑游戲去收集過程中使用到的函數，這些收集到的代碼函數就作為首包，在進入游戲時加載出來，剩下的用到才會去線上拉取。

代碼分包對開發者而言有利有弊。好處在于，分包能大大降低首包大小，提升啟動速度和有效轉化，同時也能降低首包編譯內存；壞處在于，既要“小”，又要“全”，這在工程上比較麻煩。微信平臺的分包機制在安卓和 iOS 上有所不同：安卓可以在后臺完整加載分包，而 iOS 則需要運行時逐函數拉取。如果 iOS 分包不完整，觸發了連續 5 個以上的分包拉取，用戶體驗會非常糟糕。因此，我們必須做到“既小又全”。

我們的做法是：

• 首次收集后進行人工微調。

• 通過工具實現增量管理。

• 遵循經驗：首包占比 30% 是一個較優的比例。

這里有必要介紹一下我們的分包輔助工具。在做微信分包時，我們發現分包界面提供了兩個手動管理的按鈕。出于好奇點擊后，發現“新增函數”和“總收集函數”的格式與 symbol 符號表文件里面非常相似。于是我們基于這個思路，通過反序列化了 symbol 文件，用新包的 symbol 去 diff 舊包，導出一份新增的函數列表，用這份列表導入到微信分包工具中就可以保證業務迭代的代碼都能加到首包里面。這樣能做到版本增量更新后腳本自動跑增量分包，提高效率提高準確率。最終也能保持分包后，首包函數占比 30% 左右，整體運行流暢。

Part 3：大量同屏元素

對于肉鴿塔防游戲來說，“爽感”至關重要，而這往往意味著滿屏的怪物、滿屏的特效和滿屏的飄字。這種感官體驗帶來的是巨大的性能挑戰。

以《永遠的蔚藍星球》為例，游戲場景中存在高達 5000+ 的粒子系統（Particle System）、同屏超過 200+ 怪物以及 3000+ 的傷害飄字。為了保證還原 app 的效果和品質，數量不能減少，要在小游戲平臺做到大量級，同時兼顧性能。面對這種同屏場景，無論是在內存、CPU 還是渲染層面，都帶來了巨大的壓力。

Part 3-1: GPU 序列幀

面對原生 Particle System 高昂的性能消耗（每個組件約占用 10KB），我們的第一反應是：盡量不用粒子系統。雖然它的表現力好，但 DC 過高，性能代價過大。

我們轉而采用GPU 序列幀方案。之所以叫 “GPU 序列幀”，是因為常規序列幀（如使用 Animate 組件或腳本輪詢圖集）是運行在 CPU 上的。而我們的優化思路是，在微信小程序這樣的平臺，CPU 壓力本就很大，因此要把能轉移到 GPU 的邏輯都轉移到 GPU 上去執行，所以就定義它為 GPU 序列幀。

具體實現上，關鍵點是利用了GPU Instancing。我們將粒子的表現效果烘焙到圖集或圖片中，然后在 GPU 中進行計算和還原。優化后，原來 1500+ DrawCall 的場景可以通過 GPU Instancing 合批到 233 個 batches，簡單而有效。

Part 3-2: GPU粒子

既然序列幀很有效，為什么還要做 GPU 粒子？因為序列幀有其局限性。當面對全屏播放、幀數很高的特效時，序列幀圖集會變得異常龐大，得不償失。另外不支持 3D，比如立體透視的龍卷風、拖尾等，而且存在填充率問題，overdraw 很高。

因此，我們引入了GPU 粒子的概念，使用VAT（Vertex Animation Texture，頂點動畫貼圖）。它的核心思想是，把大網格、ID 索引、粒子的屬性和材質的屬性都烘焙下來，裝到頂點著色器里，在頂點著色器中用 SV_VertexID 去逐步解析出粒子和粒子系統的 ID，再去獲取對應下標的各項數據，從而將計算壓力完全轉移到 GPU。

在實踐中，我們克服了兩個主要難點：

• 動態變化的粒子記錄：粒子系統的一大特點是粒子隨著時間會不斷的生成和消失，常規 VAT 做法以橫坐標為粒子數、縱坐標為幀數，會導致貼圖空間浪費。我們在烘焙粒子信息時，舍棄了粒子的固定順序，把貼圖寬度壓縮為同時存在的最大粒子數目。雖然放棄了粒子的嚴格先后順序，不能采樣相鄰幀做動畫的平滑，但極大地壓縮了貼圖大小，降低了內存和帶寬消耗。

• 多粒子系統網格烘焙：另一個難點是，特效可能包含多個粒子系統，而每一個粒子系統可能又由多種網格組成。這時候可以以單個粒子系統的單種網格為最小單元，把每個單元的貼圖進行水平拼接。

實現時，在將資源烘焙好之后，需要記錄兩張索引表來還原粒子 ID 和粒子系統 ID，再由此讀出烘焙好的各類信息。其中粒子 ID 可以用來讀取逐粒子的信息，比如每個粒子的 Transform；粒子系統 ID 可以用來讀取逐粒子系統的信息，比如材質參數。最終在頂點渲染階段完成所有計算，這樣邏輯、渲染都在 GPU 層面。

這一優化不僅降低了 CPU 負荷，還讓我們可以精確控制渲染層級，解決了原生粒子系統在層級穿插上難以把控的問題。

Part 3-3: 怪物 GPU 動畫

三是怪物 GPU 動畫，還是繼續壓榨 GPU。在這個場景里有同屏 200+ 的怪物，對于 2D 游戲，動畫常用 Spine 組件。但 Spine 組件存在內存占用高、CPU 開銷大、實例無法共享的問題（200 個相同怪物就要 200 份消耗）。

我們的思路依然是 “CPU 轉移到 GPU”，即將怪物動畫也變成頂點動畫（VAT）形式。在將 Spine 動畫烘焙為 VAT 的過程中，同樣遇到了挑戰：

• 動畫部件顯隱記錄：Spine 動畫播放過程中會實時改變部件的顯示和隱藏，例如武器投擲，特效附件的出現和隱藏，部件的切換等，為解決該問題，我們在自制的 Spine 導出工具中，把所有附件預烘焙到一個靜態 Tpose 網格中（右圖），當某一幀某個附件需要隱藏時，VAT 會在對應位置記錄一個非法值（如負無窮大），播放時讀取到非法的頂點位置信息就會自動隱藏。

• 部位之間的層級變化：動畫播放過程中還會出現部件之間渲染順序變化的問題，如左圖，渲染順序從右手-->身體-->左手，變成身體-->左手-->右手。原生 Spine 對部件之間渲染順序的控制是通過頂點的 Z 軸坐標實現的，因此在烘培 VAT 時，會根據 SlotIndex 和 zSpacing 計算出每幀對應部件的 Z 軸坐標。

最終導出的核心資源：

• TPose 網格（包括所有部件）

• vat 貼圖（黑色部分就是寫入的非法值）

同個 Spine 的多個實例可以合成一個 DC。所以我們實現了能合批的 spine GPU 動畫，而且上游制作流程無感。

優化后，GPU Spine 對比原生 spine 在耗時、drawcall 和內存上都有很大的優化。

Part 4：高性能飄字

我們的舊版飄字存在一個問題，它是通過一個大網格管理同屏中所有出現的飄字，并通過網格通道傳遞飄字信息的，在每次生成飄字的時候需要重建整個大網格，一方面重建網格會造成 CPU 耗時，另一方面重建后需要把網格重新從 CPU 傳到 GPU 上，會造成帶寬浪費。

我們最初的優化方案是預分一個大網格，將所有字體烘焙進去。但這仍是“舊版方案”，每飄一個字就要重建一次網格，仍然會造成性能峰值，并且在 CPU 向 GPU 傳遞大量數據時會產生嚴重的帶寬鋸齒。

我們的“新版方案”核心是使用 CBuffer 傳遞飄字信息，拋棄了每次更新都重建網格的方式，只需要通過材質修改對應 Cbuffer 即可完成。

改版后，不再通過網格通道記錄數據，現在的網格只使用了一個 4 字節大小的 SV_VertexID。以往逐頂點記錄的數據現在可以逐文本記錄，并且對數據進行了充分壓縮，充分利用了總量為 16k 的 Cbuffer，大幅降低帶寬浪費，極致地完成了飄字效果還原。

優化后，新版飄字保證了原有飄字數量 3000+ 的前提下,可以看到左上角的帶寬更穩定了，帶寬峰值從每幀 8mb 降到每幀 3mb。

不僅線條平滑，在游戲高壓場景下（合作模式第十層）最低幀率從 32 上升到 48。

Part 5：團結引擎側優化

團結引擎帶來的直接收益

除了業務層面的優化，《永遠的蔚藍星球》也受益于團結引擎的優化升級。團結引擎為小游戲提供了針對性的優化，帶來了立竿見影的性能收益：

• il2cpp 虛擬機優化：減少約 30MB 內存占用。

• 內存分配器 overhead 優化：減少約 7-11MB 內存。

• 粒子系統內存減少約 15MB：剔除未使用的粒子系統模塊內存占用，粒子系統播放結束釋放內存，數量越多收益越大，該功能默認開啟。

• TypeTree 內存優化：小游戲可只加載 MonoBehaviour 對應的 TypeTree，節省序列化文件內存，減少約 25MB 內存。

• 此外，Slim Global-Metadata、String Intern Pool、Dynamic Buff Reuse 等優化也貢獻了可觀的增益。

總計，從 Unity 引擎切換到團結引擎，我們直接獲得了約 100MB 的內存下降。這對于開發者是巨大的好處，并且線上閃退率也直接砍半。

WebGL Metal

我們在 iOS 平臺上還使用了Metal渲染后端。Metal 通過直接調用 iOS 原生 API，避免了 WebGL 到 Metal 的中間轉換層，減少了 GPU 帶寬消耗和功耗。從實際測試數據看，在幀率和亮度一致的情況下，使用 Metal API 在 iOS 機上的功耗下降了 17%,帶來了更好的體感和設備溫度表現。

以上就是我今天分享的小游戲優化。雖然是小游戲，但其中的優化技術卻并不“小”。我們對包體、渲染、引擎底層等多個層面進行了深度探索和實踐。未來，我們也期待著像團結引擎正在開發的Infinity 粒子系統這樣的新技術能盡快上線，這能極大地減輕我們手動定制 VAT 的工作負擔。

最后，希望大家還是要以一個精品游戲探索者的角色，堅持做難而正確的事情。

以上就是我的分享，希望大家可以一起交流學習，謝謝。

UUG（Unity用戶組織）是一個連接本地 Unity 開發者的社群網絡。十年來，全國各地的志愿者們在北京、上海、廣州、深圳、杭州、武漢、成都、廈門、沈陽等城市成功舉辦了 50+ 線下交流活動。2026 年，我們希望能構建一個具備更多可能性的場域，讓創作的能量在這里流動。

深圳 UUG 的演講資料已上傳至網盤，點擊閱讀原文下載，持續關注學習。

Unity 官方微信

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

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