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

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

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

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

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

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

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

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

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

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

代碼層性能提升策略

這里面有兩個(gè)“避坑指南”和一個(gè)“加分項(xiàng)”：

• 分幀加載/處理機(jī)制

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高性能與 JIT

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

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

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

Unity 官方微信

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

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