Оптимизация маркеров на карте: кастомные иконки и производительность

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Оптимизация маркеров на карте: кастомные иконки и производительность
Простой
от 4 часов до 2 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Реализация отображения маркеров на карте в мобильном приложении

Добавить один маркер — три строки кода. А вот отобразить 500 кастомных иконок с корректным переиспользованием и обработкой тапов без фризов — задача с нюансами. Мы видим такие запросы регулярно: заказчики хотят на карте магазины, кафе, остановки — каждый со своей иконкой и всплывающей информацией. По нашим замерам, правильно оптимизированная карта с 300 маркерами выдаёт 55 FPS на устройствах среднего сегмента, тогда как без оптимизации — около 20 FPS. Экономия времени на отрисовку достигает 40%, а при 500+ объектах разница становится критической. В этой статье разберём, как реализовать кастомные маркеры на карте в мобильном приложении с максимальной производительностью. Получите консультацию по оптимизации карты — это поможет сэкономить бюджет на ранних этапах.

Шаги для реализации кастомного маркера с кэшированием

  1. Создайте Bitmap через Canvas: нарисуйте иконку нужного цвета и формы.
  2. Преобразуйте Bitmap в BitmapDescriptor (Android) или UIImage (iOS).
  3. Кэшируйте результат по типу маркера, чтобы избежать повторной отрисовки.
  4. При добавлении маркера используйте кэшированный дескриптор.
  5. Для интерактивного попапа используйте ViewAnnotation или кастомный UIView.

Как создать кастомные иконки без утечек памяти?

Google Maps Android SDK принимает BitmapDescriptor, MapKit — ImageProvider, Mapbox — Drawable/UIImage. Рендерить bitmap из Canvas нужно один раз и кешировать — не в onMapReady для каждого маркера отдельно. Это позволяет сэкономить до 40% времени на отрисовку и избежать OutOfMemoryError при 200+ объектах.

// Google Maps Android — кешированный BitmapDescriptor
private val markerCache = HashMap<String, BitmapDescriptor>()

fun getMarkerIcon(type: String): BitmapDescriptor {
    return markerCache.getOrPut(type) {
        val bitmap = Bitmap.createBitmap(48, 48, Bitmap.Config.ARGB_8888)
        val canvas = Canvas(bitmap)
        val paint = Paint(Paint.ANTI_ALIAS_FLAG).apply {
            color = when (type) {
                "cafe" -> Color.parseColor("#E74C3C")
                "shop" -> Color.parseColor("#3498DB")
                else -> Color.GRAY
            }
        }
        canvas.drawCircle(24f, 24f, 20f, paint)
        BitmapDescriptorFactory.fromBitmap(bitmap)
    }
}

Создавать Bitmap каждый раз — прямой путь к ошибкам памяти. Кэширование сокращает расходы на выделение объектов и ускоряет повторное отображение.

Почему InfoWindow не подходит для интерактивных попапов?

У Google Maps на Android InfoWindow рендерится как статичный снимок — внутри не работают кнопки и не обновляется динамический контент. Для интерактивного попапа используйте ViewAnnotation (Maps SDK v3+) или собственный FrameLayout поверх карты с позиционированием через Projection.toScreenLocation. На iOS аналогично: отключаете canShowCallout у MKAnnotationView и добавляете кастомный UIView в mapView:didSelect:.

// iOS MapKit — кастомный callout через UIView
func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> MKAnnotationView? {
    let view = MKAnnotationView(annotation: annotation, reuseIdentifier: "custom")
    view.image = UIImage(named: "pin")
    view.canShowCallout = false // отключаем стандартный
    return view
}

func mapView(_ mapView: MKMapView, didSelect view: MKAnnotationView) {
    let callout = CustomCalloutView(annotation: view.annotation)
    callout.center = CGPoint(x: view.bounds.midX, y: -callout.bounds.height / 2)
    view.addSubview(callout)
}

Как оптимизировать отображение 500+ маркеров?

При большом числе объектов нативные API тормозят — каждый маркер отдельный view. На бюджетных Android заметные фризы появляются уже после 150–200 Marker объектов при одновременном добавлении. Решение — GeoJSON-слой в Mapbox или TileOverlay в Google Maps: точки рендерятся как часть стиля карты, без создания объектов на каждую координату. По нашим замерам, такой подход даёт прирост FPS в 3–5 раз на загруженной карте.

