K60 Pro官方停產(chǎn) 第三方瞬間漲價
雖然沒有官方宣布，但Redmi的一些高管也已經(jīng)透露了，Redmi K60 Pro已經(jīng)停產(chǎn)且不會補(bǔ)貨，這一切都是為了即將到來的K60 Ultra鋪路，屬于廠家的正常操作。但有意思的是該機(jī)在停產(chǎn)之后
近段時間，我們使用three.js完成了vivo擬我形象的開發(fā)工作，大家可以在vivo賬號中擬制屬于自己的3D形象，也可以保存作為自己的頭像名片。
作為一個3D的項目，從用戶打開頁面到最終模型的渲染需要經(jīng)過多個流程，加載的時間也會比普通的H5項目要更長一些。然而過長的等待時間會造成大量的用戶流失，這部分用戶沒有體驗到具體的功能就退出了頁面非常的遺憾，為了提升首屏加載的轉(zhuǎn)化率，需要盡可能的降低loading的時間。這里就分享一些我們在模型加載優(yōu)化方面的心得。
想對加載進(jìn)行優(yōu)化，首先需要了解Three.js加載模型時的工作流程，并分析出其中耗時的部分進(jìn)行針對性的處理。
在Three.js中，模型從加載到渲染需要經(jīng)過模型下載、序列化模型、網(wǎng)格解析、寫入緩存和渲染模型幾個步驟，經(jīng)過分析發(fā)現(xiàn)主要的瓶頸在網(wǎng)絡(luò)請求和網(wǎng)格解析兩個部分，所以整體的優(yōu)化思路就是減少網(wǎng)絡(luò)請求資源的體積和提升網(wǎng)格的解析速度。
目前主流的壓縮方案是使用google的draco庫對模型進(jìn)行壓縮。draco的原理類似降低圖片的分辨率，通過減少模型的頂點數(shù)起到壓縮體積的效果。
也就是說draco是一種有損的壓縮方式，這樣就會帶來諸多的問題：
基于以上幾點，最終我們放棄了draco的壓縮方案。
使用draco壓縮之后導(dǎo)致的模型撕裂
高端的食材，往往只需要采用最樸素的烹飪方式。經(jīng)過一些嘗試，我們發(fā)現(xiàn)將glb模型直接打成zip包可以明顯的提升模型的壓縮效率。50.7mb的人物模型可以壓縮到11.6mb。
但是Three.js提供的gltfloader是不能直接加載zip文件的，于是我們需要對其進(jìn)行功能擴(kuò)展。
Three.js加載gltf模型是首先通過fetch請求獲取到模型的arraybuffer，再對arraybuffer進(jìn)行格式化。所以我們只需要在模型格式化之前攔截zip文件進(jìn)行解壓縮即可。
于是我們使用jszip，資源加載完成后判斷資源的后綴，如果是zip文件就使用jszip進(jìn)行解壓縮。
看起來還不錯，在保證視覺效果的同時又可以大幅壓縮模型的體積，那么有沒有可能做的再極致一些呢？
既然是針對性的場景，我們就可以從解壓縮的解算開始入手，于是我們使用rust寫了一個解壓工具，將其轉(zhuǎn)換成wasm包代替jszip，可以發(fā)現(xiàn)wasm的冷啟動性能確實要比js好很多，可以將解壓的時長從幾十到100毫秒降低到1毫秒左右，適合體積比較小的解壓縮場景。
作為一個h5項目，獲取到靜態(tài)資源的鏈接并不困難，所以需要對模型文件進(jìn)行一點點加密，讓破解起來沒有那么容易。同時解密的過程不能顯著延長資源加載的時間，影響用戶體驗。
基于數(shù)據(jù)解密的效率，我們可以截取文件buffer的一部分進(jìn)行加密，而不對全文進(jìn)行加密，同時將數(shù)據(jù)解密的過程也放到wasm中，提升解算效率的同時也增強(qiáng)了安全性。采用對稱加密的算法，同一個方法既可以用于加密，也可以用于解密。
按照模型加載的流程，解密的操作應(yīng)該放在解壓縮之后，序列化之前，那么如何判斷數(shù)據(jù)是否進(jìn)行了加密呢，可以通過判斷解壓數(shù)據(jù)decode以后是否有g(shù)lTF的標(biāo)記來確定。
如下圖，數(shù)據(jù)解密的耗時幾乎可以忽略不計，可以放心使用。
優(yōu)化完模型的加載，繼續(xù)來優(yōu)化模型的渲染，在加載一個體積比較大的模型的時候經(jīng)常會有頁面的卡死的情況出現(xiàn)，需要從兩方面治標(biāo)也治本的進(jìn)行優(yōu)化：
在模型加載的時候通常會設(shè)置一個loading頁面來展示當(dāng)前的加載進(jìn)度，同時loading頁也可以播放一些動效或者互動來讓用戶等待的過程中不那么無聊。但是由于js單線程的特性，在進(jìn)行首幀渲染的時候任何事件都不無法響應(yīng)，會讓用戶誤以為頁面卡死，造成流失。
為了解決這個問題我們可以使用分步加載的方案，在模型加載的時候先遍歷第一層網(wǎng)格，將所有的網(wǎng)格隱藏起來，然后循環(huán)這些網(wǎng)格，每展示一個就執(zhí)行一次render方法，這樣就可以把一個大的卡頓分散成多個小的，不至于影響前臺的體驗。
但是這樣的方法只能讓用戶感受起來沒那么卡頓，該等的時間一點沒少，過長的等待時間還是會讓用戶等的不耐煩，有沒有其他解決卡頓的方式呢？這就要從Three.js的渲染邏輯來進(jìn)行分析了。
由于我們做的是一個捏臉的項目，通過形態(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é)果進(jìn)行持久化，縮短頁面加載的時間。那么我們只要將每一個網(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的時間。
以上就是我們的優(yōu)化流程，將glb模型文件壓縮成zip包，配合前臺wasm解壓工具降低模型的加載時間。通過增加形態(tài)鍵緩存的方式來降低首幀渲染的時長。
經(jīng)過這一系列的操作，成功的將模型的體積從50mb壓縮到11mb，增加了額外80mb的形態(tài)鍵緩存也可以使用zip壓縮到15mb，處理后頁面的首次加載時長從15秒縮短到5秒，算是一個不小的提升。
然而，我們也意識到還有進(jìn)一步的優(yōu)化空間，譬如目前雖然有了形態(tài)鍵緩存，但是原模型中的形態(tài)鍵信息還存儲在模型中，這一部分的信息不需要被threejs讀取，卻很大的占用了模型的體積，后續(xù)可以開發(fā)一個gltf-pipeline類似的處理工具，將形態(tài)鍵緩存直接整合進(jìn)gltf模型中，同時把整個模型的序列化工作放到wasm中處理，降低模型的尺寸的同時也可以減少模型解析的時長。期待為大家?guī)砀玫氖褂皿w驗。
本文鏈接：http://m.www897cc.com/showinfo-26-101717-0.html基于 Three.js 的 3D 模型加載優(yōu)化
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號