業(yè)務(wù)背景

AnnieX作為字節(jié)一方游戲統(tǒng)一容器，服務(wù)字節(jié)內(nèi)部電商、直播、UG等跨端場景業(yè)務(wù)。在字節(jié)一方游戲互動場景，有大量的一方游戲業(yè)務(wù)對容器有特定的流量、端能力和游戲優(yōu)化的訴求。因此我們不斷深入互動游戲業(yè)務(wù)特點，為字節(jié)游戲提供完善游戲端能力和流量運營能力，同時提供游戲互動場景極致優(yōu)化能力，提升游戲業(yè)務(wù)的整體性能。

養(yǎng)羊賺錢

種樹賺錢

萌寵旅行家

新周中/周末

今年是抖音春節(jié)活動的第7年，我們跨端容器已經(jīng)具備豐富的端能力的同時，也提供了一些對于跨端容器常規(guī)的一些優(yōu)化手段，例如：資源預加載、網(wǎng)絡(luò)預請求等手段，并且在往年春節(jié)活動中取得了不錯的優(yōu)化效果。而今年，我們希望能夠基于游戲場景，逐漸深挖游戲互動場景的特點，為春節(jié)等游戲場景去提供更加豐富和專業(yè)的游戲優(yōu)化能力。

春節(jié)-神龍尋寶

春節(jié)-守衛(wèi)現(xiàn)金

春節(jié)-搖福簽

春節(jié)-神龍?zhí)綄?/span>

互動套件介紹

因此我們基于24年抖音春節(jié)活動，在容器側(cè)提出了互動套件的建設(shè)，希望為游戲互動場景提供優(yōu)化解決方案。24年春節(jié)我們完成游戲引擎預熱和游戲資產(chǎn)公共離線庫的相關(guān)優(yōu)化，在24年春節(jié)得到了不錯的優(yōu)化效果；同時我們完成了游戲資源（解）壓縮的探索和更高效的物理引擎探索，希望能夠在25年春節(jié)完成壓縮和物理引擎的落地，從而豐富游戲互動玩法的同時，提升游戲的整體性能。

資產(chǎn)離線公共庫是一個重要的資源管理工具，管理了游戲互動業(yè)務(wù)所需要的游戲引擎資源。通過對游戲主包拆包和引擎資源的統(tǒng)一管理，資產(chǎn)離線公共庫能夠有效地幫助降低游戲包的大小，從而提高游戲的運行效率。此外，資產(chǎn)離線公共庫還能夠通過復用本地離線公共庫的引擎版本，進一步降低游戲包下載的整體耗時和帶寬成本。

引擎預熱是一種提供了與游戲引擎優(yōu)化相關(guān)的能力的技術(shù)。其原理是在游戲啟動過程中，對游戲引擎進行預熱，以便游戲邏輯執(zhí)行過程中更快地加載游戲引擎包，從而提高游戲加載速度。通過提前準備游戲引擎，在游戲啟動時，就可以更快地進入游戲世界，減少等待時間。這種技術(shù)可以為玩家?guī)砀玫挠螒蝮w驗。

資源的壓縮與解壓縮可以極大地提高資源利用率，有效降低資源包體積和網(wǎng)絡(luò)加載時長。資源的壓縮處理是在引擎編輯器的打包構(gòu)建階段做的資源預處理，而資源的解壓縮則被放在了互動容器中，在游戲載入過程中實時進行處理。

物理引擎，目前前端游戲開發(fā)者主要依賴js或者wasm版本的物理引擎，在游戲性能和體驗上存在較大的優(yōu)化空間，因此我們探索在容器側(cè)提供更高效的物理引擎方案，從而為游戲開發(fā)者和設(shè)計師提供更好的物理引擎解決方案，豐富游戲互動玩法體驗。

本文主要介紹24年在春節(jié)場景落地的引擎預熱和資產(chǎn)公共離線庫相關(guān)的優(yōu)化手段。同時介紹、探討我們游戲資源（解）壓縮方案的探索和在探索中遇到的問題。

名詞解釋

引擎預熱&資產(chǎn)離線公共庫

業(yè)務(wù)痛點

基于游戲業(yè)務(wù)已有的數(shù)據(jù)進行分析，我們發(fā)現(xiàn)游戲互動場景有以下2個特點：

