千萬級產(chǎn)品背后的技術邏輯：同趣科技 CEO 詳解小游戲性能調(diào)優(yōu)策略

小視作為輕量級內(nèi)容載體，對性能要求非常高。同趣科技 CEO William 博士在今年的 Unite 大會上分享了團隊在框架設計、啟動優(yōu)化、CPU/GPU 協(xié)調(diào)、內(nèi)存與資源管理等方面的優(yōu)化經(jīng)驗，并介紹如何借助對小游戲友好的團結(jié)引擎，實現(xiàn)性能和效率的突破。

William：各位開發(fā)者朋友們，大家早上好！很榮幸有機會在這里跟大家分享“小游戲平臺性能調(diào)優(yōu)策略”。大家都知道小游戲的用戶對性能要求特別敏感，因為它受性能所限。無論是資源、還是空間，都比較有限。開始之前，先介紹一下我們公司。我們公司目前已經(jīng)成立超過 10 年，在杭州，早期主要是做“出?！钡?，近兩年有在聚焦做國內(nèi)的一些小游戲，做過的產(chǎn)品目前也已經(jīng)超過了 100 多款。

下圖是近兩年有登陸過各個榜單 TOP1 的部分產(chǎn)品，大部分都是益智休閑類，這些產(chǎn)品全部都是千萬級以上，部分都是“億”級別的一些產(chǎn)品。

第一款《箭頭消消消》是 2023 年初做的一個產(chǎn)品，那時候整個市場環(huán)境都在用別的引擎在做 2D 類的產(chǎn)品。我們其實希望做出差異化的產(chǎn)品，當時 Unity 在適配小游戲上還不是很成熟，比如一款產(chǎn)品、一個游戲加載可能就需要 10 秒、有些甚至超過 20 秒，用戶的體驗非常差。但是我們依然堅信 Unity 的游戲在美術表現(xiàn)上會更細膩一些，其他方面會做得更好，所以當時 Unity，而且無論是微信團隊或者抖音的團隊，也給了我們大力的支持。所以在這里，也特別感謝 Unity 的團隊。

第二款《打螺絲達人》是大家可能經(jīng)常在朋友圈看到的。第三款是我們做的一個卡比巴拉元素的一個產(chǎn)品，當時在國內(nèi)整個引起的一個卡比巴拉的一個熱潮。最后一個是《豬了個豬》，今年上半年爆發(fā)的一個產(chǎn)品，目前用戶已經(jīng)過億。在制作《豬了個豬》的過程中，我們在技術上也踩了很多坑。之前在其他平臺的幾次分享，我都是分享從立項到調(diào)優(yōu)、到買量，都是去聊運營、聊產(chǎn)品，今天是第一次在這個平臺去聊技術。我們也樂意把過程中積累的經(jīng)驗，今天毫無保留的分享給大家。

首先，我們得明確小游戲性能的核心痛點：內(nèi)存受限，加載要求高，多平臺適配難。針對這些痛點，我們總結(jié)了 5 大優(yōu)化方向：

框架與資源管理優(yōu)化

預制體：首先可以提高復用性，通過預制體，比如結(jié)算界面、皮膚商店界面，可以批量的生成實例，減少重復創(chuàng)建開銷、提升加載效率；其次預制體可以統(tǒng)一管理，修改預制體參數(shù)能自動同步到所有實例，降低維護成本，提升開發(fā)效率；第三是性能優(yōu)化，預制體支持安需加載，減少運行時資源占用，優(yōu)化性能表現(xiàn)；最后是場景結(jié)構(gòu)清晰，預制體可將復雜場景節(jié)點模塊化，提升 Hierarchy 可讀性，為后續(xù)優(yōu)化的提供清晰的基礎。

對象池：可避免頻繁創(chuàng)建銷毀，對象池可復用頻繁生成與銷毀的對象。以《豬了個豬》為例，角色、拖尾特效等，可以減少內(nèi)存分配與回收。同時可以降低 GC 壓力，減少垃圾回收觸發(fā)的頻率，降低內(nèi)存的抖動與程序的停頓。從下圖中可以看出來，它提升了游戲的穩(wěn)定性和流暢度。此外，對象池可以有效降低 CPU 的負擔，特別適用于微信小游戲或者抖音小游戲。這些對性能特別敏感的平臺，也包括鴻蒙或者其他 OV 系統(tǒng)。因為現(xiàn)在的硬核渠道也增長迅猛，或者說像硬核聯(lián)盟、小米渠道等等。

