本文出自“Unity官方開發(fā)者社區(qū)”，Unity Open Day 北京站-游戲?qū)龇窒?/span>

微信、抖音、QQ、快手、支付寶、頭條、百度等等都是國內(nèi)的小游戲平臺，以微信為例，其 2019 年 5 月已經(jīng)實現(xiàn)了玩家數(shù)量過億，2021 年流水過千萬的產(chǎn)品已經(jīng)超過 50 款。這些數(shù)據(jù)足以顯現(xiàn)當下小游戲擁有強大的玩家基礎(chǔ)以及變現(xiàn)能力，因此 Unity 正在逐步加大對移動端小游戲的支持。

Unity 中國引擎底層架構(gòu)技術(shù)主管趙亮帶來以 Unity 小游戲開發(fā)為主題的演講，演講中分別介紹了主流的小游戲平臺及技術(shù)方案；即點即玩小游戲需要用到的資源流式加載 Auto Streaming；小游戲技術(shù)方案：Native Instant game 與 WebGL。

演講中除了提供了極為實用的技術(shù)意見，還著重介紹了 Unity 引擎?zhèn)葍?yōu)化和改進，包括優(yōu)化內(nèi)存占用、優(yōu)化繪制的效率、進一步給引擎瘦身、加快小游戲的啟動速度。

以下是分享正文：

趙亮：今天跟大家一起聊一聊使用Unity開發(fā)小游戲。小游戲是一種嵌在宿主應(yīng)用內(nèi)部，無需下載安裝，可即點即玩的游戲產(chǎn)品形式。國內(nèi)小游戲用戶規(guī)模龐大，2018年，小游戲市場達到300億元規(guī)模，在移動游戲市場也是一個不小的占比，大概占到20%左右，因此Unity正在逐步加大對移動端小游戲的支持。

我的分享包括幾個方面：首先，我們介紹一下當前主流的小游戲平臺，以及他們采用的技術(shù)方案；接下來，介紹一下即點即玩小游戲需要用到的資源流式加載；然后，分別介紹兩種小游戲技術(shù)方案：Native Instant game與WebGL；最后，介紹一下我們未來的工作方向。

小游戲平臺

微信、抖音、QQ、快手、支付寶、頭條、百度等等都是國內(nèi)的小游戲平臺，這里介紹比較有代表性的微信和抖音，以及采用的技術(shù)方案。

微信是2017年12月發(fā)布“跳一跳”小游戲，2019年1月起開發(fā)者數(shù)量已經(jīng)超過10萬，2019年5月用戶過億，2021年流水過千萬的產(chǎn)品已經(jīng)超過50款。

圖中展示的就是微信小游戲的品類，隨著時間的發(fā)展，我們可以看出小游戲品類近年逐漸從超休閑向中重度發(fā)展，例如MMO、策略游戲等也開始往小游戲平臺發(fā)展。

大家也可以關(guān)注微信公開課，上面有些開發(fā)者分享使用Unity開發(fā)小游戲的經(jīng)驗。

抖音平臺經(jīng)過調(diào)研發(fā)現(xiàn)，小游戲受歡迎程度僅次于APP游戲，同時小游戲用戶規(guī)模較大，特征比較顯著，大多是18-40歲的年輕男性，有不俗的消費能力。

在宿主應(yīng)用中，實現(xiàn)即點即玩的小游戲主要有兩種技術(shù)方案：

一種是基于瀏覽器內(nèi)核，使用wasm+webgl的方案；另一種是在安卓上實現(xiàn)的native instant game。大部分小游戲平臺都采用WebGL，但native instant game好處是游戲品質(zhì)可以媲美原生APP，抖音和快手都在用這種方案。

資源流式加載

前面提到小游戲在從“超休閑”往“中重度”不斷發(fā)展，小游戲中用到的資產(chǎn)越來越多。有些小游戲資產(chǎn)打包后有幾百兆字節(jié)，甚至1GB以上。為了讓玩家可以即點即玩，減少等待下載的時間，需要實現(xiàn)按需的流式下載。對于游戲開發(fā)者來說，管理好資源的流式加載需要投入不少開發(fā)時間。因此我們在引擎?zhèn)乳_發(fā)了AutoStreaming這個功能，讓引擎底層自動處理好流式加載。