• 依賴游戲引擎：在游戲中，游戲互動場景的創(chuàng)建和運行需要依賴于游戲引擎的加載和初始化邏輯。這個過程會消耗大約200ms～300ms的時間，這可能會對游戲的性能產(chǎn)生一定的影響。因此，為了提高游戲的響應(yīng)速度和流暢度，游戲開發(fā)者需要盡可能地優(yōu)化引擎加載和初始化邏輯的執(zhí)行效率。
• 游戲加載耗時和用戶異常流失率呈正比：啟動性能對于游戲的用戶體驗至關(guān)重要，因為如果游戲啟動沒有優(yōu)化好，用戶需要等待很長時間才能看到游戲畫面。這樣很可能會導致許多用戶在游戲加載完成之前就退出游戲。根據(jù)已有的游戲數(shù)據(jù)分析，游戲加載時間在1.5秒后，每0.5秒左右就會有4%左右的用戶異常流失。因此，游戲開發(fā)者需要高度重視游戲啟動性能的優(yōu)化，以確保游戲能夠快速啟動，讓用戶盡快進入游戲世界。

因此我們針對游戲互動場景完成了引擎預熱的方案，整體在24年春節(jié)場景落地，雙端取得了不錯的加載收益。

整體思路

在優(yōu)化之前，在容器加載游戲主包完成之后，才會開始渲染游戲首屏頁面和執(zhí)行游戲業(yè)務(wù)邏輯。當游戲的業(yè)務(wù)邏輯在執(zhí)行的過程中，必須等待容器完成游戲引擎資源的加載和初始化，這部分在線上存在一定的耗時。因此，為了解決這個問題，我們在容器側(cè)和前端工具鏈完成了一系列改造，以提高游戲頁面的加載速度。

具體地來說我們在容器打開游戲頁面路由階段，就完成了游戲引擎的預加載，并在跨端框架完成初始化之后，充分利用JS線程空閑的時間，完成游戲引擎的預熱，并將預熱好的實例掛載在全局對象中，這樣當游戲頁面真正執(zhí)行的時候，就能直接通過全局對象中的獲取到游戲引擎實例，從而完成后續(xù)的游戲業(yè)務(wù)邏輯。

技術(shù)細節(jié)

開發(fā)工具鏈改造

前端工具鏈方面，在構(gòu)建工具中接入speedy-split-chunks插件，在游戲打包的過程中，將游戲引擎包從游戲主包中拆分出去，并將引擎庫發(fā)布到靜態(tài)資源分發(fā)平臺公共離線庫下；封裝split-engine-adapter組件，完成引擎預熱的前端代碼插樁，并在引擎預熱時，提供兜底邏輯，保障業(yè)務(wù)的穩(wěn)定性。在剔除游戲引擎包同時，并將剔除出來的引擎包和對應(yīng)的meta文件部署到靜態(tài)資源分發(fā)平臺公共離線庫，通過meta文件來維護離線公共庫的游戲引擎資源版本，供多個游戲互動業(yè)務(wù)使用，從而降低帶寬成本。

另一方面，我們的split-engine-adapter插件可以在請求加載引擎資源文件時，完成對requireModule函數(shù)的hook。在這個過程中，如果發(fā)現(xiàn)全局對象上不存在的引擎實例，那么就會通過requireModule請求拆包引擎包作為兜底措施。通過這種方式，可以避免因引擎實例不存在而導致的錯誤，從而提高系統(tǒng)的穩(wěn)定性和可靠性。

預熱游戲引擎

客戶端通過前端拆包的meta文件，進行公共庫離線庫資源版本管理。當客戶端頁面schema中打開引擎預熱的能力時，客戶端會在頁面路由時，根據(jù)meta查找對應(yīng)的引擎版本，提前去預加載游戲引擎。由于離線公共庫存在客戶端本地，為了防止替換客戶端本地引擎JS文件，整體加載過程中會對游戲引擎資源進行驗簽，從而達到避免JS注入攻擊的風險。同時，在跨端容器創(chuàng)建的過程中，將游戲引擎文件在JS線程進行預熱，最終將游戲引擎實例掛載到全局對象上，以確保游戲引擎的正常運行。

當前端業(yè)務(wù)邏輯執(zhí)行時，可以通過全局對象訪問游戲引擎實例。如果引擎預熱失敗，前端業(yè)務(wù)會通過兜底的邏輯，請求游戲引擎資源進行使用，從而提升整體方案的穩(wěn)定性和可靠性。

業(yè)務(wù)收益