設計模式：合理使用設計模式，減少代碼耦合度，方便閱讀和維護。但過度使用，可能會增加代碼量和影響性能。

代碼層性能提升策略

這里面有兩個“避坑指南”和一個“加分項”：

• 分幀加載/處理機制

分幀加載/處理核心思想：將原本集中在一幀內(nèi)完成的密集任務，分攤至連續(xù)的多幀中執(zhí)行。

• 啟動速度與主包精簡策略

大家都知道小游戲主包要求越小越好，主包越小首屏展示越快、用戶流失越少。通過資源分包、壓縮紋理與音頻手段，可以精準主包。另外，就是首場景的異步加載，實現(xiàn)用戶點擊即進入游戲就能看到畫面，降低流失率、提高啟動的速度。

最后就是結(jié)合首場景異步加載策略，優(yōu)化啟動流程。這個也是微信小游戲提升留存的一個關鍵環(huán)節(jié)，大家都知道對于小游戲來說其實需要跟運營去結(jié)合、跟買量結(jié)合。我覺得性能應該對留存的幫助是特別大的。

剛才看到的幾款產(chǎn)品其實基本上都已經(jīng)調(diào)優(yōu)超過三年，但是一直還在調(diào)，這些基本上都是兩三年前的產(chǎn)品。我們?yōu)槭裁匆恢边€在調(diào)？我們其實因為是買量結(jié)合，也能實時看到這個真正投放到底有沒有效果，這些調(diào)優(yōu)的反饋會比較及時。

切勿在 Awake 回調(diào)函數(shù)中執(zhí)行復雜邏輯

在 Awake 中避免放置復雜邏輯是 Unity 開發(fā)中一條至關重要的性能優(yōu)化準則，尤其是在微信小游戲中。所以如果 ScpritB 的 Awake 里有一段代碼需要依賴 ScpritA 的初始化，而 ScpritA 的 Awake 還沒執(zhí)行，你就會得到一個 NullReferenceException。如果在 100 多個對象池的 Awake 做的耗時操作（如查找物體、加載資源、復雜計算），這些操作會疊加起來阻塞主線程，導致場景加載出現(xiàn)一個巨大的卡頓峰值，進度條停滯不前。對于微信小游戲來說，首場景加載時間就是生命線，因為用戶如果卡頓 1 秒鐘可能就丟失一大批。如果在關鍵節(jié)點卡頓，基本上這個用戶就流失了，所以必須盡一切可能縮短這段時間。在 Awake 中過早地加載大量資源或?qū)嵗瘜ο?，會導致?nèi)存瞬間飆升，大量資源在場景加載初期就被塞入內(nèi)存，無論你是否立刻需要它們，無法優(yōu)雅地管理，就失去了按需加載和分幀初始化的機會。正確的做法就是 Awake 只做簡單的初始化，在 Start/OnEnable 中去做一些邏輯。

CPU 與 GPU 協(xié)同優(yōu)化

下圖是小游戲一幀的流程，技術人員應該都比較清楚。比如說我們從一開始執(zhí)行游戲邏輯、物理，再到 CPU 的準備工作，之后 CPU 再將 DrawCall 的資源提交給 GPU 處理，以及最后到 GPU 的渲染，包括輸出到屏幕上。

做小游戲，我覺得性能要求特別高，所以可以用一些 Unity 自帶的 Profiler 的性能分析工具。如下圖所示，左側(cè)是性能分析器模塊，右側(cè)是幀圖表。這些模塊的作用，比如 CPU 可能會顯示各個函數(shù)跟模塊的 CPU 耗時，支持展開調(diào)用棧、定位耗時函數(shù)，以及包括 GPU 耗時的一些需要支持的平臺和驅(qū)動、內(nèi)存分布等等都有。所以我覺得在開發(fā)小游戲的過程中，這些工具可以用起來。

下圖是我們 Profiler 上的一個截圖，大家可以看一下。主流手機一般都是在 60 幀，一幀大概就是 16.66 ms。如果超過 16.66 ms，CPU 處理就過大，可以考慮把 CPU 部分功能分攤給 GPU，降低 CPU 的壓力，比如存在大量動畫節(jié)點時可以使用 GPU Skinning。例如：原來給 CPU 處理之前，可能就是基本上要到 20ms，部分工作交給 GPU 以后就能達到 16.6ms，幀率能夠達到 60 幀以上。

