基于 Three.js 的 3D 模型加载优化

想对加载进行优化，首先需要了解Three.js加载模型时的工作流程，并分析出其中耗时的部分进行针对性的处理。

在Three.js中，模型从加载到渲染需要经过模型下载、序列化模型、网格解析、写入缓存和渲染模型几个步骤，经过分析发现主要的瓶颈在网络请求和网格解析两个部分，所以整体的优化思路就是减少网络请求资源的体积和提升网格的解析速度。

但是Three.js提供的gltfloader是不能直接加载zip文件的，于是我们需要对其进行功能扩展。

Three.js加载gltf模型是首先通过fetch请求获取到模型的arraybuffer，再对arraybuffer进行格式化。所以我们只需要在模型格式化之前拦截zip文件进行解压缩即可。

看起来还不错，在保证视觉效果的同时又可以大幅压缩模型的体积，那么有没有可能做的再极致一些呢？

既然是针对性的场景，我们就可以从解压缩的解算开始入手，于是我们使用rust写了一个解压工具，将其转换成wasm包代替jszip，可以发现wasm的冷启动性能确实要比js好很多，可以将解压的时长从几十到100毫秒降低到1毫秒左右，适合体积比较小的解压缩场景。

作为一个h5项目，获取到静态资源的链接并不困难，所以需要对模型文件进行一点点加密，让破解起来没有那么容易。同时解密的过程不能显著延长资源加载的时间，影响用户体验。

基于数据解密的效率，我们可以截取文件buffer的一部分进行加密，而不对全文进行加密，同时将数据解密的过程也放到wasm中，提升解算效率的同时也增强了安全性。采用对称加密的算法，同一个方法既可以用于加密，也可以用于解密。

按照模型加载的流程，解密的操作应该放在解压缩之后，序列化之前，那么如何判断数据是否进行了加密呢，可以通过判断解压数据decode以后是否有glTF的标记来确定。

在模型加载的时候通常会设置一个loading页面来展示当前的加载进度，同时loading页也可以播放一些动效或者互动来让用户等待的过程中不那么无聊。但是由于js单线程的特性，在进行首帧渲染的时候任何事件都不无法响应，会让用户误以为页面卡死，造成流失。

为了解决这个问题我们可以使用分步加载的方案，在模型加载的时候先遍历第一层网格，将所有的网格隐藏起来，然后循环这些网格，每展示一个就执行一次render方法，这样就可以把一个大的卡顿分散成多个小的，不至于影响前台的体验。

通过这种方式成功的将首帧渲染的时间从7秒缩短到0.6秒，大幅的提升了用户的体验。

讲到这里，大家可能发现了，虽然首帧渲染的时长缩短了，但是形态键缓存的资源有80mb，压缩后也有15mb，这块的时长可不可以继续压榨呢，先看一下资源的处理流程，处理解压后的文件需要将文件解析成JSON字符串，然后在转换成float32array，这里耗时最大的点就是JSON.parse的操作，有没有更好的方式处理呢，可以将这部分内容丢到rust里面，平均可以减少0.5s的时间。

经过这一系列的操作，成功的将模型的体积从50mb压缩到11mb，增加了额外80mb的形态键缓存也可以使用zip压缩到15mb，处理后页面的首次加载时长从15秒缩短到5秒，算是一个不小的提升。

然而，我们也意识到还有进一步的优化空间，譬如目前虽然有了形态键缓存，但是原模型中的形态键信息还存储在模型中，这一部分的信息不需要被threejs读取，却很大的占用了模型的体积，后续可以开发一个gltf-pipeline类似的处理工具，将形态键缓存直接整合进gltf模型中，同时把整个模型的序列化工作放到wasm中处理，降低模型的尺寸的同时也可以减少模型解析的时长。期待为大家带来更好的使用体验。