這里我們簡單介紹一下AutoStreaming（自動流式加載）的工作原理。在Unity Editor里，我們提供了工具，可以在打包時自動分離出重度資源。諸如：Texture、Mesh、Audio、Animation、Font。這些資源將被部署到云上。分離出重度資源后，游戲的首包、游戲的AB包會大大減小,因此可以讓小游戲快速的下載、加載。游戲運行時，引擎會根據(jù)需要自動從云上下載資源。開發(fā)者不用修改游戲的邏輯，可以像往常一樣同步實例化prefab。這些texture，mesh會在一個后臺隊列里，自動被下載、加載。

這里我們以一款線上的小游戲為案例，看一看AutoStreaming的效果：首包中的數(shù)據(jù)減少了很多，從42M降低為6.8M，因此大大減少了啟動耗時（40秒降低為7.88秒）。用戶打的AssetBundle也減小了一些，因為我們只選擇了一部分貼圖做AutoStreaming，所以瘦身程度不是很大。

另一處很重要的收益來自于內(nèi)存，內(nèi)存占用減少了75MB。內(nèi)存對于iOS平臺是很珍貴的。減小的原因在于被剝離的重度資源有更加合理的生命周期。未開啟AutoStreaming時，這些紋理在加載后依然占用內(nèi)存（首包內(nèi)存orAB內(nèi)存）。

這是webgl平臺的一個特殊之處，它沒有真正的文件系統(tǒng)，只有一個內(nèi)存中的文件系統(tǒng)。首包里的資源會持續(xù)占用內(nèi)存,AB在未unload前也會一直占用內(nèi)存。這跟原生APP不一樣，在原生APP中，每次讀取文件中的一塊，只要通過復(fù)用一小塊內(nèi)存就可以訪問一個大文件。

Native Instant Game

簡單介紹一下Native Instant Game方案：優(yōu)點很明顯，可以直接對標原生APP，性能一樣，體驗也是一樣；支持多線程；支持Gles3、Vulkan；原生APP插件也都可以用?？梢圆捎猛椒绞皆L問沙盒中的文件，訪問效率比較高，占用內(nèi)存也比較少；以獨立的子進程運行在沙盒中，不會干擾宿主運行；穩(wěn)定性和安全問題Native Instant Game也提供完整的方案。因此對移動游戲開發(fā)者來說適配Native Instant Game成本很低，只要進行流式加載，不需要額外的適配和優(yōu)化。

右側(cè)圖是來自抖音平臺的小游戲，叫做《古董就是玩兒》，我們曾經(jīng)將其適配至WebGL平臺，畫質(zhì)降低還是很明顯的，所以這是Native Instant Game的優(yōu)點。

當然了，它的缺陷也很明顯，它目前還沒法支持iOS平臺。所以微信沒有集成這種方案，字節(jié)、快手等其它平臺采用混合方案。在iOS上采用WebGL方案，在安卓上既支持WebGL也支持Native Instant Game。如果有些游戲追求性能天花板更高，可以采用Native Instant Game；假設(shè)追求受眾更多，游戲品質(zhì)沒有達到性能天花板上限，可以選用WebGL。

下圖介紹的就是Native Instant Game工作原理。Unity把每個小游戲運行時都需要的運行時庫、默認資源打包在一起，作為一個共享的引擎包，方便宿主APP提前準備，從而減少每個小游戲啟動時等待下載的時間。共享引擎包大約有9MB，具體包含libunity.so，libmono.so等運行時庫、通用的.net dll，如：mscorlib.dll System.xxx.dll UnityEngine.xxx.dll、Unity default resource。

有了共享的引擎包以后，開發(fā)者對小游戲平臺進行打包，基本上打包成兩部分就可以：首先是一個很小的首包，5-10MB左右，可以方便快速加載和下載，包含游戲本身的邏輯和第三方插件的so文件、AutoStreaming資源，以及一個json描述文件（游戲名稱、首包下載url、引擎版本和下載鏈接、文件MD5），供開發(fā)者提審，以及客戶端加載小游戲使用。

宿主客戶端啟動一個小游戲的時候會根據(jù)剛才提到的json文件描述拿到游戲首包。前面提到的共享引擎包，宿主通常都會提前下載和解壓。然后客戶端把首包解壓到小游戲?qū)?yīng)的沙盒文件夾，通過很小的InstantGame Launcher啟動Unity小游戲子進程就可以了。

游戲運行的時候可以自動從云端下載這些所需的資源，這些是針對AutoStreaming的情況，否則用戶需要自己動態(tài)加載。

