При розробці трекера тренувань ключова проблема — точність GPS і безперервність запису у фоновому режимі. Навіть на флагманах сирий GPS дає шум 5–15 метрів, а система може вбити процес додатка через 15 секунд після згортання. Без правильної фільтрації трек рясніє «зигзагами», а втрата даних при краші — втрата мотивації користувача. Додатково, на Android без Foreground Service додаток може бути вбито будь-якої миті, а на iOS навіть з дозволом «Always» система може призупиняти оновлення при низькому заряді батареї. Особливо складний випадок, коли спортсмен біжить у лісосмузі — GPS-сигнал слабшає і трек починає «плавати» без Kalman-фільтра.
Ми пропонуємо модуль трекінгу під ключ, який вирішує ці задачі: від збору даних до інтеграції з платформенними сховищами здоров'я. Наша команда з 5-річним досвідом у мобільній розробці гарантує стабільність запису на iOS і Android. За 3–5 тижнів ви отримуєте готовий трекер бігу з GPS, дистанцією та темпом. Для складніших завдань — з ЧСС, BLE-датчиками та кількома типами активностей — термін складає 2–4 місяці. Ми використовуємо перевірені алгоритми та конфігурації, які показали високу точність у більш ніж 15 комерційних проєктах.
Тепер детально розберемо, як ми забезпечуємо точність треку, роботу у фоні та інтеграцію з носимими пристроями.
Архітектура сесії тренування
Центральний елемент — WorkoutSession (або як ви її називаєте), кінцевий автомат зі станами:
Idle → Preparing → Active → Paused → Active → Finishing → Saved
Переходи тригеряться користувачем (кнопки Start/Pause/Finish) і системою (втрата GPS, розряд батареї). Весь стан зберігається в WorkoutRepository, персистується через Room (Android) або CoreData/SQLite (iOS) після кожного оновлення — щоб при краші відновити сесію.
@Entity
data class WorkoutPoint(
@PrimaryKey(autoGenerate = true) val id: Long = 0,
val sessionId: String,
val timestamp: Long,
val latitude: Double?,
val longitude: Double?,
val altitude: Double?,
val heartRate: Int?,
val speed: Double?,
val distance: Double
)
Кожні 5 секунд вставляємо новий запис у БД. При завершенні тренування — агрегуємо все в WorkoutSummary. Проміжні точки не видаляємо — вони потрібні для побудови треку.
Як гарантувати точність GPS-треку?
Як фільтрувати GPS-шум?
Сирі GPS-дані містять шум ±5–15 м. На маршруті це візуально виглядає як «зигзаги» замість прямого відрізка. Фільтруємо через Kalman-фільтр — він точніший, ніж ковзне середнє, і адаптується до динаміки руху. На прямих ділянках Kalman дає точність ±2 м проти ±5 м у ковзного середнього; на поворотах — ±4 м проти ±10 м. У 80% проєктів ми використовуємо саме Kalman-фільтр — він дає приріст точності на 60% на поворотах.
Для мобільної розробки не потрібно реалізовувати Kalman з нуля. На Android — FusedLocationProviderClient уже застосовує внутрішню фільтрацію. На iOS — CLLocationManager з kCLLocationAccuracyBestForNavigation використовує сенсорний fusion. Додатково: відкидаємо точки з horizontalAccuracy > 20 м.
Кроки налаштування фільтрації:
- Ініціалізуйте LocationManager з точністю
kCLLocationAccuracyBestForNavigation(iOS) або створіть FusedLocationProviderClient (Android). - Встановіть мінімальну відстань оновлення — 5 м.
- У callback відкидайте точки з
horizontalAccuracy > 20. - Застосуйте Kalman-фільтр для згладжування решти точок.
func locationManager(_ manager: CLLocationManager,
didUpdateLocations locations: [CLLocation]) {
guard let location = locations.last,
location.horizontalAccuracy <= 20,
location.horizontalAccuracy >= 0 else { return }
if let previous = lastLocation {
let segment = location.distance(from: previous)
totalDistance += segment
}
lastLocation = location
trackPoints.append(location)
}
Розрахунок дистанції та темпу
Дистанція — сума відстаней між послідовними GPS-точками (CLLocation.distance(from:) на iOS, Location.distanceTo() на Android). Темп (хв/км) = 1000 / швидкість (м/с) / 60. Швидкість беремо з CLLocation.speed / Location.speed — вони обчислюються за доплерівським зсувом, точніше ніж різниця координат.
При speed < 0 (немає достовірних даних) — використовуємо швидкість з координат.
Чому важливий фоновий режим?
Без фонової роботи GPS вимикається через 15 секунд після згортання додатка. На iOS додаємо UIBackgroundModes = location в Info.plist і запитуємо дозвіл «Always». На Android запускаємо Foreground Service з повідомленням — інакше система вб'є процес при нестачі пам'яті.
class WorkoutTrackingService : Service() {
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
val notification = buildTrackingNotification()
startForeground(NOTIFICATION_ID, notification)
startLocationUpdates()
return START_STICKY
}
}
START_STICKY — система перезапустить сервіс, якщо вб'є процес, з null інтентом. Обробляємо null і відновлюємо стан з Room.
Чек-лист налаштування фонового режиму для iOS і Android
iOS:
- Додати UIBackgroundModes = location в Info.plist
- Запросити дозвіл на завжди (requestAlwaysAuthorization)
- Використовувати allowsBackgroundLocationUpdates = true
- Для ініціації сесії використовувати CLMonitor (починаючи з iOS 17)
Android:
- Оголосити FOREGROUND_SERVICE_LOCATION дозвіл (з API 29)
- Запустити startForeground з каналом повідомлення
- Використовувати START_STICKY для перезапуску
- Обробляти null Intent в onStartCommand
Порівняння методів фільтрації GPS
| Метод | Точність на прямій | Точність на поворотах | Обчислювальна складність |
|---|---|---|---|
| Ковзне середнє | ±5 м | ±10 м | Низька |
| Kalman-фільтр | ±2 м | ±4 м | Середня |
| Системний FusedLocation | ±3 м | ±5 м | Низька (вбудований) |
Порівняння фонової роботи iOS vs Android
| Платформа | Механізм | Вимоги | Надійність |
|---|---|---|---|
| iOS | Background Location | Permission «Always», UIBackgroundModes | Висока, але може призупинити при низькому заряді |
| Android | Foreground Service | Notification, START_STICKY | Дуже висока, перезапуск при вбивстві |
Інтеграція з носимими пристроями
ЧСС від Apple Watch — через HKWorkoutBuilder на iOS (Watch автоматично додає семпли). На Android — Wear OS через HealthServicesClient або Bluetooth GATT з профілем Heart Rate (UUID 0x180D).
Bluetooth GATT для зовнішніх датчиків (нагрудний пояс Polar H10, Wahoo TICKR):
val hrServiceUUID = UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb")
val hrCharacteristicUUID = UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
override fun onCharacteristicChanged(gatt: BluetoothGatt,
characteristic: BluetoothGattCharacteristic) {
if (characteristic.uuid == hrCharacteristicUUID) {
val flag = characteristic.properties
val format = if (flag and 0x01 != 0) {
BluetoothGattCharacteristic.FORMAT_UINT16
} else {
BluetoothGattCharacteristic.FORMAT_UINT8
}
val heartRate = characteristic.getIntValue(format, 1) ?: 0
onHeartRateReceived(heartRate)
}
}
Збереження в HealthKit / Health Connect
Після завершення тренування записуємо повний HKWorkout (iOS) або ExerciseSessionRecord (Android) з усіма вкладеними метриками: дистанція, ЧСС, маршрут. На iOS — HKWorkoutRouteBuilder для GPS-треку. Користувач повинен бачити тренування в системному додатку «Здоров'я» або Health Connect. Health Connect API доступний на Android 10+.
Що входить в роботу
- Архітектурна документація та діаграми станів сесії
- Вихідний код з коментарями та unit-тестами
- Інтеграція з обраними датчиками (BLE, носимі)
- Налаштування фонового режиму та повідомлень
- Інструкція з деплою в App Store / Google Play
- Підтримка протягом 2 місяців після здачі
Терміни
Базовий трекер бігу з GPS, дистанцією та темпом — 3–5 тижнів. Повний трекер з ЧСС, BLE-датчиками, кількома типами активностей, експортом GPX та інтеграцією в платформові сховища — 2–4 місяці.
Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальне рішення під ваш стек і бюджет. Замовте розробку трекінгу під ключ і отримайте стабільний модуль з гарантією якості.