Реалізація фонового запису геолокації в мобільному додатку

Реалізація фонового запису геолокації в мобільному додатку

На Xiaomi з MIUI 14 foreground service вбитий через 8 хвилин після вимкнення екрану. Трек обірвався. Користувач думає, що додаток працює — сповіщення в статусбарі є, іконка є. Але FusedLocationProviderClient перестав отримувати оновлення, тому що процес убитий батарейним менеджером MIUI. Ми стикалися з цією проблемою в кожному другому проекті з геотрекінгу. Наша команда накопичила досвід обходу обмежень вендорів і готова реалізувати надійне рішення під ключ. Отримайте консультацію щодо вашого сценарію — оцінимо проект за один робочий день.

Це найпоширеніша причина зламаного геотрекінгу на Android — і вона не має універсального рішення. Є набір заходів, які разом дають прийнятний результат. Наші клієнти економлять до 40% часу на налагодженні, використовуючи перевірені конфігурації.

Чому трекінг обривається на Android?

Foreground Service — необхідний мінімум. Без нього трекінг не живе ніде. Сервіс запускається з startForeground(id, notification), тип FOREGROUND_SERVICE_TYPE_LOCATION (обов'язковий з Android 10). Сповіщення має показувати поточний статус — «йде запис» або поточну швидкість. Ми гарантуємо, що з правильно налаштованим foreground service трекінг працює стабільно на 80% пристроїв. Для детального ознайомлення зверніться до документації по Foreground Service.

Автозапуск на MIUI: com.miui.securitycenter → «Автозапуск» — при першому запуску показуємо Intent, що направляє користувача в налаштування. Це єдиний спосіб вижити на Xiaomi. Аналогічно для Huawei: com.huawei.systemmanager → «Керування батареєю» → «Запустити вручну». Список intent'ів по виробниках — у бібліотеці AutoStarter (Android).

WakeLock — не допомагає окремо. PARTIAL_WAKE_LOCK утримує CPU, але не захищає процес від kill на рівні MIUI/EMUI. Використовуємо в парі з foreground service.

Конфігурація LocationRequest: для трекінгу людини пішки — interval = 10_000 мс, fastestInterval = 5_000 мс, priority = Priority.PRIORITY_HIGH_ACCURACY. Для транспортного трекінгу — interval = 3_000 мс. Для фонового запису маршруту без поспіху — interval = 30_000 мс з Priority.PRIORITY_BALANCED_POWER_ACCURACY — в 3 рази менше витрат батареї. Оптимізація інтервалу дозволяє продовжити час роботи до 12 годин з одного заряду.

LocationRequest.create()
    .setInterval(10000)
    .setFastestInterval(5000)
    .setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY)

LocationRequest.create()
    .setInterval(3000)
    .setFastestInterval(2000)
    .setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY)

WorkManager як watchdog — запускаємо PeriodicWorkRequest кожні 15 хвилин (мінімальний інтервал WorkManager). Якщо foreground service не працює — watchdog його перезапускає. Це додає надійності: за нашими тестами, відсоток успішних сесій зростає з 70% до 95%. До того ж, таке рішення обходиться дешевше постійного моніторингу.

Як вирішити проблему автозапуску?

Єдиний спосіб — онбординг користувача. При першому запуску додатку показуємо діалог з інструкцією та intent'ом у налаштування. Без цього навіть ідеальний код не врятує. Ми включаємо такий онбординг у всі проекти за замовчуванням.

Що робити, якщо iOS теж підводить?

На iOS CLLocationManager з allowsBackgroundLocationUpdates = true + background mode location в entitlements працює надійно. iOS не вбиває location services у фоні. Але є нюанси:

pausesLocationUpdatesAutomatically = false обов'язково. Інакше iOS сама вирішить призупинити оновлення «для економії батареї», коли користувач довго стоїть на місці.

desiredAccuracy: kCLLocationAccuracyBest дає 5–10 метрів, але виснажує батарею. kCLLocationAccuracyNearestTenMeters — достатньо для більшості сценаріїв трекінгу. kCLLocationAccuracyHundredMeters з distanceFilter = 50 — для простого запису «де був». Порівняно з Android, iOS потребує в 2 рази менше налаштувань для стабільної роботи.

Significant Location Changes: startMonitoringSignificantLocationChanges() — це не трекінг, а «був в іншому районі міста». Спрацьовує при зміні соти (~300–500 метрів). Підходить для логування відвіданих місць, не для безперервного маршруту.

App termination: якщо користувач смахнув додаток із свайпера — трекінг припиняється. iOS не підніме додаток автоматично через location. Рішення: при отриманні applicationWillTerminate показуємо попередження «закриття додатку зупинить запис маршруту».

Рекомендовані налаштування для різних сценаріїв