在游戲互動場景中，AnnieX互動容器通過提供引擎預熱和依賴資產(chǎn)公共離線庫托管游戲引擎的方案，實現(xiàn)了游戲引擎的快速加載和初始化，從而提升了游戲業(yè)務(wù)的整體性能。這一方案成功地幫助完成了24年抖音春節(jié)活動的落地，游戲主包大小降低了28.05%。通過復用公共離線包引擎資源，節(jié)約了數(shù)萬元網(wǎng)絡(luò)帶寬的成本。

在游戲加載耗時方面，雙端在不同游戲的表現(xiàn)中存在200ms～500ms左右的優(yōu)化幅度。由于iOS整體性能更佳，因此優(yōu)化幅度整體上相較于Android用戶優(yōu)化幅度更大。在Android端中，PCT90有32.12%的優(yōu)化幅度，PCT50有20.75%的優(yōu)化幅度；在iOS端中，PCT90有47.24%，PCT50有33.89%的優(yōu)化幅度。

資源壓縮

業(yè)務(wù)痛點

3D資源往往文件體積較大，在需要網(wǎng)絡(luò)傳輸?shù)膱鼍埃瑢@些資源的壓縮通常能夠有效提升資源的加載速度，節(jié)約網(wǎng)絡(luò)流量傳輸成本。

目前，常用的3D資源文件格式主要有g(shù)lTF、fbx、obj等，這些資源通常包含了3D資源的幾何體、骨骼、動畫、材質(zhì)等等所有數(shù)據(jù)，因此圍繞著24年抖音春節(jié)活動，我們開始了基于游戲3D資源的壓縮和解壓縮的探索和調(diào)研。

整體思路

這里主要介紹AnnieX互動容器對于幾何體和動畫數(shù)據(jù)的壓縮算法及其具體實現(xiàn)方式，分別是：量化（Quantization）、稀疏訪問器（Sparse Accessor）和網(wǎng)格優(yōu)化（meshopt）。

技術(shù)細節(jié)

幾何體的壓縮與解壓縮

在SAR Creator中，幾何體（Geometry）除了包含了頂點的坐標（Position）、紋理坐標（UV）、法向量（Normal）、切向量（Tangent）、顏色（Color）等數(shù)據(jù)之外，還包含了組成三角形的頂點索引（Index）、骨骼（Skeleton）和混合變形（Blend Shape）等數(shù)據(jù)。

由于這些不同的數(shù)據(jù)有著不同的格式和特性，所以往往需要分別應(yīng)用不同的壓縮格式，用以在盡可能保證數(shù)據(jù)精度的同時盡量提高壓縮效率。

這里介紹幾種SAR Creator中使用到的壓縮算法：量化、稀疏訪問器和meshopt。

量化（Quantization）

量化是一種常用的簡單且高效的資源壓縮方式，通常用于頂點數(shù)據(jù)的壓縮，是一種有損壓縮。

量化是將32位浮點值轉(zhuǎn)換為16位或8位的整數(shù)進行存儲的過程，可以達到50%甚至25%的壓縮率。

轉(zhuǎn)換公式

詳情

由上述轉(zhuǎn)換說明易知，量化是一個有損的壓縮，其壓縮和解壓縮均只需要對所有原始數(shù)據(jù)做當且僅當一次乘法/除法運算，算法復雜度為O(n)，開銷較低。

量化對原始浮點數(shù)的范圍有一個前提要求，其范圍必須在0到1之間（可轉(zhuǎn)換到無符號整數(shù)）或-1到1之間（可轉(zhuǎn)換到有符號整數(shù)）。當原始浮點數(shù)的值不在這個范圍內(nèi)的話，需要預先做一次歸一化處理，使其落在需要的范圍內(nèi)，才能繼續(xù)進行量化處理。

本質(zhì)上，量化是建立了一個浮點數(shù)和整數(shù)的對應(yīng)關(guān)系，整數(shù)的存儲位數(shù)越大，對應(yīng)的浮點數(shù)精度越高。理論上可以實現(xiàn)任意位數(shù)的整數(shù)跟浮點數(shù)的轉(zhuǎn)換。

在SAR Creator中，因為不同的數(shù)據(jù)對于精度的要求不同，故在實際應(yīng)用時對于不同類型的數(shù)據(jù)使用了不同位數(shù)的整數(shù)進行存儲，具體如下：

• position：14
• uv：12
• normal：10
• tangent：12
• color：8
• blend shape：8

