随着项目越来越复杂,很多对大场景渲染支持已经成为了“刚需”。但是,对于很多经验有限的同学,似乎找不到相关思路。那么,我们就来聊聊,如何进行 webgl 的性能优化。
首先性能优化是一个比较大的话题,会涉及多个技术点,本篇文章旨在总结相关优化思路和方向,很多阐述都是浅尝辄止,并不对每项技术点做具体的深入剖析。对于大场景来说,一般优化可以分为以下几个大的优化方向。加载性能优化
渲染帧率优化
内存管理优化
交互操作优化
我们会根据每个大的方向,讲讲如何具体的采取哪些策略进行优化。我们首先需要知道造成渲染帧率不高的性能瓶颈在哪里。一般来说,我们使用 chrome 的开发者工具中的 performance 模块进行性能诊断,找到性能瓶颈主要是在 CPU 执行效率方面,还是在 GPU 渲染阶段的性能方面。
如果主要性能瓶颈在 cpu 执行阶段,我们其实非常容易找到某段 js 的执行效率较低,可以通过各种算法优化,降低 js 算法的时间复杂度,从而达到优化执行时间的目的。
1. 加载优化
受制于网络速度,对于没有缓存的大场景首次加载,可能是比较费时的,所以我们需要尽量减少加载时间,提高用户体验。
模型压缩
模型和贴图数据是整个加载过程中最为“重量级”的数据。因此,我们应当从建模阶段就定好规范,在保证外观效果的前提下,尽量使用较为精简(面数较少)的模型。在模型制作完成之后,我们也应当尽量选取一些压缩比较高的模型格式,例如 fbx、gltf 等进行模型传输。
gzip
对于一些纯字符编码的模型,如 obj,dae 等,在服务端开启 gzip 压缩,可以带来较好的压缩比。而且,使用 gzip 压缩是服务器与浏览器直接默认完成的,无需任何额外操作,对于开发者可以做到无感知。所以建议使用这类模型的都加上 gzip 压缩。其实我们可以默认所有文件都开启,因为 js css 文件经过 gzip 压缩后传输量也会小很多。
gltf draco
对于可以选取导出格式的项目来说,选取 gltf 格式加 draco 压缩的方式,可以得到较高的压缩比。不过使用 draco 压缩并不是没有代价的,有时候可能会造成模型的外观损坏。同时,解压模型也需要一些的时间。所以,对于小的模型,网络传输较快的,也就没必要上 draco 压缩了。
自定义格式
对于有能力的开发者,完全可以使用自定义的格式,将模型数据做成二进制的形式进行传输和加载,这样灵活性比较高,而且如果再前端解模型的时候使用 wasm 进行解压,可以保证自己的模型内部格式对外是一个黑盒子。
贴图压缩
(感谢知乎评论区 王政 同学提醒,加入贴图压缩部分)
上述描述的模型压缩