CesiumJS中GLB文件共享外部纹理的内存统计问题分析

问题背景

在CesiumJS项目中，当多个GLB文件共享相同的外部纹理时，系统虽然实际只加载了一次纹理资源，但在内存使用统计上却错误地重复计算了这些共享纹理所占用的内存空间。这导致系统误判内存使用情况，进而可能过早地停止加载更多3D瓦片内容。

技术细节

该问题的核心在于CesiumJS的内存统计机制。系统通过ModelStatistics类来累计每个模型的内存使用情况，其中包含对纹理内存的计算。虽然在实际加载过程中，GltfImageLoader类确实通过缓存机制确保了相同纹理只被加载一次，但内存统计系统未能识别这种共享情况。

具体表现为：

1. 每个GLB文件引用的外部纹理都被独立统计
2. 即使多个文件引用同一纹理，统计值仍会叠加
3. 最终导致totalMemoryUsageBytes计算值远高于实际内存占用

影响范围

这一问题主要影响以下场景：

• 使用外部纹理的3D瓦片集
• 多个瓦片共享相同纹理资源的场景
• 内存预算较为紧张的应用环境

典型症状是系统过早显示"内存不足"警告，并开始省略部分瓦片的加载，即使实际内存使用并未达到限制。

解决方案分析

解决这一问题需要考虑两个技术层面：

1. 纹理标识机制：

   • 现有Texture对象已包含_id字段
   • 可利用GltfTextureLoader中的cacheKey作为唯一标识
   • 需要将cacheKey信息传递到Texture对象创建过程

2. 全局内存统计：

   • 需要在Cesium3DTilesetStatistics级别维护纹理ID到大小的映射
   • 实现引用计数机制跟踪纹理使用情况
   • 在瓦片加载/卸载时正确更新统计信息

实现考量

技术实现上面临的主要挑战是接口设计。现有Cesium3DTileContent接口需要扩展以支持纹理共享信息的传递，同时要避免破坏现有实现类的兼容性。可能的解决方案包括：

• 扩展接口增加纹理共享信息方法
• 使用适配器模式包装现有实现
• 在统计系统中引入更智能的纹理追踪机制

总结

CesiumJS中GLB文件共享外部纹理的内存统计问题虽然不影响实际渲染性能，但会导致系统对内存使用的误判。通过改进纹理标识和全局统计机制，可以更准确地反映实际内存占用情况，提升资源管理效率。这一改进对于处理大规模3D场景，特别是包含大量重复纹理的瓦片集尤为重要。