以上不同類型數(shù)據(jù)的存儲位數(shù)的配置選擇參考自業(yè)界經(jīng)驗，可以在盡量保證數(shù)據(jù)精度的同時提高壓縮率。在對精度要求較高的情況下，可以對該配置進行調(diào)整優(yōu)化，一般最大值不會超過16位。

稀疏訪問器（Sparse Accessor）

這里的稀疏訪問器來自于glTF規(guī)范中的稀疏訪問器（Sparse Accessor），特別適合用來存儲混合變形（BlendShape，以下簡稱BS）數(shù)據(jù)，因為BS數(shù)據(jù)中往往存在較多的“0”。

在glTF規(guī)范中，Sparse Accessor會把一個較大的vector2/3/4的數(shù)組（Buffer），拆分成3個部分：非0值數(shù)組（Values Array）、索引下標數(shù)組（Indices Array）和原始長度值（Count）。通過這樣僅存儲非0值及其下標的方式，結(jié)合一個原始長度，就可以很方便地還原出原始數(shù)據(jù)。

在SAR Creator中會基于glTF的Sparse Accessor的格式再進一步做優(yōu)化調(diào)整，僅會存儲非0的vector2/3/4的非0通道的數(shù)據(jù)，而不是glTF規(guī)范中必須是Vector2/3/4中所有通道的數(shù)據(jù)均為0才不去存儲，這樣可以進一步減少序列化后存儲數(shù)據(jù)的文件體積大小。同時，由于SAR的AssetBundle格式對于數(shù)組存儲采用了特殊的方式，所以這里還可以少存一個Int32的Count值。

轉(zhuǎn)換格式

轉(zhuǎn)換格式示意圖如下：

由上圖可知，稀疏訪問器是無損壓縮，且其壓縮和解壓縮的流程簡單，算法復雜度為O(n)，但實際的解壓縮過程并不需要對所有的數(shù)據(jù)進行處理，只需要創(chuàng)建跟原先相同大小的buffer，按下標將所有的非零值填進去即可，故而開銷很低。

詳情

另外，由于稀疏訪問器僅在當BS數(shù)據(jù)的0值較多時，才會有較高的壓縮效率，否則反而會降低壓縮效率。SAR Creator默認會自動判斷應(yīng)用了稀疏訪問器后是否會減少資源文件體積，來決定是否采用稀疏訪問器，不需要手動開啟。

附：真實業(yè)務(wù)（虛擬形象）中的glTF文件為例，僅采用Sparse Accessor能減少53%左右的文件體積，如果采用Sar的Asset Bundle中優(yōu)化后的數(shù)據(jù)格式，可以減少78%左右的文件體積。

值得一提的是，稀疏訪問器可以跟量化一起疊加同時應(yīng)用在幾何體數(shù)據(jù)上，兩者互不影響，互不沖突，最終的精度損失僅為量化的損失。

網(wǎng)格優(yōu)化（meshopt）

meshopt是glTF規(guī)范中的一個擴展：EXT_meshopt_compression，該擴展可以對glTF文件中的幾何體和動畫數(shù)據(jù)進行優(yōu)化與壓縮。在SAR Creator中，幾乎全量移植了這個擴展的具體實現(xiàn)，使得SAR Creator的Asset Bundle中的幾何體和動畫數(shù)據(jù)同樣支持了meshopt壓縮。

由于meshopt壓縮和解壓縮的算法較為復雜，SAR Creator在實現(xiàn)時應(yīng)用了wasm的方式（同時用asm.js做兜底），這里使用了開源項目meshoptimizer，它提供了對Mesh進行優(yōu)化、壓縮相關(guān)算法的C/C++接口，也可以編譯為wasm使用。

壓縮流程

meshopt在壓縮前需要先優(yōu)化頂點和索引數(shù)據(jù)，用于提高壓縮效率，同時也可以提高解壓縮后的渲染效率（GPU緩存）。meshopt提出了三種不同的模式（mode：attribute、triangles、indices）的和三種不同的過濾器（filter：octahedral、quaternion、exponential），針對不同的數(shù)據(jù)類型應(yīng)用不同的模式和過濾器，可以最大化壓縮率。

對于幾何體的meshopt壓縮，SAR Creator實現(xiàn)時的具體流程如下：

1. 優(yōu)化索引順序

1. 優(yōu)化索引順序，可以最大限度地利用附近的頂點數(shù)據(jù)，從而盡量復用在GPU硬件中的緩存。