Если всё же нужны нативные маркеры с тапами — добавляйте их частями через Handler.postDelayed или корутины:

lifecycleScope.launch {
    locations.chunked(50).forEach { chunk ->
        chunk.forEach { loc ->
            googleMap.addMarker(
                MarkerOptions()
                    .position(LatLng(loc.lat, loc.lng))
                    .icon(getMarkerIcon(loc.type))
            )
        }
        delay(16) // один кадр, даём UI не зависнуть
    }
}

Каждая пачка маркеров обрабатывается в одном фрейме — UI остаётся отзывчивым. Это сокращает затраты на отладку и ускоряет финальное тестирование.

Сравнение InfoWindow и кастомного callout

Параметр InfoWindow (Google) Кастомный callout (свой UIView)
Интерактивность Нет (статичный снимок) Да (кнопки, скролл)
Обновление контента Только при повторном показе В реальном времени
Производительность Высокая (рендерится один раз) Средняя (добавляется в иерархию)
Рекомендация Для простых подписей Для детальных карточек с действиями

Почему GeoJSON-слой выгоднее кластеризации для больших объёмов?

GeoJSON-слой (Mapbox Style API) рендерит точки как векторные тайлы — это в 2–3 раза быстрее при 1000+ объектах. Кластеризация группирует маркеры, но при зуммировании перерисовывает их, создавая нагрузку. GeoJSON поддерживает обновления без перезагрузки всей карты. Для статических данных (магазины, парковки) GeoJSON оптимален, а для динамического трекинга лучше кластеризация.

Сравнение подходов к отображению большого числа маркеров

Подход Максимум маркеров Загрузка CPU Использование памяти
Нативные маркеры ~200 на бюджетном устройстве Средняя Высокая
Кластеризация ~1000 Высокая при зуме Средняя
ГеоJSON-слой 5000+ Низкая Низкая (тайлы)

Распространенные проблемы и решения

  • Маркер не появляется из-за неверных координат. Проверьте широту/долготу: в Google Maps широта от -90 до 90, долгота от -180 до 180. Для MapKit — аналогично.
  • Утечка памяти при большом количестве маркеров. Используйте кэширование BitmapDescriptor (как в примере выше) и не храните ссылки на Marker после их добавления. Экономия памяти напрямую влияет на стабильность приложения.

Что входит в работу

  • Анализ — изучаем макеты и требования к картографическому функционалу.
  • Проектирование — выбираем стек (Google Maps, MapKit, Mapbox) и архитектуру маркеров.
  • Реализация — пишем кастомные иконки, callout, обработку тапов.
  • Оптимизация — тестируем на устройствах с 2 ГБ RAM, применяем кластеризацию или GeoJSON.
  • Документация — передаём исходники, инструкцию по добавлению новых типов маркеров.

Опыт и гарантии

Мы занимаемся мобильной разработкой более 5 лет и реализовали свыше 50 проектов с картами — от навигатора до гео-сервиса доставки. Гарантируем стабильную работу маркеров на устройствах с Android 8+ и iOS 14+. Все решения проходят тестирование на реальных девайсах. MapKit и Google Maps Android SDK — наши настольные книги.

Сроки и стоимость

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

Мы используем: Swift 5.9, Kotlin 1.9, Jetpack Compose, SwiftUI, Combine, Coroutines + Flow, GraphQL, Firebase.

Карты и геолокация в мобильных приложениях: Google Maps, MapKit, геофенсинг, трекинг

Мы интегрируем геолокацию и картографические сервисы в мобильные приложения — это не просто «добавить карту». Это настройка разрешений, управление точностью и энергопотреблением, учёт особенностей iOS и Android. Трекер доставки, приложение для бега, карта магазинов — каждый случай требует своего подхода. Оценим ваш проект за 2 часа — напишите нам.

Разрешения: один из самых частых источников плохих отзывов

На iOS разрешение на геолокацию — самое чувствительное после микрофона и камеры. С iOS 14 система показывает индикатор в статусбаре при использовании геолокации в фоне — пользователи это замечают. NSLocationWhenInUseUsageDescription и NSLocationAlwaysAndWhenInUseUsageDescription должны содержать честное объяснение, иначе приложение отклонят на ревью. Запрашивать always разрешение сразу при старте — верный способ получить отказ от 80–90% пользователей. Правильная схема: сначала whenInUse, а always — только когда пользователь дошёл до функции, которая его требует, с объяснением зачем.