webGL

下面我們詳細介紹WebGL方案，優(yōu)點是支持iOS和Android，但方案限制很多，我們會用更多的篇幅介紹。

WebGL在iOS平臺上內(nèi)存十分受限，低檔機不能超過1GB，高檔機大概1.4GB左右，超過這一限制可能就會觸發(fā)操作系統(tǒng)OOM迫使進程重啟。WebGL運行效率比原生APP慢3倍左右，目前只支持單線程不支持多線程，所以WebGL小游戲CPU性能比原生低不少。圖形API只支持WebGL1/WebGL2，所以有些高級特性和優(yōu)化沒有辦法使用，包括Compute Shader。沒有文件系統(tǒng)，所以需要更大的內(nèi)存模擬文件系統(tǒng)。這也導(dǎo)致Unity cache機制受到很大影響，cache文件無法被同步訪問。

由于CPU側(cè)性能比較弱，游戲復(fù)雜度提高、計算量增大的時候，手機很容易過熱。也會對網(wǎng)絡(luò)API有限制，因為只支持websocket，所以需要開發(fā)者進行適配。由于以上這些限制，導(dǎo)致能使用的插件也比較有限。iOS對于WebGL的支持也不盡如人意，我們經(jīng)常要為iOS平臺做特殊優(yōu)化、寫特別的workaround。

對于WebGL方案來說，iOS平臺的問題比Android平臺要多。因此接下來的討論中，我們都關(guān)注如何在iOS平臺上profile、優(yōu)化小游戲。iOS平臺優(yōu)化好了，Android平臺基本不會有問題。

我們這里使用一個案例分別打包原生APP和WebGL小游戲，對比內(nèi)存、CPU、GPU的差異。我們使用的測試手機是iPhone12。

相比原生APP，WebGL進程內(nèi)存占用多了450M左右，增大的部分在于加載和編譯占到340M；Wasm heap有些Unallocated內(nèi)存，多出來90M；File System多了60M。

除了Wasm文件本身之外，瀏覽器的內(nèi)核在代碼編譯執(zhí)行的時候也會產(chǎn)生更多的內(nèi)存消耗，相關(guān)的緩存、JIT優(yōu)化也會使用較多內(nèi)存，總體大約是Wasm文件大小的10倍左右。

接下來分析Unallocated的部分。Wasm heap的大小是從一個預(yù)設(shè)值開始，然后以一定步長逐步擴容，擴容的方式比較傻，需要復(fù)制整個ArrayBuffer。例如從400M擴容到500M，擴容的時候400M也在，500M也在，總共會有900M的峰值。我們建議開發(fā)者根據(jù)游戲?qū)嶋H內(nèi)存峰值，剛開始設(shè)立一個比較大的預(yù)設(shè)值。但這樣會帶來另外一個問題，就是會在wasm heap的尾部留有一段尚未分配的部分，就是90M的地方。

文件系統(tǒng)會多使用內(nèi)存。瀏覽器的沙盒機制導(dǎo)致WebGL無法訪問本地文件，為了瀏覽器安全，只能使用JavaScript + IndexedDB模擬一個文件系統(tǒng)。Wasm訪問js層，js層再訪問IndexedDB，這里js層會占用一定內(nèi)存，不能像Native文件系統(tǒng)那樣直接使用一小塊內(nèi)存訪問大的文件。

還有一處值得注意的是Mono Heap和Emscripten malloc的空閑空間。WebGL上，Mono Heap由IL2Cpp分配管理，其他native內(nèi)存（包括引擎Native Heap和其他第三方庫如Lua分配的內(nèi)存）由Emscripten的malloc分配管理（默認使用dlmalloc）。這兩部分都是只增不減，而且相互獨立，空閑空間無法共享，因此需要各自都注意控制峰值。

我們看到WebGL相比原生APP也有一部分內(nèi)存占用減少，比較顯著的就是Native Heap中的IL2Cpp Runtime。通過延遲加載meta信息、使用Sparse HashTable等方式使內(nèi)存從101MB降低到35.3MB。這里主要是針對WebGL平臺進行優(yōu)化，后面會詳細介紹這些。Asset相關(guān)的部分也有降低，因為資源壓縮格式進行了調(diào)整，來自引擎底層內(nèi)存分配器的行為和策略在不同平臺上也有不同。