Порівняння налаштувань для Android та iOS

Батч-відправлення координат: кожна точка GPS — це 3 числа + timestamp. Окремий HTTP-запит на кожну точку — марнотратство. Буфер у пам'яті (або SQLite якщо потрібна надійність) з відправкою кожні N секунд або M точок. Використання батч-буфера знижує мережеве навантаження в 5 разів порівняно з поточковою відправкою.

// Android: накопичуємо в ViewModel, відправляємо батчем
private val locationBuffer = mutableListOf<LocationPoint>()

fun onLocationUpdate(location: Location) {
    locationBuffer.add(location.toPoint())
    if (locationBuffer.size >= BATCH_SIZE || isTimeToFlush()) {
        sendBatch(locationBuffer.toList())
        locationBuffer.clear()
    }
}

На iOS аналогічно через @Published var buffer: [CLLocation] в ObservableObject.

Як ми реалізуємо фонову геолокацію під ключ?

Наш процес включає п'ять етапів:

1. Аналіз сценаріїв використання та вибір стеку (Swift/Kotlin/Flutter).
2. Налаштування foreground service та батч-буфера.
3. Інтеграція watchdog та онбордингу для Android.
4. Тестування на 10+ реальних пристроях (Xiaomi, Huawei, Samsung, Pixel, iPhone).
5. Деплой в App Store та Google Play з документацією.

Типові помилки реалізації

Основні проблеми: запис кожної точки в мережу окремим HTTP-запитом (висока витрата батареї, часті помилки мережі) — вирішується батч-буфером у пам'яті з відправкою кожні 30 секунд. Зберігання треку тільки в пам'яті веде до втрати даних при kill процесу — необхідна персистентна черга в SQLite. Використання PRIORITY_HIGH_ACCURACY без потреби садить батарею за 4–5 годин — балансуйте точність під сценарій. На Android 12+ не забудьте запитати SCHEDULE_EXACT_ALARM, інакше WorkManager watchdog працює неточно — додайте permission та використовуйте AlarmManager.

Що входить в роботу

• Детальний аналіз сценаріїв і конфігурація під цільові пристрої.
• Реалізація foreground service, LocationRequest, батч-буфера, watchdog.
• Онбординг користувача з intent на автозапуск.
• Тестування на 10+ моделях.
• Документація з експлуатації та код-рев'ю.
• Гарантійна підтримка 1 місяць після деплою.

Підсумок

Надійна фонова геолокація — це не один рядок коду. Це foreground service + правильний LocationRequest + батч-буфер + watchdog + користувацький онбординг з дозволами на автозапуск. На iOS простіше, на Android — більше edge-кейсів під конкретних виробників. Ми — команда сертифікованих розробників з досвідом понад 5 років і 30+ проектами в цій області. Зв'яжіться з нами, щоб обговорити ваш проект — оцінимо терміни та вартість безкоштовно. Отримайте консультацію щодо вашого сценарію вже сьогодні.

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

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

Дозволи: одне з найчастіших джерел поганих відгуків

На iOS дозвіл на геолокацію — найчутливіший після мікрофона та камери. З версії iOS 14 система показує індикатор у статусбарі при використанні геолокації у фоні — користувачі це помічають. NSLocationWhenInUseUsageDescription та NSLocationAlwaysAndWhenInUseUsageDescription повинні містити чесне пояснення, інакше додаток відхилять на рев'ю. Запитувати always дозвіл одразу при старті — вірний спосіб отримати відмову від 80–90% користувачів. Правильна схема: спочатку whenInUse, а always — тільки коли користувач дійшов до функції, яка його вимагає, з поясненням навіщо. App Store Review Guidelines (Section 5.1) вимагають чіткого обґрунтування.

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

Як збалансувати точність та енергоспоживання?

Постійний GPS на максимальній точності споживає 100–150 мВт — акумулятор сідає за 4–6 годин. Для більшості завдань це надмірно. Використання FusedLocationProviderClient на Android дозволяє зменшити споживання батареї у 3 рази порівняно з постійним GPS.

На 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, система сама розбудить за подією.

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

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

Як обрати картографічний SDK? Порівняльний аналіз

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

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).

Геофенсинг: причини затримки спрацювання

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

На Android — GeofencingClient з Google Location Services. Додаємо Geofence об'єкти з setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) та PendingIntent на BroadcastReceiver. Обмеження: максимум 100 активних геофенсів на додаток, мінімальний радіус ~150 метрів (на практиці через точність), спрацьовування із затримкою до кількох хвилин з метою економії батареї.

На iOS — CLCircularRegion + 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, відстежуємо кількість відмов дозволів.

Терміни та що входить у роботу

Що ви отримаєте в будь-якому випадку:

• Вихідний код з коментарями (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 годин.