2. 優(yōu)化頂點順序

3. 頂點順序應(yīng)按照頂點在索引數(shù)據(jù)中出現(xiàn)的順序進行順序排列，以而可以最大化索引數(shù)據(jù)的壓縮率。

需要注意的是：有時候更高的壓縮率反而會降低渲染效率，需要取好平衡點。

3. 壓縮頂點數(shù)據(jù)

1. 頂點數(shù)據(jù)需要先進行量化（quantized），才能進行后續(xù)的壓縮處理；
2. 量化后的頂點數(shù)據(jù)需要用attributes模式來進行二進制比特流存儲；
3. 對于normal/tangent的數(shù)據(jù)，使用octahedral的filter可以進一步提高壓縮率，對于position或其他數(shù)據(jù)，可以使用exponential的filter進行處理；

4. 壓縮索引數(shù)據(jù)

5. 索引數(shù)據(jù)用indices模式進行存儲，也可以用triangles模式進行存儲；

6. 其中，triangles模式僅支持三角形列表的存儲，indices模式可以支持其他拓撲類型的索引數(shù)據(jù)存儲；

7. 
   

   壓縮BS數(shù)據(jù)

   
   

8. BS數(shù)據(jù)可以完全當作頂點數(shù)據(jù)來進行處理，也需要先進行量化（quantized），之后再以attributes模式進行二進制比特流存儲；

9. BS數(shù)據(jù)因為是增量（relative/delta）的值，故也可以選用比頂點數(shù)據(jù)在量化后更小的比特位來進行存儲；

解壓縮流程

對于幾何體的meshopt解壓縮，則需要反過來進行，互動容器中實現(xiàn)的具體流程如下

1. 解壓縮頂點數(shù)據(jù)

1. 按attributes模式進行解壓縮；
2. 對于采用了對應(yīng)filter的數(shù)據(jù)，還需要再進行filter的解壓縮；
3. （可選）如果有必要，在進行反量化轉(zhuǎn)換（de-quantized）處理;

2. 解壓縮索引數(shù)據(jù)

3. 直接按壓縮時采用的indices或triangles模式進行解壓縮即可；

4. 
   

   解壓縮BS數(shù)據(jù)

   
   

5. 同頂點數(shù)據(jù)的解壓，不再贅述；

詳情

對于幾何體數(shù)據(jù)應(yīng)用meshopt壓縮，往往可以帶來10%-20%的壓縮率，可以極大減少資源體積。但由于其復雜度較高，需要使用wasm加速壓縮和解壓縮的過程。

對于不支持wasm的環(huán)境，SAR Creator使用了asm.js作為兜底方案。實際測試結(jié)果顯示，asm.js會比wasm慢2-4倍。在后續(xù)版本的SAR中，可能會直接使用C++的方案加速運行時對meshopt壓縮后的資源進行解壓縮，加速資源加載和解析的整個流程。

另：SAR Creator對于幾何體數(shù)據(jù)的meshopt壓縮實現(xiàn)，目前仍在feature分支，未經(jīng)過全面測試，僅上線了對于動畫數(shù)據(jù)的meshopt壓縮。

動畫的壓縮與解壓縮

動畫（Animation）數(shù)據(jù)是由一系列的關(guān)鍵幀（keyframe）組成的。所以動畫數(shù)據(jù)是由兩部分組成的：關(guān)鍵幀的時間數(shù)組（times）和關(guān)鍵幀的值數(shù)組（values）。

網(wǎng)格優(yōu)化（meshopt）

SAR Creator中對于動畫（Animation）數(shù)據(jù)的壓縮，也是移植自上述meshopt擴展。

壓縮流程

對于動畫數(shù)據(jù)的meshopt壓縮，SAR Creator實現(xiàn)時的具體流程如下：

1. 對動畫數(shù)據(jù)進行重采樣

1. 對動畫數(shù)據(jù)的壓縮，最有收益的是進行重采樣（resample），這樣可以減少存儲的關(guān)鍵幀數(shù)量，進而減少動畫數(shù)據(jù)的文件存儲體積；
2. 具體實現(xiàn)使用開源庫：keyframe-resample-wasm，它提供了WebAssembly版本的重采樣方式，會比純js的版本快一些，而且這個庫的重采樣過程是無損的。

2. 壓縮關(guān)鍵幀的times數(shù)據(jù)

