webgl限制帧率_也聊webgl中的大场景性能优化

随着项目越来越复杂，很多对大场景渲染支持已经成为了“刚需”。但是，对于很多经验有限的同学，似乎找不到相关思路。那么，我们就来聊聊，如何进行 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 进行解压，可以保证自己的模型内部格式对外是一个黑盒子。

贴图压缩

(感谢知乎评论区 王政 同学提醒，加入贴图压缩部分)

上述描述的模型压缩