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

问题背景

在CesiumJS项目中，当使用3D Tileset加载包含多个GLB文件的场景时，如果这些GLB文件共享相同的外部纹理资源，系统会出现内存统计不准确的问题。具体表现为：尽管纹理资源实际上只被加载一次并在多个模型间共享，但内存统计系统却会重复计算这些共享纹理的内存占用，导致系统错误地认为内存使用量超出限制，从而过早地停止加载更多图块。

技术细节分析

纹理共享机制

CesiumJS确实实现了纹理共享机制。通过GltfImageLoader类，系统能够识别并复用相同的外部纹理资源。当多个GLB文件引用同一个外部纹理时，该纹理实际上只会被加载一次，后续引用都会指向同一个纹理对象。

内存统计问题

问题出在内存统计系统的工作方式上。当前实现中：

1. 每个Model3DTileContent都会独立统计其纹理内存使用量
2. ModelStatistics类虽然会检查纹理ID以避免重复统计，但这种检查仅限于单个模型内部
3. Cesium3DTilesetStatistics会累加所有加载图块的纹理内存使用量

这种设计导致当多个图块共享相同纹理时，纹理内存会被多次计入总内存使用量，造成统计值远高于实际内存占用。

影响与表现

这种内存统计不准确会导致以下问题：

1. 系统过早判定内存不足，停止加载更多图块
2. 场景中可能出现图块缺失，影响视觉效果
3. 资源利用率降低，无法充分利用可用内存

在测试案例中，即使整个场景只包含两个2048x2048的PNG纹理和少量几何数据，当加载约100个共享这些纹理的图块时，系统就会错误地报告内存不足。

解决方案思路

要解决这个问题，需要从以下几个方面入手：

纹理标识机制

1. 利用现有的Texture._id字段
2. 从GltfTextureLoader的cacheKey中提取唯一标识符
3. 在CreateTextureJob中将这个标识符传递给Texture对象

全局内存统计

1. 在Cesium3DTilesetStatistics中维护全局的纹理ID到内存大小的映射
2. 实现引用计数机制跟踪纹理使用情况
3. 在加载/卸载图块时更新全局统计信息

接口设计考虑

需要谨慎设计接口变更，避免破坏现有实现。可能的方案包括：

1. 扩展Cesium3DTileContent接口以支持纹理共享信息
2. 在Model3DTileContent中实现新的统计逻辑
3. 保持向后兼容性，避免影响其他类型的图块内容

总结

CesiumJS中的纹理共享机制虽然实际工作正常，但由于内存统计系统未能正确识别共享纹理，导致了资源使用评估不准确的问题。通过改进纹理标识和全局统计机制，可以更准确地反映实际内存使用情况，从而提高系统资源利用率，避免不必要的图块加载限制。这个问题不仅影响性能表现，在某些情况下还会直接影响渲染结果的完整性，是3D Tileset处理中需要重视的一个技术细节。