下面介紹 GPU Skinning。對于需要極致性能或有特殊需求（如大規(guī)模人群、頂點動畫）的項目，可以使用 Compute Shader 來手動實現(xiàn) GPU Skinning。工作原理就是在 GPU 上并行計算所有頂點的最終位置，將結(jié)果寫入一個 ComputeBuffer 中。然后在渲染時，標準的不含皮膚邏輯的頂點著色器直接從該 ComputeBuffer 中讀取最終的頂點位置。優(yōu)點是性能最高，靈活性最強，可以處理非常規(guī)的動畫效果。缺點就是實現(xiàn)操作比較復雜。

下方是我們使用前后的對比圖。未使用 GPU Skinning，可能 GPU 耗時就是 30 多 ms，用完后就可能達到 16.6ms，大概 60 幀率。使用過后的一個效果就是提升了幀率，游戲更加流暢，減少 CPU 的處理壓力，有效降低發(fā)燙和發(fā)熱。特別是對于 iPhone 來說，大家知道 iPhone 手機玩小游戲其實發(fā)燙就特別明顯。所以這些對于規(guī)模上一定量級的小游戲，我覺得這一點處理特別重要。

另外一個模塊，講一下內(nèi)存與資源的優(yōu)化策略。紋理壓縮可以采用 ASTC 等格式壓縮紋理，貼圖 maxsize 盡量不要超過 1024。音頻處理，音頻資源盡可能勾選強制單聲道。大家都知道聲音文件是很大的，在小游戲這種對內(nèi)存要求極高的，所以你可能要稍微損失一點這個效果。盡量避免使用 RenderTexture，盡量減少 RenderTexture 的使用；同時要做到主動的釋放資源，及時釋放不使用的資源，比如使用對象池來頻繁創(chuàng)建銷毀的對象。還有就是合理地觸發(fā) GC，比如每局游戲的開始、結(jié)束或者場景切換時，主動觸發(fā)垃圾回收。針對 iOS 跟平臺，也要采取差異化不一樣的 GC 控制策略。

高性能與 JIT

高性能模式下，內(nèi)存可能要求更加嚴格，比如 iPhone 6s、7、8 等 2G RAM 機型的內(nèi)存限制為 1G；對于 iPhone 7P/8P/11 等 3G 以上內(nèi)存機型的內(nèi)存限制為 1.4G。當內(nèi)存緊張的時候，這時候需要引入代碼分包。分包的作用在于優(yōu)化啟動時間。另外對于 iOS 的高性能模式，分包還有兩個作用：一個是減少內(nèi)存使用，以支持更多 iOS 低端機上運行高性能模式，另一個是減少編譯時間，降低了游戲前期的發(fā)燙情況。大家都知道由于 iOS 平臺系統(tǒng)限制的原因默認無法 JIT 解釋執(zhí)行，所以結(jié)果就會導致 JS 執(zhí)行性能受限。那么高性能模式使用 Apple Web kit，間接獲得了 JIT 的能力，就顯著提升了 iOS 的性能。同時我覺得開發(fā)者的優(yōu)化核心還應該是精簡 JS 代碼、減少循環(huán)和遞歸的使用，并精細內(nèi)存管理、對象池的引用，避免泄漏。

最后我們聊一下團結(jié)引擎。給大家推薦一個利器就是團結(jié)引擎，它對于小游戲平臺特別友好，支持微信、快手等平臺的 MiniGame 構(gòu)建，就不需要到處去查找插件。另外一個就是性能上，我們也做了一下對比，就是性能上也有較大的提升。下圖是《豬了個豬》的內(nèi)存對比。大家可以看到 Shader、粒子系統(tǒng)、字體等方面都有特別明顯的提升。比如第一項，用 Unity 占用空間 40 多 MB，用了團結(jié)以后可能只有 4MB。

小游戲的性能調(diào)優(yōu)不是一錘子買賣，而是細節(jié)堆出來的流暢。比如一個預制體的使用，一次二維邏輯的調(diào)整，一次 GPU 的協(xié)同，看似小事，卻能決定用戶是否留下來。希望今天的分享對大家有所幫助，也期待未來和大家一起探索出更多優(yōu)化的方案。謝謝大家！

Unity 官方微信

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

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