哪个网站做二手车抵押,网络营销常用工具有哪些?,用什么l软件做网站了,微信营销的含义作者#xff1a;来自 vivo 互联网前端团队- Su Ning 作为一个3D的项目#xff0c;从用户打开页面到最终模型的渲染需要经过多个流程#xff0c;加载的时间也会比普通的H5项目要更长一些#xff0c;从而造成大量的用户流失。为了提升首屏加载的转化率#xff0c;需要尽可能… 作者来自 vivo 互联网前端团队- Su Ning 作为一个3D的项目从用户打开页面到最终模型的渲染需要经过多个流程加载的时间也会比普通的H5项目要更长一些从而造成大量的用户流失。为了提升首屏加载的转化率需要尽可能的降低loading的时间。这里就分享一些我们在模型加载优化方面的心得。
一、前言
近段时间我们使用three.js完成了vivo拟我形象的开发工作大家可以在vivo账号中拟制属于自己的3D形象也可以保存作为自己的头像名片。 作为一个3D的项目从用户打开页面到最终模型的渲染需要经过多个流程加载的时间也会比普通的H5项目要更长一些。然而过长的等待时间会造成大量的用户流失这部分用户没有体验到具体的功能就退出了页面非常的遗憾为了提升首屏加载的转化率需要尽可能的降低loading的时间。这里就分享一些我们在模型加载优化方面的心得。
二、模型加载的优化思路
想对加载进行优化首先需要了解Three.js加载模型时的工作流程并分析出其中耗时的部分进行针对性的处理。
在Three.js中模型从加载到渲染需要经过模型下载、序列化模型、网格解析、写入缓存和渲染模型几个步骤经过分析发现主要的瓶颈在网络请求和网格解析两个部分所以整体的优化思路就是减少网络请求资源的体积和提升网格的解析速度。 三、缩小模型的体积
3.1 常见的解决方案
目前主流的压缩方案是使用google的draco库对模型进行压缩。draco的原理类似降低图片的分辨率通过减少模型的顶点数起到压缩体积的效果。
也就是说draco是一种有损的压缩方式这样就会带来诸多的问题 可能在网格连接处存在画面模型撕裂。 仅仅压缩顶点只能将50.7mb的人物模型压缩到49.5压缩效果有限。 draco前台decoder在h5中的解算效率不理想可能节省下来的网络请求时间还没有增加的数据解算的时间长。
基于以上几点最终我们放弃了draco的压缩方案。 使用draco压缩之后导致的模型撕裂
3.2 进阶方案
高端的食材往往只需要采用最朴素的烹饪方式。经过一些尝试我们发现将glb模型直接打成zip包可以明显的提升模型的压缩效率。50.7mb的人物模型可以压缩到11.6mb。 但是Three.js提供的gltfloader是不能直接加载zip文件的于是我们需要对其进行功能扩展。
Three.js加载gltf模型是首先通过fetch请求获取到模型的arraybuffer再对arraybuffer进行格式化。所以我们只需要在模型格式化之前拦截zip文件进行解压缩即可。 于是我们使用jszip资源加载完成后判断资源的后缀如果是zip文件就使用jszip进行解压缩。 看起来还不错在保证视觉效果的同时又可以大幅压缩模型的体积那么有没有可能做的再极致一些呢
既然是针对性的场景我们就可以从解压缩的解算开始入手于是我们使用rust写了一个解压工具将其转换成wasm包代替jszip可以发现wasm的冷启动性能确实要比js好很多可以将解压的时长从几十到100毫秒降低到1毫秒左右适合体积比较小的解压缩场景。 四、文件的加解密
作为一个h5项目获取到静态资源的链接并不困难所以需要对模型文件进行一点点加密让破解起来没有那么容易。同时解密的过程不能显著延长资源加载的时间影响用户体验。
基于数据解密的效率我们可以截取文件buffer的一部分进行加密而不对全文进行加密同时将数据解密的过程也放到wasm中提升解算效率的同时也增强了安全性。采用对称加密的算法同一个方法既可以用于加密也可以用于解密。
按照模型加载的流程解密的操作应该放在解压缩之后序列化之前那么如何判断数据是否进行了加密呢可以通过判断解压数据decode以后是否有glTF的标记来确定。 如下图数据解密的耗时几乎可以忽略不计可以放心使用。 五、如何优化首帧的渲染体验
优化完模型的加载继续来优化模型的渲染在加载一个体积比较大的模型的时候经常会有页面的卡死的情况出现需要从两方面治标也治本的进行优化 通过减少页面的卡停来优化用户的感官体验。 通过缩短首屏渲染的时长来解决根本问题。
5.1 减少页面的卡停
在模型加载的时候通常会设置一个loading页面来展示当前的加载进度同时loading页也可以播放一些动效或者互动来让用户等待的过程中不那么无聊。但是由于js单线程的特性在进行首帧渲染的时候任何事件都不无法响应会让用户误以为页面卡死造成流失。
为了解决这个问题我们可以使用分步加载的方案在模型加载的时候先遍历第一层网格将所有的网格隐藏起来然后循环这些网格每展示一个就执行一次render方法这样就可以把一个大的卡顿分散成多个小的不至于影响前台的体验。 但是这样的方法只能让用户感受起来没那么卡顿该等的时间一点没少过长的等待时间还是会让用户等的不耐烦有没有其他解决卡顿的方式呢这就要从Three.js的渲染逻辑来进行分析了。
5.2 缩短首帧渲染的时间
由于我们做的是一个捏脸的项目通过形态键来实现不同的脸型表情等表现。在Three.js中存储形态键信息的属性在geometry.morphAttributes中形态键存放的顶点信息总数与网格的顶点数相同这就意味着同一个模型有多少个形态键就额外需要加载多少套网格的顶点信息。在首次渲染的时候Three.js会遍历每一个形态键的顶点信息生成一个float32array而这个巨量的遍历操作就是造成卡顿的根本原因。 如何解决这个循环黑洞呢我想到了steamdeck上的着色器预缓存通过将着色器编译的结果进行持久化缩短页面加载的时间。那么我们只要将每一个网格的形态键编译的结果储存起来就行了。 /three/src/renderers/webgl/WebGLMorphtargets.js 通过这种方式成功的将首帧渲染的时间从7秒缩短到0.6秒大幅的提升了用户的体验。
讲到这里大家可能发现了虽然首帧渲染的时长缩短了但是形态键缓存的资源有80mb压缩后也有15mb这块的时长可不可以继续压榨呢先看一下资源的处理流程处理解压后的文件需要将文件解析成JSON字符串然后在转换成float32array这里耗时最大的点就是JSON.parse的操作有没有更好的方式处理呢可以将这部分内容丢到rust里面平均可以减少0.5s的时间。 六、总结与规划
以上就是我们的优化流程将glb模型文件压缩成zip包配合前台wasm解压工具降低模型的加载时间。通过增加形态键缓存的方式来降低首帧渲染的时长。 经过这一系列的操作成功的将模型的体积从50mb压缩到11mb增加了额外80mb的形态键缓存也可以使用zip压缩到15mb处理后页面的首次加载时长从15秒缩短到5秒算是一个不小的提升。
然而我们也意识到还有进一步的优化空间譬如目前虽然有了形态键缓存但是原模型中的形态键信息还存储在模型中这一部分的信息不需要被threejs读取却很大的占用了模型的体积后续可以开发一个gltf-pipeline类似的处理工具将形态键缓存直接整合进gltf模型中同时把整个模型的序列化工作放到wasm中处理降低模型的尺寸的同时也可以减少模型解析的时长。期待为大家带来更好的使用体验。
