《永遠的蔚藍星球》小游戲性能優(yōu)化實戰(zhàn)

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

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

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

這次分享，我將重點介紹我們針對微信小游戲平臺所做的性能優(yōu)化工作。在微信平臺開發(fā)，往往會遇到平臺本身的局限性，我們?yōu)榇嗽诎w、性能、渲染等多個方面投入了大量精力。

Part 1：WASM 包體

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

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

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

Part 2：WASM 代碼分包

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

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

我們的做法是：

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

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

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

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

Part 3：大量同屏元素

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

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

Part 3-1: GPU 序列幀

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

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

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

Part 3-2: GPU粒子

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

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

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

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

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

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

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

Part 3-3: 怪物 GPU 動畫

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

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

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

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

最終導出的核心資源：

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

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

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

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

Part 4：高性能飄字

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

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

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

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

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

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

Part 5：團結引擎?zhèn)葍?yōu)化

團結引擎帶來的直接收益

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

• il2cpp 虛擬機優(yōu)化：減少約 30MB 內存占用。

• 內存分配器 overhead 優(yōu)化：減少約 7-11MB 內存。

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

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

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

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

WebGL Metal

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

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

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

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

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

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

Unity 官方微信

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

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