3. 如果times數(shù)據(jù)是均勻的，僅使用attribute模式而不使用任何過濾器已經(jīng)能取得比較高的壓縮率了；

4. 為了保證最終的動畫不變形，一般不建議對關(guān)鍵幀的times數(shù)據(jù)進行filter處理，也可以繼續(xù)使用具有最大尾數(shù)位數(shù)（23）的exponential過濾器進行處理，從而保證最小的精度損失；

5. 最后使用attributes模式進行存儲；

6. 
   

   壓縮關(guān)鍵幀的values數(shù)據(jù)

   
   

7. 旋轉(zhuǎn)的數(shù)據(jù)可以使用16-bit進行量化處理，并應(yīng)用quaternion過濾器進行處理；

8. 位移和縮放數(shù)據(jù)可以應(yīng)用exponential過濾器應(yīng)用相同的指數(shù)進行處理；

9. 最后使用attributes模式進行存儲；

解壓縮流程

對于動畫數(shù)據(jù)的meshopt解壓縮，互動容器中的實現(xiàn)具體流程如下：

1. 解壓縮關(guān)鍵幀的times數(shù)據(jù)

1. 按attributes模式進行解壓縮；
2. 如果壓縮時采用了exponential的過濾器（filter），還需要再進行exponential的過濾器解壓縮；

2. 解壓縮關(guān)鍵幀的values數(shù)據(jù)

3. 按attributes模式進行解壓縮；

4. 旋轉(zhuǎn)的數(shù)據(jù)還需要用quaternion過濾器進行解壓縮；

5. 位移和縮放數(shù)據(jù)還需要用exponential過濾器進行壓縮時相同指數(shù)的解壓縮；

詳情

對于動畫數(shù)據(jù)的meshopt壓縮，同樣也是有損的，往往有40%左右的壓縮率，同樣采用了wasm的方式加速壓縮和解壓縮的過程。

附：真實業(yè)務(wù)（招財神龍）中的動畫資源文件為例，有38.50%的壓縮率，可以減少1.9MB的資源包體積。

另：招財神龍業(yè)務(wù)中，考慮中低端機在跨端框架下wasm的兼容性問題，開發(fā)時直接默認啟用了asm.js的降級方案，但在后來的性能測試環(huán)節(jié)中發(fā)現(xiàn)meshopt解壓縮的asm.js在iOS的JSC運行時下效率較低，會嚴重增加資源的解析耗時，最終上線時并沒有啟用動畫數(shù)據(jù)的meshopt壓縮。

未來規(guī)劃

24年春節(jié)我們完成了引擎預熱、資產(chǎn)公共離線庫的落地，取得了不錯的游戲優(yōu)化效果。但在業(yè)務(wù)落地的過程中，我們也發(fā)現(xiàn)一些存在的問題，例如引擎預熱邏輯命中率雙端平均只達到81.33%，整體上還存在優(yōu)化的空間；另一方面隨著資產(chǎn)公共離線庫的托管的引擎類型和版本越來越多，體積越來越大，我們需要加強對離線公共庫的版本管理，識別和控制ROI整體較低的引擎和版本，從而更好的控制離線公共庫的帶寬成本。

而在資源壓縮方面，我們完成了相關(guān)方案js和wasm版本的流程的調(diào)研和探索，以24年春節(jié)玩法招財神龍為例，我們?nèi)〉昧瞬诲e的資源體積優(yōu)化效果，降低整體游戲包的大小。但在資源壓縮方面，由于低端機和部分iOS手機上對于網(wǎng)格優(yōu)化的解壓縮效率低下，甚至部分機型適用wasm會有崩潰的情況存在，所以雖然完成了整體的技術(shù)方案落地，但考慮到穩(wěn)定性并沒有在線上啟用。后續(xù)會進一步優(yōu)化這一方面的兼容性問題，解壓的性能問題上也會直接采用C++而非wasm的方案，將資源壓縮方案完整在正式的游戲業(yè)務(wù)落地，同時覆蓋更多的游戲業(yè)務(wù)場景。

另外，在3D游戲場景下，一般意義上的資源還包括圖片、視頻、字體、腳本以及特定編輯器導出的資源（如lottie、spine等），對于這些資源文件的壓縮也有著明顯的意義，我們將在后續(xù)進一步探索相關(guān)資產(chǎn)的壓縮，從而優(yōu)化整體游戲的資產(chǎn)大小。