2024 抖音歡笑中國年之AnnieX互動容器創新玩法解析
業務背景
AnnieX作為字節一方游戲統一容器，服務字節內部電商、直播、UG等跨端場景業務。在字節一方游戲互動場景，有大量的一方游戲業務對容器有特定的流量、端能力和游戲優化的訴求。因此我們不斷深入互動游戲業務特點，為字節游戲提供完善游戲端能力和流量運營能力，同時提供游戲互動場景極致優化能力，提升游戲業務的整體性能。
養羊賺錢
種樹賺錢
萌寵旅行家
新周中/周末
今年是抖音春節活動的第7年，我們跨端容器已經具備豐富的端能力的同時，也提供了一些對于跨端容器常規的一些優化手段，例如：資源預加載、網絡預請求等手段，并且在往年春節活動中取得了不錯的優化效果。而今年，我們希望能夠基于游戲場景，逐漸深挖游戲互動場景的特點，為春節等游戲場景去提供更加豐富和專業的游戲優化能力。
春節-神龍尋寶
春節-守衛現金
春節-搖福簽
春節-神龍探寶
互動套件介紹
因此我們基于24年抖音春節活動，在容器側提出了互動套件的建設，希望為游戲互動場景提供優化解決方案。24年春節我們完成游戲引擎預熱和游戲資產公共離線庫的相關優化，在24年春節得到了不錯的優化效果；同時我們完成了游戲資源（解）壓縮的探索和更高效的物理引擎探索，希望能夠在25年春節完成壓縮和物理引擎的落地，從而豐富游戲互動玩法的同時，提升游戲的整體性能。
資產離線公共庫是一個重要的資源管理工具，管理了游戲互動業務所需要的游戲引擎資源。通過對游戲主包拆包和引擎資源的統一管理，資產離線公共庫能夠有效地幫助降低游戲包的大小，從而提高游戲的運行效率。此外，資產離線公共庫還能夠通過復用本地離線公共庫的引擎版本，進一步降低游戲包下載的整體耗時和帶寬成本。
引擎預熱是一種提供了與游戲引擎優化相關的能力的技術。其原理是在游戲啟動過程中，對游戲引擎進行預熱，以便游戲邏輯執行過程中更快地加載游戲引擎包，從而提高游戲加載速度。通過提前準備游戲引擎，在游戲啟動時，就可以更快地進入游戲世界，減少等待時間。這種技術可以為玩家帶來更好的游戲體驗。
資源的壓縮與解壓縮可以極大地提高資源利用率，有效降低資源包體積和網絡加載時長。資源的壓縮處理是在引擎編輯器的打包構建階段做的資源預處理，而資源的解壓縮則被放在了互動容器中，在游戲載入過程中實時進行處理。
物理引擎，目前前端游戲開發者主要依賴js或者wasm版本的物理引擎，在游戲性能和體驗上存在較大的優化空間，因此我們探索在容器側提供更高效的物理引擎方案，從而為游戲開發者和設計師提供更好的物理引擎解決方案，豐富游戲互動玩法體驗。
本文主要介紹24年在春節場景落地的引擎預熱和資產公共離線庫相關的優化手段。同時介紹、探討我們游戲資源（解）壓縮方案的探索和在探索中遇到的問題。
名詞解釋
引擎預熱&資產離線公共庫
業務痛點
基于游戲業務已有的數據進行分析，我們發現游戲互動場景有以下2個特點：
- 依賴游戲引擎：在游戲中，游戲互動場景的創建和運行需要依賴于游戲引擎的加載和初始化邏輯。這個過程會消耗大約200ms～300ms的時間，這可能會對游戲的性能產生一定的影響。因此，為了提高游戲的響應速度和流暢度，游戲開發者需要盡可能地優化引擎加載和初始化邏輯的執行效率。
- 游戲加載耗時和用戶異常流失率呈正比：啟動性能對于游戲的用戶體驗至關重要，因為如果游戲啟動沒有優化好，用戶需要等待很長時間才能看到游戲畫面。這樣很可能會導致許多用戶在游戲加載完成之前就退出游戲。根據已有的游戲數據分析，游戲加載時間在1.5秒后，每0.5秒左右就會有4%左右的用戶異常流失。因此，游戲開發者需要高度重視游戲啟動性能的優化，以確保游戲能夠快速啟動，讓用戶盡快進入游戲世界。
因此我們針對游戲互動場景完成了引擎預熱的方案，整體在24年春節場景落地，雙端取得了不錯的加載收益。
整體思路
在優化之前，在容器加載游戲主包完成之后，才會開始渲染游戲首屏頁面和執行游戲業務邏輯。當游戲的業務邏輯在執行的過程中，必須等待容器完成游戲引擎資源的加載和初始化，這部分在線上存在一定的耗時。因此，為了解決這個問題，我們在容器側和前端工具鏈完成了一系列改造，以提高游戲頁面的加載速度。
具體地來說我們在容器打開游戲頁面路由階段，就完成了游戲引擎的預加載，并在跨端框架完成初始化之后，充分利用JS線程空閑的時間，完成游戲引擎的預熱，并將預熱好的實例掛載在全局對象中，這樣當游戲頁面真正執行的時候，就能直接通過全局對象中的獲取到游戲引擎實例，從而完成后續的游戲業務邏輯。
技術細節
開發工具鏈改造
前端工具鏈方面，在構建工具中接入speedy-split-chunks插件，在游戲打包的過程中，將游戲引擎包從游戲主包中拆分出去，并將引擎庫發布到靜態資源分發平臺公共離線庫下；封裝split-engine-adapter組件，完成引擎預熱的前端代碼插樁，并在引擎預熱時，提供兜底邏輯，保障業務的穩定性。在剔除游戲引擎包同時，并將剔除出來的引擎包和對應的meta文件部署到靜態資源分發平臺公共離線庫，通過meta文件來維護離線公共庫的游戲引擎資源版本，供多個游戲互動業務使用，從而降低帶寬成本。
另一方面，我們的split-engine-adapter插件可以在請求加載引擎資源文件時，完成對requireModule函數的hook。在這個過程中，如果發現全局對象上不存在的引擎實例，那么就會通過requireModule請求拆包引擎包作為兜底措施。通過這種方式，可以避免因引擎實例不存在而導致的錯誤，從而提高系統的穩定性和可靠性。
預熱游戲引擎
客戶端通過前端拆包的meta文件，進行公共庫離線庫資源版本管理。當客戶端頁面schema中打開引擎預熱的能力時，客戶端會在頁面路由時，根據meta查找對應的引擎版本，提前去預加載游戲引擎。由于離線公共庫存在客戶端本地，為了防止替換客戶端本地引擎JS文件，整體加載過程中會對游戲引擎資源進行驗簽，從而達到避免JS注入攻擊的風險。同時，在跨端容器創建的過程中，將游戲引擎文件在JS線程進行預熱，最終將游戲引擎實例掛載到全局對象上，以確保游戲引擎的正常運行。
當前端業務邏輯執行時，可以通過全局對象訪問游戲引擎實例。如果引擎預熱失敗，前端業務會通過兜底的邏輯，請求游戲引擎資源進行使用，從而提升整體方案的穩定性和可靠性。
業務收益
在游戲互動場景中，AnnieX互動容器通過提供引擎預熱和依賴資產公共離線庫托管游戲引擎的方案，實現了游戲引擎的快速加載和初始化，從而提升了游戲業務的整體性能。這一方案成功地幫助完成了24年抖音春節活動的落地，游戲主包大小降低了28.05%。通過復用公共離線包引擎資源，節約了數萬元網絡帶寬的成本。
在游戲加載耗時方面，雙端在不同游戲的表現中存在200ms～500ms左右的優化幅度。由于iOS整體性能更佳，因此優化幅度整體上相較于Android用戶優化幅度更大。在Android端中，PCT90有32.12%的優化幅度，PCT50有20.75%的優化幅度；在iOS端中，PCT90有47.24%，PCT50有33.89%的優化幅度。
資源壓縮
業務痛點
3D資源往往文件體積較大，在需要網絡傳輸的場景，對這些資源的壓縮通常能夠有效提升資源的加載速度，節約網絡流量傳輸成本。
目前，常用的3D資源文件格式主要有glTF、fbx、obj等，這些資源通常包含了3D資源的幾何體、骨骼、動畫、材質等等所有數據，因此圍繞著24年抖音春節活動，我們開始了基于游戲3D資源的壓縮和解壓縮的探索和調研。
整體思路
這里主要介紹AnnieX互動容器對于幾何體和動畫數據的壓縮算法及其具體實現方式，分別是：量化（Quantization）、稀疏訪問器（Sparse Accessor）和網格優化（meshopt）。
技術細節
幾何體的壓縮與解壓縮
在SAR Creator中，幾何體（Geometry）除了包含了頂點的坐標（Position）、紋理坐標（UV）、法向量（Normal）、切向量（Tangent）、顏色（Color）等數據之外，還包含了組成三角形的頂點索引（Index）、骨骼（Skeleton）和混合變形（Blend Shape）等數據。
由于這些不同的數據有著不同的格式和特性，所以往往需要分別應用不同的壓縮格式，用以在盡可能保證數據精度的同時盡量提高壓縮效率。
這里介紹幾種SAR Creator中使用到的壓縮算法：量化、稀疏訪問器和meshopt。
量化（Quantization）
量化是一種常用的簡單且高效的資源壓縮方式，通常用于頂點數據的壓縮，是一種有損壓縮。
量化是將32位浮點值轉換為16位或8位的整數進行存儲的過程，可以達到50%甚至25%的壓縮率。
轉換公式
詳情
由上述轉換說明易知，量化是一個有損的壓縮，其壓縮和解壓縮均只需要對所有原始數據做當且僅當一次乘法/除法運算，算法復雜度為O(n)，開銷較低。
量化對原始浮點數的范圍有一個前提要求，其范圍必須在0到1之間（可轉換到無符號整數）或-1到1之間（可轉換到有符號整數）。當原始浮點數的值不在這個范圍內的話，需要預先做一次歸一化處理，使其落在需要的范圍內，才能繼續進行量化處理。
本質上，量化是建立了一個浮點數和整數的對應關系，整數的存儲位數越大，對應的浮點數精度越高。理論上可以實現任意位數的整數跟浮點數的轉換。
在SAR Creator中，因為不同的數據對于精度的要求不同，故在實際應用時對于不同類型的數據使用了不同位數的整數進行存儲，具體如下：
- position：14
- uv：12
- normal：10
- tangent：12
- color：8
- blend shape：8
以上不同類型數據的存儲位數的配置選擇參考自業界經驗，可以在盡量保證數據精度的同時提高壓縮率。在對精度要求較高的情況下，可以對該配置進行調整優化，一般最大值不會超過16位。
稀疏訪問器（Sparse Accessor）
這里的稀疏訪問器來自于glTF規范中的稀疏訪問器（Sparse Accessor），特別適合用來存儲混合變形（BlendShape，以下簡稱BS）數據，因為BS數據中往往存在較多的“0”。
在glTF規范中，Sparse Accessor會把一個較大的vector2/3/4的數組（Buffer），拆分成3個部分：非0值數組（Values Array）、索引下標數組（Indices Array）和原始長度值（Count）。通過這樣僅存儲非0值及其下標的方式，結合一個原始長度，就可以很方便地還原出原始數據。
在SAR Creator中會基于glTF的Sparse Accessor的格式再進一步做優化調整，僅會存儲非0的vector2/3/4的非0通道的數據，而不是glTF規范中必須是Vector2/3/4中所有通道的數據均為0才不去存儲，這樣可以進一步減少序列化后存儲數據的文件體積大小。同時，由于SAR的AssetBundle格式對于數組存儲采用了特殊的方式，所以這里還可以少存一個Int32的Count值。
轉換格式
轉換格式示意圖如下：
由上圖可知，稀疏訪問器是無損壓縮，且其壓縮和解壓縮的流程簡單，算法復雜度為O(n)，但實際的解壓縮過程并不需要對所有的數據進行處理，只需要創建跟原先相同大小的buffer，按下標將所有的非零值填進去即可，故而開銷很低。
詳情
另外，由于稀疏訪問器僅在當BS數據的0值較多時，才會有較高的壓縮效率，否則反而會降低壓縮效率。SAR Creator默認會自動判斷應用了稀疏訪問器后是否會減少資源文件體積，來決定是否采用稀疏訪問器，不需要手動開啟。
附：真實業務（虛擬形象）中的glTF文件為例，僅采用Sparse Accessor能減少53%左右的文件體積，如果采用Sar的Asset Bundle中優化后的數據格式，可以減少78%左右的文件體積。
值得一提的是，稀疏訪問器可以跟量化一起疊加同時應用在幾何體數據上，兩者互不影響，互不沖突，最終的精度損失僅為量化的損失。
網格優化（meshopt）
meshopt是glTF規范中的一個擴展：EXT_meshopt_compression，該擴展可以對glTF文件中的幾何體和動畫數據進行優化與壓縮。在SAR Creator中，幾乎全量移植了這個擴展的具體實現，使得SAR Creator的Asset Bundle中的幾何體和動畫數據同樣支持了meshopt壓縮。
由于meshopt壓縮和解壓縮的算法較為復雜，SAR Creator在實現時應用了wasm的方式（同時用asm.js做兜底），這里使用了開源項目meshoptimizer，它提供了對Mesh進行優化、壓縮相關算法的C/C++接口，也可以編譯為wasm使用。
壓縮流程
meshopt在壓縮前需要先優化頂點和索引數據，用于提高壓縮效率，同時也可以提高解壓縮后的渲染效率（GPU緩存）。meshopt提出了三種不同的模式（mode：attribute、triangles、indices）的和三種不同的過濾器（filter：octahedral、quaternion、exponential），針對不同的數據類型應用不同的模式和過濾器，可以最大化壓縮率。
對于幾何體的meshopt壓縮，SAR Creator實現時的具體流程如下：
- 優化索引順序
- 優化索引順序，可以最大限度地利用附近的頂點數據，從而盡量復用在GPU硬件中的緩存。
- 優化頂點順序
頂點順序應按照頂點在索引數據中出現的順序進行順序排列，以而可以最大化索引數據的壓縮率。
需要注意的是：有時候更高的壓縮率反而會降低渲染效率，需要取好平衡點。
- 壓縮頂點數據
- 頂點數據需要先進行量化（quantized），才能進行后續的壓縮處理；
- 量化后的頂點數據需要用attributes模式來進行二進制比特流存儲；
- 對于normal/tangent的數據，使用octahedral的filter可以進一步提高壓縮率，對于position或其他數據，可以使用exponential的filter進行處理；
- 壓縮索引數據
索引數據用indices模式進行存儲，也可以用triangles模式進行存儲；
其中，triangles模式僅支持三角形列表的存儲，indices模式可以支持其他拓撲類型的索引數據存儲；
壓縮BS數據
BS數據可以完全當作頂點數據來進行處理，也需要先進行量化（quantized），之后再以attributes模式進行二進制比特流存儲；
BS數據因為是增量（relative/delta）的值，故也可以選用比頂點數據在量化后更小的比特位來進行存儲；
解壓縮流程
對于幾何體的meshopt解壓縮，則需要反過來進行，互動容器中實現的具體流程如下
- 解壓縮頂點數據
- 按attributes模式進行解壓縮；
- 對于采用了對應filter的數據，還需要再進行filter的解壓縮；
- （可選）如果有必要，在進行反量化轉換（de-quantized）處理;
- 解壓縮索引數據
直接按壓縮時采用的indices或triangles模式進行解壓縮即可；
解壓縮BS數據
同頂點數據的解壓，不再贅述；
詳情
對于幾何體數據應用meshopt壓縮，往往可以帶來10%-20%的壓縮率，可以極大減少資源體積。但由于其復雜度較高，需要使用wasm加速壓縮和解壓縮的過程。
對于不支持wasm的環境，SAR Creator使用了asm.js作為兜底方案。實際測試結果顯示，asm.js會比wasm慢2-4倍。在后續版本的SAR中，可能會直接使用C++的方案加速運行時對meshopt壓縮后的資源進行解壓縮，加速資源加載和解析的整個流程。
另：SAR Creator對于幾何體數據的meshopt壓縮實現，目前仍在feature分支，未經過全面測試，僅上線了對于動畫數據的meshopt壓縮。
動畫的壓縮與解壓縮
動畫（Animation）數據是由一系列的關鍵幀（keyframe）組成的。所以動畫數據是由兩部分組成的：關鍵幀的時間數組（times）和關鍵幀的值數組（values）。
網格優化（meshopt）
SAR Creator中對于動畫（Animation）數據的壓縮，也是移植自上述meshopt擴展。
壓縮流程
對于動畫數據的meshopt壓縮，SAR Creator實現時的具體流程如下：
- 對動畫數據進行重采樣
- 對動畫數據的壓縮，最有收益的是進行重采樣（resample），這樣可以減少存儲的關鍵幀數量，進而減少動畫數據的文件存儲體積；
- 具體實現使用開源庫：keyframe-resample-wasm，它提供了WebAssembly版本的重采樣方式，會比純js的版本快一些，而且這個庫的重采樣過程是無損的。
- 壓縮關鍵幀的times數據
如果times數據是均勻的，僅使用attribute模式而不使用任何過濾器已經能取得比較高的壓縮率了；
為了保證最終的動畫不變形，一般不建議對關鍵幀的times數據進行filter處理，也可以繼續使用具有最大尾數位數（23）的exponential過濾器進行處理，從而保證最小的精度損失；
最后使用attributes模式進行存儲；
壓縮關鍵幀的values數據
旋轉的數據可以使用16-bit進行量化處理，并應用quaternion過濾器進行處理；
位移和縮放數據可以應用exponential過濾器應用相同的指數進行處理；
最后使用attributes模式進行存儲；
解壓縮流程
對于動畫數據的meshopt解壓縮，互動容器中的實現具體流程如下：
- 解壓縮關鍵幀的times數據
- 按attributes模式進行解壓縮；
- 如果壓縮時采用了exponential的過濾器（filter），還需要再進行exponential的過濾器解壓縮；
- 解壓縮關鍵幀的values數據
按attributes模式進行解壓縮；
旋轉的數據還需要用quaternion過濾器進行解壓縮；
位移和縮放數據還需要用exponential過濾器進行壓縮時相同指數的解壓縮；
詳情
對于動畫數據的meshopt壓縮，同樣也是有損的，往往有40%左右的壓縮率，同樣采用了wasm的方式加速壓縮和解壓縮的過程。
附：真實業務（招財神龍）中的動畫資源文件為例，有38.50%的壓縮率，可以減少1.9MB的資源包體積。
另：招財神龍業務中，考慮中低端機在跨端框架下wasm的兼容性問題，開發時直接默認啟用了asm.js的降級方案，但在后來的性能測試環節中發現meshopt解壓縮的asm.js在iOS的JSC運行時下效率較低，會嚴重增加資源的解析耗時，最終上線時并沒有啟用動畫數據的meshopt壓縮。
未來規劃
24年春節我們完成了引擎預熱、資產公共離線庫的落地，取得了不錯的游戲優化效果。但在業務落地的過程中，我們也發現一些存在的問題，例如引擎預熱邏輯命中率雙端平均只達到81.33%，整體上還存在優化的空間；另一方面隨著資產公共離線庫的托管的引擎類型和版本越來越多，體積越來越大，我們需要加強對離線公共庫的版本管理，識別和控制ROI整體較低的引擎和版本，從而更好的控制離線公共庫的帶寬成本。
而在資源壓縮方面，我們完成了相關方案js和wasm版本的流程的調研和探索，以24年春節玩法招財神龍為例，我們取得了不錯的資源體積優化效果，降低整體游戲包的大小。但在資源壓縮方面，由于低端機和部分iOS手機上對于網格優化的解壓縮效率低下，甚至部分機型適用wasm會有崩潰的情況存在，所以雖然完成了整體的技術方案落地，但考慮到穩定性并沒有在線上啟用。后續會進一步優化這一方面的兼容性問題，解壓的性能問題上也會直接采用C++而非wasm的方案，將資源壓縮方案完整在正式的游戲業務落地，同時覆蓋更多的游戲業務場景。
另外，在3D游戲場景下，一般意義上的資源還包括圖片、視頻、字體、腳本以及特定編輯器導出的資源（如lottie、spine等），對于這些資源文件的壓縮也有著明顯的意義，我們將在后續進一步探索相關資產的壓縮，從而優化整體游戲的資產大小。
