Реализация тепловых карт (Heatmaps) в мобильном приложении
Тепловые карты в мобильном приложении — инструмент аналитики и навигации одновременно: показать плотность заказов, популярные зоны, активность водителей. Проблема не в рендеринге — библиотеки справляются, — а в работе с большими датасетами на мобильном экране без деградации FPS.
Как рендерятся тепловые карты
Каждая библиотека строит heatmap через kernel density estimation: для каждой точки на экране считается взвешенная сумма вкладов от всех точек данных в заданном радиусе. Результат — bitmap-слой поверх карты.
iOS: GMUHeatmapTileLayer из google-maps-ios-utils. Данные — массив GMUWeightedLatLng. Радиус градиента, минимальная интенсивность и цветовая схема настраиваются через свойства слоя. Тайловый механизм означает, что при скролле карты новые тайлы рендерятся на лету — без лага, если датасет не огромный.
Android: HeatmapTileProvider из android-maps-utils. Принцип аналогичный. Передаём Collection<LatLng> или Collection<WeightedLatLng> для взвешенных точек.
Flutter: google_maps_flutter не включает heatmap из коробки. Два варианта: нативный platform channel к GMSMapView/MapView с GMUHeatmapTileLayer / HeatmapTileProvider, или библиотека flutter_map + flutter_map_heatmap на основе canvas.
Работа с большими датасетами
Главная проблема: передавать 50 000 точек в GMUHeatmapTileLayer и ждать, пока он их обработает на main thread — получить ANR или заморозку на 3-4 секунды.
Правильный подход — агрегация на сервере. Вместо 50 000 сырых точек сервер возвращает уже агрегированные данные по сетке (grid aggregation): каждая ячейка сетки — одна точка с весом, равным количеству событий в ячейке. При зуме 10 — сетка 500×500 метров, при зуме 14 — 50×50 метров. Количество точек сокращается до 200-500 вне зависимости от исходного объёма.
Серверная агрегация через PostGIS:
SELECT
round(lat::numeric, 3) AS lat_grid,
round(lon::numeric, 3) AS lon_grid,
COUNT(*) AS weight
FROM events
WHERE created_at > now() - interval '7 days'
GROUP BY lat_grid, lon_grid;
При изменении зума карты — перезапрашиваем агрегацию с новой точностью округления. Дебаунс 500 мс на событие изменения зума обязателен.
Цветовые схемы и интерпретация
Стандартная цветовая схема (синий → зелёный → жёлтый → красный) интуитивна, но не подходит для людей с дальтонизмом. Для B2B-аналитики лучше работает одноцветный градиент (белый → тёмно-синий) или кастомная схема бренда.
GMUHeatmapTileLayer принимает [GMUGradient] с массивом цветов и позиций — настраивается без пересборки.
Срок: два-три дня — интеграция библиотеки, серверная агрегация (если нужна), настройка динамического зума, цветовая схема.