作者：來(lái)自 vivo 互聯(lián)網(wǎng)前端團(tuán)隊(duì)- Su Ning

作為一個(gè)3D的項(xiàng)目，從用戶(hù)打開(kāi)頁(yè)面到最終模型的渲染需要經(jīng)過(guò)多個(gè)流程，加載的時(shí)間也會(huì)比普通的H5項(xiàng)目要更長(zhǎng)一些，從而造成大量的用戶(hù)流失。為了提升首屏加載的轉(zhuǎn)化率，需要盡可能的降低loading的時(shí)間。這里就分享一些我們?cè)谀Ｐ图虞d優(yōu)化方面的心得。

一、前言

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

作為一個(gè)3D的項(xiàng)目，從用戶(hù)打開(kāi)頁(yè)面到最終模型的渲染需要經(jīng)過(guò)多個(gè)流程，加載的時(shí)間也會(huì)比普通的H5項(xiàng)目要更長(zhǎng)一些。然而過(guò)長(zhǎng)的等待時(shí)間會(huì)造成大量的用戶(hù)流失，這部分用戶(hù)沒(méi)有體驗(yàn)到具體的功能就退出了頁(yè)面非常的遺憾，為了提升首屏加載的轉(zhuǎn)化率，需要盡可能的降低loading的時(shí)間。這里就分享一些我們?cè)谀Ｐ图虞d優(yōu)化方面的心得。

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

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

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

三、縮小模型的體積

3.1 常見(jiàn)的解決方案

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

也就是說(shuō)draco是一種有損的壓縮方式，這樣就會(huì)帶來(lái)諸多的問(wèn)題：

• 可能在網(wǎng)格連接處存在畫(huà)面模型撕裂。

• 僅僅壓縮頂點(diǎn)只能將50.7mb的人物模型壓縮到49.5，壓縮效果有限。

• draco前臺(tái)decoder在h5中的解算效率不理想，可能節(jié)省下來(lái)的網(wǎng)絡(luò)請(qǐng)求時(shí)間還沒(méi)有增加的數(shù)據(jù)解算的時(shí)間長(zhǎng)。

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

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

3.2 進(jìn)階方案

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

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

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

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

看起來(lái)還不錯(cuò)，在保證視覺(jué)效果的同時(shí)又可以大幅壓縮模型的體積，那么有沒(méi)有可能做的再極致一些呢？

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

四、文件的加解密

作為一個(gè)h5項(xiàng)目，獲取到靜態(tài)資源的鏈接并不困難，所以需要對(duì)模型文件進(jìn)行一點(diǎn)點(diǎn)加密，讓破解起來(lái)沒(méi)有那么容易。同時(shí)解密的過(guò)程不能顯著延長(zhǎng)資源加載的時(shí)間，影響用戶(hù)體驗(yàn)。

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

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

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

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

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

1. 通過(guò)減少頁(yè)面的卡停來(lái)優(yōu)化用戶(hù)的感官體驗(yàn)。

2. 通過(guò)縮短首屏渲染的時(shí)長(zhǎng)來(lái)解決根本問(wèn)題。

5.1 減少頁(yè)面的卡停

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

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

但是這樣的方法只能讓用戶(hù)感受起來(lái)沒(méi)那么卡頓，該等的時(shí)間一點(diǎn)沒(méi)少，過(guò)長(zhǎng)的等待時(shí)間還是會(huì)讓用戶(hù)等的不耐煩，有沒(méi)有其他解決卡頓的方式呢？這就要從Three.js的渲染邏輯來(lái)進(jìn)行分析了。

5.2 縮短首幀渲染的時(shí)間

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

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

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

通過(guò)這種方式成功的將首幀渲染的時(shí)間從7秒縮短到0.6秒，大幅的提升了用戶(hù)的體驗(yàn)。

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

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

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

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

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

轉(zhuǎn)自https://www.cnblogs.com/vivotech/p/18311240