Caching политики

Кэширование в CesiumJS строится как многоуровневая система, в которой участвуют браузер, транспортный слой загрузки ресурсов, внутренние кэши текстур и тайлов, а также специализированные механизмы для 3D Tiles, изображений, террейна и данных с Cesium ion. Такая архитектура позволяет минимизировать сетевые запросы, уменьшить задержки при навигации по сцене и обеспечить стабильную производительность при работе с большими объёмами геопространственных данных.


В CesiumJS кэширование не является единым механизмом. Оно распределено по нескольким уровням:

  • HTTP-кэш браузера (Cache-Control, ETag, Last-Modified)
  • Внутренний кэш ресурсов Cesium (ResourceCache)
  • Кэш загруженных тайлов в ImageryLayer и TerrainProvider
  • Кэш 3D Tiles (тайлы и их контент)
  • GPU-кэш (текстуры и буферы WebGL)

Каждый уровень решает свою задачу и оптимизирован под конкретный тип данных.


HTTP-кэш и управление заголовками

CesiumJS активно использует стандартные механизмы HTTP-кэширования. При загрузке ресурсов через Resource и RequestScheduler учитываются:

  • Cache-Control
  • ETag
  • Expires
  • Last-Modified

Если сервер корректно настроен, повторные запросы могут быть полностью устранены на уровне браузера.

Особенность CesiumJS заключается в том, что библиотека не препятствует работе браузерного кэша, а наоборот — старается максимально его использовать. При этом можно управлять поведением запросов через параметры:

  • request.headers
  • request.throttle
  • request.priority

Это позволяет тонко регулировать баланс между актуальностью данных и скоростью загрузки сцены.


ResourceCache: внутренний кэш ресурсов

Класс ResourceCache отвечает за хранение загруженных ресурсов в памяти JavaScript. Он используется для:

  • изображений текстур
  • бинарных данных (ArrayBuffer)
  • JSON-описаний тайлов
  • шейдеров и вспомогательных данных

Кэш реализован как LRU-структура (Least Recently Used), что означает автоматическое удаление наименее используемых элементов при превышении лимита памяти.

Ключевые особенности:

  • хранение по URL или производному ключу ресурса
  • контроль времени жизни объектов
  • автоматическая очистка при нехватке памяти WebGL

Важный аспект: ResourceCache работает независимо от HTTP-кэша и может содержать уже «устаревшие» данные, если не настроено принудительное обновление.


Кэширование ImageryLayer

Слой изображений (например, Bing Maps, OpenStreetMap, WMS/WMTS) использует многоуровневый тайловый кэш.

Основные принципы:

  • тайлы делятся по координатной сетке (x, y, level)
  • каждый тайл имеет уникальный ключ
  • загруженные изображения сохраняются в памяти и переиспользуются при перемещении камеры

Поведение кэша:

  • при панорамировании сцены Cesium повторно использует уже загруженные тайлы
  • при изменении уровня детализации старые тайлы могут оставаться в памяти до вытеснения
  • стратегия зависит от ImageryProvider

LRU-подобная модель позволяет удерживать в памяти наиболее актуальные тайлы вокруг текущей камеры.


Кэш TerrainProvider

Геометрия поверхности (terrain) кэшируется аналогично изображениям, но с дополнительной сложностью:

  • данные содержат высотные карты (heightmap) или quantized-mesh
  • тайлы имеют зависимость от LOD (Level of Detail)
  • соседние тайлы могут объединяться для построения сетки

Terrain-кэш оптимизирован под повторное использование геометрии при изменении угла обзора.

Особенности:

  • хранение декодированных мешей в памяти
  • повторное использование вершинных буферов
  • ограничение по GPU-памяти

Кэш 3D Tiles

3D Tiles — наиболее сложный источник данных в CesiumJS, и его кэширование критично для производительности.

Структура кэша:

  • тайлы (Tile)
  • контент тайлов (b3dm, i3dm, pnts)
  • готовые WebGL ресурсы
  • bounding volume и метаданные

