一、前言

近段時間，我們使用three.js完成了vivo擬我形象的開發(fā)工作，大家可以在vivo賬號中擬制屬于自己的3D形象，也可以保存作為自己的頭像名片。

作為一個3D的項目，從用戶打開頁面到最終模型的渲染需要經(jīng)過多個流程，加載的時間也會比普通的H5項目要更長一些。然而過長的等待時間會造成大量的用戶流失，這部分用戶沒有體驗到具體的功能就退出了頁面非常的遺憾，為了提升首屏加載的轉(zhuǎn)化率，需要盡可能的降低loading的時間。這里就分享一些我們在模型加載優(yōu)化方面的心得。

二、模型加載的優(yōu)化思路

想對加載進行優(yōu)化，首先需要了解Three.js加載模型時的工作流程，并分析出其中耗時的部分進行針對性的處理。

在Three.js中，模型從加載到渲染需要經(jīng)過模型下載、序列化模型、網(wǎng)格解析、寫入緩存和渲染模型幾個步驟，經(jīng)過分析發(fā)現(xiàn)主要的瓶頸在網(wǎng)絡(luò)請求和網(wǎng)格解析兩個部分，所以整體的優(yōu)化思路就是減少網(wǎng)絡(luò)請求資源的體積和提升網(wǎng)格的解析速度。

三、縮小模型的體積

3.1 常見的解決方案

目前主流的壓縮方案是使用google的draco庫對模型進行壓縮。draco的原理類似降低圖片的分辨率，通過減少模型的頂點數(shù)起到壓縮體積的效果。

也就是說draco是一種有損的壓縮方式，這樣就會帶來諸多的問題：

• 可能在網(wǎng)格連接處存在畫面模型撕裂。
• 僅僅壓縮頂點只能將50.7mb的人物模型壓縮到49.5，壓縮效果有限。
• draco前臺decoder在h5中的解算效率不理想，可能節(jié)省下來的網(wǎng)絡(luò)請求時間還沒有增加的數(shù)據(jù)解算的時間長。

基于以上幾點，最終我們放棄了draco的壓縮方案。

使用draco壓縮之后導(dǎo)致的模型撕裂

3.2 進階方案

高端的食材，往往只需要采用最樸素的烹飪方式。經(jīng)過一些嘗試，我們發(fā)現(xiàn)將glb模型直接打成zip包可以明顯的提升模型的壓縮效率。50.7mb的人物模型可以壓縮到11.6mb。

但是Three.js提供的gltfloader是不能直接加載zip文件的，于是我們需要對其進行功能擴展。

Three.js加載gltf模型是首先通過fetch請求獲取到模型的arraybuffer，再對arraybuffer進行格式化。所以我們只需要在模型格式化之前攔截zip文件進行解壓縮即可。

于是我們使用jszip，資源加載完成后判斷資源的后綴，如果是zip文件就使用jszip進行解壓縮。

看起來還不錯，在保證視覺效果的同時又可以大幅壓縮模型的體積，那么有沒有可能做的再極致一些呢？

既然是針對性的場景，我們就可以從解壓縮的解算開始入手，于是我們使用rust寫了一個解壓工具，將其轉(zhuǎn)換成wasm包代替jszip，可以發(fā)現(xiàn)wasm的冷啟動性能確實要比js好很多，可以將解壓的時長從幾十到100毫秒降低到1毫秒左右，適合體積比較小的解壓縮場景。

四、文件的加解密

作為一個h5項目，獲取到靜態(tài)資源的鏈接并不困難，所以需要對模型文件進行一點點加密，讓破解起來沒有那么容易。同時解密的過程不能顯著延長資源加載的時間，影響用戶體驗。

基于數(shù)據(jù)解密的效率，我們可以截取文件buffer的一部分進行加密，而不對全文進行加密，同時將數(shù)據(jù)解密的過程也放到wasm中，提升解算效率的同時也增強了安全性。采用對稱加密的算法，同一個方法既可以用于加密，也可以用于解密。

按照模型加載的流程，解密的操作應(yīng)該放在解壓縮之后，序列化之前，那么如何判斷數(shù)據(jù)是否進行了加密呢，可以通過判斷解壓數(shù)據(jù)decode以后是否有g(shù)lTF的標(biāo)記來確定。

如下圖，數(shù)據(jù)解密的耗時幾乎可以忽略不計，可以放心使用。

