Three.js 升级后Safari内存占用问题分析与解决方案

在Three.js项目从r165版本升级到r166版本后，开发者发现了一个值得关注的问题：在Safari浏览器(MacOS 15.1.1和iOS 18.2)中，GLB模型的渲染会导致内存占用增加约50MB。这个问题对于移动端特别是iPhone用户影响较大，因为移动设备的内存资源更为有限。

问题根源分析

经过技术团队的深入调查，发现问题源于r166版本中GLTFLoader的一个重要改动：默认使用ImageBitmapLoader来加载纹理。ImageBitmapLoader的设计初衷是为了优化性能，它采用异步方式解压缩纹理数据，避免在上传纹理到GPU时阻塞主线程导致掉帧。

然而在Safari浏览器中，这种处理方式似乎导致了额外的内存开销。具体表现为：

1. 使用ImageBitmapLoader时，纹理对象在主线程保留了未压缩数据的引用
2. 传统方式下，纹理解压缩完全在GPU端进行，主线程不会保留这些数据
3. Safari可能没有像其他浏览器那样高效地管理这些中间数据

技术验证与解决方案

开发团队提出了几种验证和解决方案：

1. 内存释放验证

可以通过以下代码验证内存释放情况：

texture.onUpdate = function() {
    texture.source.data.close();
    texture.source.data = null;
};

这段代码利用了Texture.onUpdate回调，在纹理上传到GPU后立即释放CPU端的纹理数据。ImageBitmap.close()是专门用于释放图像位图相关资源的标准方法。

2. 模型优化方案

对于长期解决方案，建议开发者：

1. 使用DRACO压缩技术处理模型
2. 将纹理转换为WEBP或AVIF格式
3. 控制纹理分辨率(如最大2048x2048)
4. 使用KTX2等现代纹理格式

这些优化可以显著减少内存占用，某些情况下甚至能减少50%的内存使用。

浏览器兼容性建议

由于这个问题主要出现在Safari浏览器，建议开发者：

1. 针对Safari用户考虑回退到传统加载方式
2. 监控不同浏览器中的内存使用情况
3. 在关键操作后主动触发内存清理

总结

Three.js r166版本引入的ImageBitmapLoader在大多数情况下能提升性能，但在Safari中可能导致显著的内存增加。开发者需要权衡性能优化与内存占用的关系，根据目标用户群体选择合适的解决方案。对于移动端特别是iOS用户，建议实施额外的内存优化措施或考虑特定于Safari的优化策略。