再來看一看CPU計算性能的對比。之前網(wǎng)上看別人的Benchmark研究，webassembly的執(zhí)行效率約為原生app的三分之一左右。

我們拿了一款真實的小游戲進行測試。Timeline Profile可以看出原生APP耗時3.5毫秒左右，小游戲耗時10毫秒，所以整體來看WebGL的CPU性能與原生App相比相差3倍左右，其中既有WebGL單線程的原因，也有wasm本身執(zhí)行效率的問題，印證了之前Benchmark結(jié)果。

再來看GPU的對比，去除空白網(wǎng)頁本身的GPU消耗以外，對一個游戲來說，WebGL和原生APP差距并不大，我們可以認為WebGL小游戲的GPU性能和原生APP差不多。

WebGL小游戲的開發(fā)和移植最近幾年已經(jīng)有大量的成功案例，所以新進來的開發(fā)者不用很擔心，之前踩過的坑都已經(jīng)處理好了。Unity有一個官方QQ群，大家如果有什么問題可以在群里聊。微信為WebGL小游戲開發(fā)也整理了很詳盡的教程，公開課也有開發(fā)者分享使用Unity開發(fā)小游戲的經(jīng)驗。

為了減輕WebGL平臺限制對小游戲開發(fā)的影響，我們在引擎?zhèn)纫灿泻芏鄡?yōu)化和改進，包括優(yōu)化內(nèi)存占用、優(yōu)化繪制的效率、進一步給引擎瘦身、加快小游戲的啟動速度。

在一個案例中IL2CPP運行時內(nèi)存占用從64M優(yōu)化到了33M。也有優(yōu)化DynamicVBO pool的復(fù)用機制，測試案例中從59M降低到了38M。后面提到的代碼輕量化和資源裁減也會幫助減少運行時的內(nèi)存占用。

這里我們詳細介紹一下IL2CPP運行時內(nèi)存的優(yōu)化。我們首先分析一下IL2CPP運行時主要的內(nèi)存開銷。首先是Metadata，它是運行時構(gòu)建的元數(shù)據(jù)結(jié)構(gòu)，里面主要是Il2CppClass和它的各種成員變量。然后是global-metadata.dat，它是打包時生成的元數(shù)據(jù)序列化文件，在webgl平臺會完整地加載到內(nèi)存中。再是HashTable，用來在運行時加速元數(shù)據(jù)的訪問。

接下來，分析一下對Metadata部分的優(yōu)化。這里主要是針對Il2CppClass及其成員變量的延遲加載，其中MethodInfo占比最大。之前的libil2cpp實現(xiàn)中，在使用到某個類型時，會初始化這個類型完整的元數(shù)據(jù)：包括它的所有函數(shù)、接口、事件、屬性、虛函數(shù)表等等信息。但分析發(fā)現(xiàn)，腳本代碼運行時，通常只會用到很少的一部分元數(shù)據(jù)（在反射或虛函數(shù)調(diào)用時訪問）。例如：數(shù)組類型，它有155個方法，25個虛函數(shù)，實現(xiàn)了6個接口，但實際在運行時只會用到其中的很小一部分，存在冗余加載的情況。因此我們的優(yōu)化思路是延遲加載這些元數(shù)據(jù)，等到真正需要某個元數(shù)據(jù)項目時才去初始化這份數(shù)據(jù)。

圖中可以看到，除了Field之外的信息都可以進行延遲加載（Field信息在構(gòu)建對象實例時就需要，它決定了對象實例的的內(nèi)存布局）。延遲加載粒度可以精確到逐個方法的粒度。延遲加載也會帶來一個比較小的開銷，就是在訪問某個元數(shù)據(jù)前需要做一次非空判斷，目前我們還沒有Profile出它引入的性能回退。

我們根據(jù)兩個實際案例對比優(yōu)化前和優(yōu)化后的內(nèi)存占用，63.8M降低到33.2M，11M降低到6.5M。除了MetaData的內(nèi)存降低，HashTable也有降低，因為我們用sparse哈希表替代了dense哈希表。未來我們還會優(yōu)化global-metadata.dat這個序列化文件。它里面包含大量string，有一部分可以用hash值替代。它里面還有大量索引使用32位保存，這也比較浪費內(nèi)存。

