本文出自“Unity官方開(kāi)發(fā)者社區(qū)”，Unity Open Day 北京站-游戲?qū)?chǎng)分享

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

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

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

以下是分享正文：

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

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

小游戲平臺(tái)

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

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

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

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

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

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

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

資源流式加載

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

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

這里我們以一款線上的小游戲?yàn)榘咐?，看一看AutoStreaming的效果：首包中的數(shù)據(jù)減少了很多，從42M降低為6.8M，因此大大減少了啟動(dòng)耗時(shí)（40秒降低為7.88秒）。用戶打的AssetBundle也減小了一些，因?yàn)槲覀冎贿x擇了一部分貼圖做AutoStreaming，所以瘦身程度不是很大。

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

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

Native Instant Game

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

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

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

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

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

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

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

webGL

下面我們?cè)敿?xì)介紹WebGL方案，優(yōu)點(diǎn)是支持iOS和Android，但方案限制很多，我們會(huì)用更多的篇幅介紹。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從下圖中的Timeline Profile，可以看到MeshSkinning.Update時(shí)間開(kāi)銷從57ms降低到了29ms。

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

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

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

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

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

未來(lái)工作

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

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

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

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

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

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