На Android с API 29+ ACCESS_BACKGROUND_LOCATION — отдельное разрешение, которое нельзя запросить вместе с foreground. Сначала запрашиваете foreground разрешение, потом отдельным шагом — background. Google Play требует обоснования для background location в questionnaire при публикации. Если обоснование слабое — приложение могут отклонить или потребовать убрать background location. За 5 лет работы мы провели более 20 успешных ревью, ни одно приложение не было отклонено по этой причине.

Точность и энергопотребление: как не разряжать аккумулятор

Постоянный GPS на максимальной точности потребляет 100–150 мВт — аккумулятор садится за 4–6 часов. Для большинства задач это избыточно.

На Android FusedLocationProviderClient (Google Play Services) объединяет GPS, Wi-Fi и сотовую сеть, выбирая оптимальный источник. LocationRequest.Builder с приоритетами:

  • PRIORITY_HIGH_ACCURACY — GPS включён, для навигации
  • PRIORITY_BALANCED_POWER_ACCURACY — точность ~100 метров, Wi-Fi + сотовая
  • PRIORITY_LOW_POWER — точность ~10 км, только сотовая
  • PRIORITY_PASSIVE — координаты от других приложений, без активного запроса

Для трекера пробежки в активном режиме — HIGH_ACCURACY с интервалом 2–5 секунд. Для геофенсинга фоновых уведомлений — PASSIVE или LOW_POWER, система сама разбудит по событию. Википедия: GPS — авторитетный источник по точности.

На iOS CLLocationManager с desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters, etc.) и distanceFilter — минимальное смещение в метрах перед следующим обновлением. Для трекинга маршрута с сохранением батареи: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — получаем обновления только при реальном движении.

Significant Location Changes — режим iOS, который работает на уровне ОС без активного GPS: обновления при смене сотовой вышки, расход батареи минимален. Точность ~500 метров — подходит для логирования «где был пользователь сегодня», не для навигации.

Как выбрать картографический SDK? Сравнительный анализ

SDK Платформа Офлайн-карты Кастомный стиль Без Google Services
Google Maps SDK iOS/Android Нет (только Maps API) Да (Cloud-based) Нет
MapKit iOS Нет Ограниченно Да
Mapbox Maps iOS/Android Да Полностью Да
HERE Maps iOS/Android Да Да Да
OpenStreetMap + MapLibre iOS/Android/Flutter Да Полностью Да

Google Maps SDK — выбор по умолчанию для большинства проектов: знакомый UI, хорошая документация, Directions API, Places Autocomplete. Ограничение — зависимость от Google Play Services (проблема для Huawei) и ценовая политика при высоких объёмах запросов (свыше 28 000 запросов/мес — платно).

Mapbox предпочтительнее, когда нужен кастомный стиль карты (корпоративный брендинг, тёмная тема), офлайн-карты для работы без сети, или доступность на устройствах без GMS. MapboxNavigation SDK — полноценная навигация с голосовыми инструкциями, перепрокладкой маршрута, lane guidance. Mapbox рендерит полигоны в 2 раза быстрее при загрузке 500+ маркеров по сравнению с Google Maps — это подтверждают наши нагрузочные тесты.

Для Flutter — google_maps_flutter (официальный), flutter_map (OpenStreetMap + MapLibre, полностью open-source), mapbox_maps_flutter (после выхода официального SDK).

Пример выбора: приложение с офлайн-картами и геозонами на 100+ точек

Клиент — сеть розничных магазинов. Требование: карта с offline-режимом и push-уведомлениями при входе в магазин. Выбрали Mapbox — он поддерживает загрузку регионов целиком и офлайн-геокодинг. Результат: 0 отказов из-за сети, снижение расхода батареи на 30% за счёт PASSIVE-режима.

Почему геофенсинг срабатывает с задержкой?

Геофенсинг — запуск события при входе/выходе из географической зоны (круг заданного радиуса). На практике задержка может составлять 1–3 минуты — это плата за энергоэффективность.

На AndroidGeofencingClient из Google Location Services. Добавляем Geofence объекты с setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) и PendingIntent на BroadcastReceiver. Ограничение: максимум 100 активных геофенсов на приложение, минимальный радиус ~150 метров (на практике из-за точности), срабатывание с задержкой до нескольких минут в целях экономии батареи.

