Клієнт запустив трекінг на 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). Гарантуємо стабільну роботу реалізованого функціоналу протягом місяця після здачі. Отримайте консультацію інженера безкоштовно — ми підготуємо пропозицію з урахуванням ваших вимог. Замовте оцінку вашого проекту.