除了內(nèi)存優(yōu)化以外，我們也在繪制方面做了很多優(yōu)化工作。WebGL不支持Compute Shader，這里通過Transform Feedback支持了GPU Skinning。優(yōu)化Shader Compiler，將non-const global變量移到main函數(shù)中，幀率可以從23幀提高到55幀。修改Immediate Const Buffer轉(zhuǎn)換過程，聲明成const并賦予一個初始值就可以將某案例從32FPS優(yōu)化到37FPS。我們還會提供可配置的max visible lights值，改成16甚至更小以后性能會有很大提升。iOS平臺對WebGL的支持不夠好，所以我們也針對iOS平臺做了特殊的Workaround，避免使用過多的Uniform變量。在iOS14.x-15.4的WebGL上有一個Bug，針對這些版本，我們對同一個Canvas不共享IB和VB，可以改善UI渲染性能。

可以看到打開GPU Skinning以后平均每幀消耗42毫秒左右，沒有開啟的話每幀需要消耗67毫秒左右。

從下圖中的Timeline Profile，可以看到MeshSkinning.Update時間開銷從57ms降低到了29ms。

看一看引擎代碼的輕量化。從前面的內(nèi)存分析可以知道，30多M的wasm在加載后會占用300多M的內(nèi)存，因此生成的wasm越小越好。之前Unity的方法主要是Managed Code Strip和Engine Code Strip，它們是通過靜態(tài)分析依賴的方式做的strip，以函數(shù)作為顆粒度。我們在這里會更加深入地分析打包生成的wasm代碼，看看除了這兩個Strip，我們是不是還有更多的優(yōu)化空間。

我們分析兩個案例。游戲指令數(shù)都是1200萬左右，其中il2cpp占比約60%，其余是引擎C++代碼，占比40%，然后我們按模塊對其進行分類，發(fā)現(xiàn)其中較重的模塊有 Physx, particle system, sqlite, mecanim等，如Physx占了 8%。

通過分析，目前發(fā)現(xiàn)的問題有：案例2是一個消除類游戲，并未使用到什么Physx仿真，僅僅在UI上使用了Physx的射線檢測，就引入了一個龐大的Physx庫，所以是非常不合理的。Wasm中有很多模版展開的代碼，拿空間換時間可能在某些平臺上是比較不錯的策略，但WebGL平臺內(nèi)存特別緊張，所以在WebGL上并不是一個好的策略。

目前我們做了的工作有：將一部分c++模板參數(shù)改為函數(shù)參數(shù)，減少生成的代碼量；用宏剔除 webgl項目用不到的模塊和函數(shù)，例如：Sqlite，ComputeShader，Physx的部分功能。未來我們還會繼續(xù)清理啟動流程、主循環(huán)里面不必要的步驟，以及探索如何優(yōu)化il2cpp代碼生成。

在加快啟動速度方面，我們主要做了兩件事情：一是跟平臺合作，讓平臺提供中文字體，避免每個小游戲都在首包里放一個中文字體，可以節(jié)省5-10M左右的下載時間。二是動態(tài)裁減Unity Default Resource，這些資源不見得每個小游戲都會用到。目前看來對大部分游戲可以把Default Resource從3.5M降到400K左右。之前我們還嘗試通過wasm snapshot方案進行加載。

未來工作

接下來聊一下未來工作的方向。除了前面提到的給global-metadata.dat瘦身、探索如何減少IL2CPP代碼生成，主要有多線程和WebGPU這兩大塊。我們還會探索Web Assembly上的SIMD，甚至嘗試讓W(xué)ebGL平臺支持Burst。

Unity現(xiàn)在已經(jīng)可以打開WebGL多線程，可以看到打開多線程以后，DeformSkinnedMeshJob從主線程轉(zhuǎn)到了web worker上。

這里還是針對之前的測試案例嘗試使用多線程，使用后每幀消耗從68毫秒降低到38-40毫秒左右。

但是目前Unity多線程還不夠穩(wěn)定、不夠完善，切換場景的時候可能Crash，目前也不支持RenderThread，因為web worker無法訪問DOM。打開多線程以后，內(nèi)存增加也比較厲害。另外WebGL多線程只能支持Native代碼，不支持C#代碼，也是我們要努力解決的問題。

四月底發(fā)布的Chrome 113已經(jīng)支持WebGPU了，目前我們也是一邊集成一邊研究如何重構(gòu)GFX Device的接口層，使它更接近于現(xiàn)代圖形API，從而能夠更多地發(fā)揮WebGPU的性能優(yōu)勢。

今天介紹到這里，謝謝大家！