На iOSCLCircularRegion + CLLocationManager.startMonitoring(for:). Лимит: 20 регионов на приложение. ОС управляет когда проверять — разработчик не контролирует задержку. Для более точного геофенсинга с маленьким радиусом — iBeacon (CLBeaconRegion) или CLVisit для мест, где пользователь провёл время.

Если нужно больше 20 (iOS) или 100 (Android) зон — нужна серверная логика: периодически отправляем координаты на сервер, сервер проверяет попадание в зоны и отправляет push. Менее точно по времени, но масштабируется на тысячи зон. Википедия: Геозона — подробнее о принципах работы.

Трекинг маршрутов и фоновая геолокация

Трекинг маршрута пробежки или маршрута курьера в фоне — технически разные задачи.

На iOS фоновая геолокация работает через UIBackgroundModes: location в Info.plist. Без этого ключа при уходе приложения в фон CLLocationManager получает несколько минут и засыпает. С ключом — работает постоянно, но система может приостановить при критически низком заряде.

Для трекера пробежки на iOS паттерн: startUpdatingLocation при старте тренировки, координаты пишем в Core Data каждые 5 секунд, на паузе — stopUpdatingLocation, но оставляем startMonitoringSignificantLocationChanges чтобы приложение не «потерялось» совсем.

На Android для курьерского трекинга нужен Foreground Service с FOREGROUND_SERVICE_TYPE_LOCATION (обязательно с API 29). Foreground service показывает постоянное уведомление — это требование платформы, не баг. Без него Android Doze убьёт обновления геолокации. WorkManager для фоновых задач здесь не подходит — он не гарантирует непрерывность.

Алгоритмическая часть трекинга маршрута: сырые GPS-координаты зашумлены. Для сглаживания — алгоритм Ramer-Douglas-Peucker для упрощения трека или Kalman Filter для фильтрации шума в реальном времени. Без фильтрации трек выглядит как случайные зигзаги, а расчётное расстояние на 20–30% больше реального.

Как мы внедряем карты и геолокацию: пошаговый процесс

  1. Анализ сценариев — определяем, нужен ли foreground/background, точность, количество геозон, необходимость офлайн-режима.
  2. Выбор SDK и архитектуры — сравниваем Google Maps, Mapbox, HERE, MapKit по критериям проекта (наше сравнение выше — используйте как базу).
  3. Интеграция и настройка разрешений — прописываем Info.plist / AndroidManifest.xml, тестируем ревью-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
  4. Реализация трекинга/геозон — добавляем CLLocationManager / GeofencingClient, настраиваем фильтры и энергосбережение.
  5. Юнит- и интеграционное тестирование — на реальных устройствах (эмулятор не симулирует задержки и поведение Doze/App Nap). Проверяем не менее 50 сценариев.
  6. Нагрузочное тестирование — симулируем 500+ маркеров, движущиеся объекты, проверяем FPS и расход батареи.
  7. Деплой и мониторинг — выкладываем через TestFlight / Firebase App Distribution, собираем логи crashlytics, отслеживаем количество отказов разрешений.

Сроки и что входит в работу

Этап Срок Состав deliverables
Базовая интеграция карты с маркерами и поиском 1–2 недели Исходный код (Swift/Kotlin/Dart), документация API, инструкция по сборке
Геофенсинг с push-уведомлениями 2–3 недели Код геозон, настройка FCM/APNs, тестовые зоны, отчёт по задержкам
Полноценный трекинг маршрутов (фон, сглаживание, серверная синхр.) 4–6 недель Код с Kalman фильтром, серверная часть (опционально), мониторинг батареи

Что вы получите в любом случае:

  • Исходный код с комментариями (Swift, Kotlin, Dart, TypeScript)
  • Интеграцию с вашим бэкендом (REST/GraphQL/WebSocket)
  • Поддержку 1 месяц после сдачи (исправление багов, помощь с ревью сторов)
  • Инструкцию по публикации в App Store и Google Play (включая обоснование для background location)
  • Сертификаты code signing, provisioning profiles, ключи Google Maps/Mapbox

Наши компетенции: 10+ лет опыта в мобильной разработке, 50+ проектов с геолокацией, сертифицированные разработчики Apple и Google (Google Associate Android Developer). Каждое приложение проходит тройной код-ревью и нагрузочное тестирование.

Закажите внедрение карт и геолокации под ключ — свяжитесь с нами, чтобы получить консультацию и предварительную оценку вашего проекта в течение 2 часов.