Поведение:

  • Cesium загружает тайлы по мере приближения камеры
  • ранее загруженные тайлы остаются в памяти, если они находятся в зоне актуальности
  • при выходе из области видимости тайлы могут быть выгружены

Ключевой механизм — Tile Cache + Tile Replacement Policy, который определяет:

  • какие тайлы оставить
  • какие выгрузить
  • какие заменить более детализированными версиями

Используется стратегия, основанная на:

  • расстоянии до камеры
  • screen-space error (SSE)
  • приоритете загрузки

RequestScheduler и управление загрузкой

RequestScheduler не является кэшем напрямую, но влияет на эффективность кэширования.

Он контролирует:

  • количество одновременных запросов
  • приоритет загрузки тайлов
  • задержки между запросами

Это снижает вероятность повторных загрузок одних и тех же ресурсов при высокой нагрузке.


GPU-кэш и WebGL ресурсы

На уровне графического процессора CesiumJS хранит:

  • текстуры (imagery, materials)
  • vertex buffers (terrain, 3D Tiles)
  • index buffers
  • compiled shaders

Особенности:

  • ресурсы живут до освобождения контекста WebGL или явного удаления
  • текстуры могут быть пересозданы при потере контекста
  • используется механизм референсного подсчёта

GPU-кэш тесно связан с ResourceCache, но работает на другом уровне памяти.


Инвалидация кэша

Кэширование в CesiumJS не является полностью статичным. Существуют механизмы инвалидирования:

  • изменение URL ресурса
  • обновление тайловых схем
  • смена параметров ImageryProvider
  • ручной вызов destroy() у слоёв
  • истечение времени жизни LRU-элементов

Особое внимание уделяется тому, что изменение параметров провайдера не всегда автоматически очищает старые данные, поэтому возможны «смешанные» состояния сцены при динамической конфигурации.


Тайловые стратегии и влияние на кэш

Разные провайдеры реализуют различные стратегии кэширования:

  • WMTS — строгая tile-based модель с предсказуемым кэшем
  • WMS — более динамическая модель, кэш менее эффективен
  • XYZ — оптимален для LRU-кэширования
  • Cesium ion — серверная оптимизация + клиентский кэш

Чем более регулярна структура тайлов, тем эффективнее работает кэш.


Memory pressure и очистка

CesiumJS учитывает ограниченность памяти браузера:

  • при росте количества тайлов запускается eviction
  • удаляются наименее используемые текстуры и геометрия
  • учитывается размер GPU памяти

Внутренние алгоритмы стараются сохранить баланс между:

  • визуальной стабильностью сцены
  • количеством доступных деталей
  • объёмом используемой памяти

Детерминированность кэша при навигации

При перемещении камеры кэш обеспечивает:

  • мгновенное отображение ранее загруженных областей
  • постепенную догрузку новых тайлов
  • отсутствие повторных запросов при возврате в ранее посещённую область

Эта модель делает возможной плавную навигацию даже в сценах с миллионами тайлов.


Влияние параметров Cesium на кэширование

На поведение кэша влияют:

  • maximumScreenSpaceError
  • maximumMemoryUsage
  • requestRenderMode
  • preloadSiblings
  • tileCacheSize

Изменение этих параметров напрямую влияет на:

  • плотность загружаемых данных
  • скорость очистки кэша
  • устойчивость к пиковым нагрузкам

Кэширование пользовательских ресурсов

При работе с кастомными ImageryProvider и DataSource необходимо учитывать:

  • Cesium не всегда автоматически кэширует нестандартные источники
  • требуется явная реализация cache key
  • желательно учитывать версионность данных

Неправильная реализация приводит к частым повторным загрузкам и деградации производительности.


Оптимизация кэш-стратегий

Эффективная работа с кэшированием достигается за счёт:

  • корректных HTTP-заголовков
  • стабильных URL ресурсов
  • ограничения избыточных запросов через RequestScheduler
  • использования tile-friendly форматов (quantized mesh, b3dm)
  • контроля LOD-структуры

При больших сценах критично избегать динамических URL без версионирования, так как это полностью ломает эффективность кэша на всех уровнях.