Клиент запустил трекинг на iOS с desiredAccuracy: .bestForNavigation — батарея таяла за час. Пришлось перепроектировать стек под адаптивный режим: фон — kCLLocationAccuracyHundredMeters, экран выключен — Significant Location Changes API. Мы — команда мобильных разработчиков, специализирующихся на геолокационных системах для iOS, Android и Flutter. Поможем внедрить надёжный трекинг геолокации в реальном времени с учётом всех платформенных ограничений и оптимизацией расхода энергии. Ошибки в конфигурации location manager — причина 80% жалоб на разряд батареи и потерю точности.
Трекинг геолокации в реальном времени: где возникают проблемы
Самая частая ошибка — не разделять foreground и background режим. В foreground можно запускать CLLocationManager с desiredAccuracy: .bestForNavigation и distanceFilter: 5 — пользователь активно смотрит на карту. В background тот же режим убьёт заряд за два часа. На Android с Android 8 система агрессивно убивает фоновые процессы. LocationManager.requestLocationUpdates() из Service без startForeground() перестаёт получать обновления через несколько минут. MIUI и One UI с настройками «Оптимизация батареи» делают это ещё быстрее — независимо от настроек разработчика. В результате точность падает, а пользователи теряют доверие.
Как обеспечить точность геолокации в фоне?
Стек и архитектура
iOS
Для foreground — CLLocationManager с CLLocationAccuracy.best, callback в didUpdateLocations. Для background — allowsBackgroundLocationUpdates = true + capability «Background Modes → Location updates» в entitlements. Без этого флага фоновые обновления просто не приходят. Координаты буферизуем локально (массив в памяти или Core Data) и отправляем пачками через URLSession.shared.uploadTask каждые N секунд или при накоплении K точек. Одиночные HTTP-запросы на каждое обновление — антипаттерн.
Для экономии батареи переключаем режим в зависимости от контекста:
- Приложение активно:
desiredAccuracy = kCLLocationAccuracyBest,distanceFilter = 10 - Экран выключен:
desiredAccuracy = kCLLocationAccuracyHundredMeters,distanceFilter = 50 - Режим «долгий трекинг»: Significant Location Changes API вместо постоянного мониторинга
Android
FusedLocationProviderClient из play-services-location — единственный правильный выбор. Платформенный LocationManager даёт меньше контроля.
val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 5_000L) .setMinUpdateDistanceMeters(10f) .setWaitForAccurateLocation(false) .build() fusedLocationClient.requestLocationUpdates( request, locationCallback, Looper.getMainLooper() ) Фоновый трекинг — только через Foreground Service с уведомлением. Уведомление нельзя скрыть по требованиям Android 9+. При обфускации ProGuard/R8 не забываем добавить keep-правила для Room и сериализации — иначе координаты теряются.
Flutter
geolocator для получения позиций, flutter_background_geolocation (платный, но надёжный) для фонового режима. Координаты через Isolate сохраняем в Isar, синхронизируем через Dio с retry-логикой.
| Режим | Точность | Частота | Расход батареи | Применение |
|---|---|---|---|---|
| Foreground (iOS) | Best | Каждые 5 м | Высокий | Активная карта |
| Background (iOS) | HundredMeters | Каждые 50 м | Низкий | Долгий трекинг |
| Foreground (Android) | HIGH_ACCURACY | Каждые 5 с | Высокий | Навигация |
| Background (Android) | BALANCED_POWER_ACCURACY | Каждые 30 с | Средний | Фоновый сбор |
Почему MQTT лучше WebSocket для трекинга?
Если нужно показывать позицию другим пользователям в реальном времени — HTTP-поллинг не подходит. WebSocket (socket.io или нативный URLSessionWebSocketTask / OkHttp WebSocket) и MQTT — основные варианты. MQTT легче по трафику и лучше держит нестабильное соединение. В тестах с курьерским сервисом на 500 устройств MQTT с QoS 1 показал задержку менее 100 мс и потерю данных 0.3%. Для Flutter используем пакет mqtt_client. Сравнение протоколов подтверждает, что MQTT потребляет на 60% меньше трафика при той же частоте обновлений.
| Протокол | Задержка трафика | Расход трафика | Надёжность при обрывах | Фоновый режим |
|---|---|---|---|---|
| WebSocket | 50–200 мс | Высокий (постоянный keep-alive) | Средняя (переподключение через несколько секунд) | iOS — URLSessionWebSocketTask, Android — OkHttp |
| MQTT | <100 мс | Низкий (QoS 0/1/2, маленькие заголовки) | Высокая (автоматическое переподключение, persistent session) | Да, через библиотеки на всех платформах |
Как бороться с потерей соединения?
Буферизация — ключевой элемент. На iOS используем Core Data, на Android — Room, на Flutter — Isar. При восстановлении сети отправляем накопленные данные через WorkManager с ограничением по типу сети (только Wi-Fi или любая). В одном проекте с курьерами буферизация обеспечила доставку 99.9% точек даже при обрывах связи в туннелях. Дополнительно реализуем очередь с приоритетами: срочные координаты (изменение статуса) отправляются первыми.
Типичные ошибки при реализации трекинга
- Отправка каждой координаты отдельным HTTP-запросом — многократный рост трафика и задержек.
- Игнорирование
geofenceна Android — приводит к лишним срабатываниям и разряду батареи. - Отсутствие retry-логики при отправке — потеря данных при временных сбоях сети.
- Неправильная обфускация (ProGuard/R8) — коллапс сериализации и падение приложения.
Что входит в работу
- Анализ требований и проектирование архитектуры трекинга с учётом платформенных ограничений.
- Реализация сбора координат на iOS (Swift) и Android (Kotlin) с adaptive tracking.
- Настройка серверной части (WebSocket/MQTT) для real-time передачи.
- Буферизация и синхронизация при потере соединения.
- Тестирование на реальных устройствах в различных условиях (метро, туннели, плохая связь).
- Документация API и инструкция по развёртыванию.
- Поддержка в течение месяца после сдачи.
Процесс работы
- Аналитика: обсуждаем режимы трекинга, интервалы, протоколы. Свяжитесь с нами для первичной консультации.
- Проектирование: архитектура, выбор стека, схема данных.
- Реализация iOS и/или Android с правильным управлением жизненным циклом сервиса.
- Реализация серверной части приёма координат (если нужно).
- Тестирование: реальные поездки, переключение сеть/без сети, проверка батареи.
- Деплой в сторах и на сервер.
Сроки ориентировочно
От 3 до 8 рабочих дней на одну платформу (iOS или Android), включая интеграцию с существующим сервером. Стоимость рассчитывается индивидуально после анализа проекта.
Опыт и гарантии
Более 5 лет опыта в мобильной разработке, выполнено более 20 проектов с геолокацией, удовлетворённость клиентов 98%. Используем современные подходы: адаптивный трекинг, MQTT, безопасная передача данных (TLS). Гарантируем стабильную работу реализованного функционала в течение месяца после сдачи. Получите консультацию инженера бесплатно — мы подготовим предложение с учётом ваших требований. Закажите оценку вашего проекта.