五、如何優(yōu)化首幀的渲染體驗

優(yōu)化完模型的加載，繼續(xù)來優(yōu)化模型的渲染，在加載一個體積比較大的模型的時候經(jīng)常會有頁面的卡死的情況出現(xiàn)，需要從兩方面治標(biāo)也治本的進行優(yōu)化：

1. 通過減少頁面的卡停來優(yōu)化用戶的感官體驗。
2. 通過縮短首屏渲染的時長來解決根本問題。

5.1 減少頁面的卡停

在模型加載的時候通常會設(shè)置一個loading頁面來展示當(dāng)前的加載進度，同時loading頁也可以播放一些動效或者互動來讓用戶等待的過程中不那么無聊。但是由于js單線程的特性，在進行首幀渲染的時候任何事件都不無法響應(yīng)，會讓用戶誤以為頁面卡死，造成流失。

為了解決這個問題我們可以使用分步加載的方案，在模型加載的時候先遍歷第一層網(wǎng)格，將所有的網(wǎng)格隱藏起來，然后循環(huán)這些網(wǎng)格，每展示一個就執(zhí)行一次render方法，這樣就可以把一個大的卡頓分散成多個小的，不至于影響前臺的體驗。

但是這樣的方法只能讓用戶感受起來沒那么卡頓，該等的時間一點沒少，過長的等待時間還是會讓用戶等的不耐煩，有沒有其他解決卡頓的方式呢？這就要從Three.js的渲染邏輯來進行分析了。

5.2 縮短首幀渲染的時間

由于我們做的是一個捏臉的項目，通過形態(tài)鍵來實現(xiàn)不同的臉型，表情等表現(xiàn)。在Three.js中存儲形態(tài)鍵信息的屬性在geometry.morphAttributes中，形態(tài)鍵存放的頂點信息總數(shù)與網(wǎng)格的頂點數(shù)相同，這就意味著同一個模型有多少個形態(tài)鍵，就額外需要加載多少套網(wǎng)格的頂點信息。在首次渲染的時候Three.js會遍歷每一個形態(tài)鍵的頂點信息，生成一個float32array，而這個巨量的遍歷操作就是造成卡頓的根本原因。

如何解決這個循環(huán)黑洞呢，我想到了steamdeck上的著色器預(yù)緩存，通過將著色器編譯的結(jié)果進行持久化，縮短頁面加載的時間。那么我們只要將每一個網(wǎng)格的形態(tài)鍵編譯的結(jié)果儲存起來就行了。

/three/src/renderers/webgl/WebGLMorphtargets.js

通過這種方式成功的將首幀渲染的時間從7秒縮短到0.6秒，大幅的提升了用戶的體驗。

講到這里，大家可能發(fā)現(xiàn)了，雖然首幀渲染的時長縮短了，但是形態(tài)鍵緩存的資源有80mb，壓縮后也有15mb，這塊的時長可不可以繼續(xù)壓榨呢，先看一下資源的處理流程，處理解壓后的文件需要將文件解析成JSON字符串，然后在轉(zhuǎn)換成float32array，這里耗時最大的點就是JSON.parse的操作，有沒有更好的方式處理呢，可以將這部分內(nèi)容丟到rust里面，平均可以減少0.5s的時間。

六、總結(jié)與規(guī)劃

以上就是我們的優(yōu)化流程，將glb模型文件壓縮成zip包，配合前臺wasm解壓工具降低模型的加載時間。通過增加形態(tài)鍵緩存的方式來降低首幀渲染的時長。

經(jīng)過這一系列的操作，成功的將模型的體積從50mb壓縮到11mb，增加了額外80mb的形態(tài)鍵緩存也可以使用zip壓縮到15mb，處理后頁面的首次加載時長從15秒縮短到5秒，算是一個不小的提升。

然而，我們也意識到還有進一步的優(yōu)化空間，譬如目前雖然有了形態(tài)鍵緩存，但是原模型中的形態(tài)鍵信息還存儲在模型中，這一部分的信息不需要被threejs讀取，卻很大的占用了模型的體積，后續(xù)可以開發(fā)一個gltf-pipeline類似的處理工具，將形態(tài)鍵緩存直接整合進gltf模型中，同時把整個模型的序列化工作放到wasm中處理，降低模型的尺寸的同時也可以減少模型解析的時長。期待為大家?guī)砀玫氖褂皿w驗。