Чому біговий застосунок втрачає точність на довгих дистанціях
Розробка бігового застосунку впирається в проблему, яку помічаєш не на тестовому колі, а на двадцятому кілометрі: трек починає «різати» повороти, темп стрибає, а пульс відстає від реальності на десятки секунд.
Причина не в одному збої, а в накопиченні: втрата сигналу GPS у щільній забудові або лісосмузі, дрейф датчика після зміни темпу, розсинхрон між потоком координат і потоком серцевого ритму, коли кожен пишеться своїм таймером.
Далі вмикається другий ефект — витрата батареї під час запису тренування. Постійне опитування GPS на високій частоті, утримання екрана, фонова синхронізація та перерахунок треку в реальному часі з'їдають заряд швидше, ніж триває сам забіг.
Користувач бачить знайоме: на останніх кілометрах телефон сідає, а разом із ним втрачається фінішний відрізок, заради якого все й записувалося.
Для продукту це дорожче, ніж здається. Неточність трекінгу пробіжок ламає довіру до цифр: бігун перестає вірити темпу та пульсовим зонам, перестає порівнювати свої відрізки й ділитися результатами. А розряд посеред забігу — це не «дрібний баг», а втрачене тренування й привід видалити застосунок.
Розбираємо, як це закривається на рівні архітектури запису, а не косметичними правками.
Що дає правильна архітектура: метрики, режими, обмеження
Де саме втрачаються дані та час
Три вузли визначають, чи переживе застосунок реальне тренування: фоновий трекінг тренувань при заблокованому екрані, поведінка застосунку при обриві мережі та відновлення сесії після того, як система вивантажила процес із пам'яті.
Помилка в будь-якому з них дає один і той самий клас відмов — «пробіжка записалася, але половина маршруту зникла». Архітектура мобільного застосунку вирішує це не «оптимізацією потім», а вибором моделі запису та синхронізації на старті.
Що дає вимірюваний ефект
- Локальний журнал точок із пакетним записом. Координати та пульс пишуться на диск одразу, а не накопичуються в пам'яті до відправлення. Частка втрачених точок при вивантаженні процесу падає з десятків відсотків до одиниць.
- Ідемпотентна офлайн-синхронізація даних. Кожне тренування отримує ідентифікатор на пристрої; повторне відправлення після обриву не створює дублів. Час відновлення сесії після збою мережі — секунди замість ручного перезапуску.
- Розділення запису та відображення. Карта й графіки читають із журналу, а не диктують темп запису. Інтерфейс не «залипає» на слабкому пристрої, а трек продовжує писатися при згорнутому застосунку.
- Явні стани сесії. Перерване тренування відновлюється з журналу з останньої валідної точки, а не починається заново.
Порівняння підходів до трекінгу
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Запис у пам'ять із відправленням у кінці | Короткі тренування, стабільна мережа | Втрата всієї сесії при вивантаженні процесу |
| Локальний журнал + пакетне відправлення | Основний сценарій бігового застосунку | Потрібна логіка злиття та ідемпотентності |
| Потокове відправлення в реальному часі | Трансляції, групові забіги | Витрата батареї, чутливість до обривів |
На практиці ми поєднуємо другий і третій режими: журнал як джерело істини, потік — як доповнення для живих сценаріїв. Такий шар синхронізації зручно будувати на SQLite з чергою вихідних операцій.
Опишіть сценарій тренувань і поточний стек — повернемося з оцінкою та планом щодо архітектури запису й синхронізації.
Етапи розробки бігового застосунку: від аудиту до передачі
Розробка бігового застосунку починається не з коду, а з розбору того, як застосунок поводитиметься в полі: на вулиці, без стабільного зв'язку, з розрядженим акумулятором і активним GPS.
Помилка в архітектурі на старті коштує найдорожче — її виправлення зачіпає і схему даних, і логіку трекінгу, і синхронізацію. Тому перші кроки присвячені вимогам і моделі даних, а не інтерфейсу.
Далі робота йде за етапами, кожен з яких закінчується перевірюваним результатом:
- Аудит вимог — фіксуємо сценарії: запис треку, пауза/відновлення, автопауза за зупинкою, робота у фоні, синхронізація після втрати мережі. На виході — узгоджений перелік функцій та обмежень.
- Схема даних і архітектура — проєктуємо зберігання точок маршруту, метрик (темп, пульс, дистанція) та офлайн-чергу відправлення. Визначаємо, що обчислюється на пристрої, а що на сервері.
- Налаштування трекінгу — вибір режиму геолокації, частота запису точок, фільтрація «тремтіння» GPS на старті та в щільній забудові. Тут же — фонова робота та коректна поведінка при згортанні.
- Перевірка на реальних маршрутах — тестуємо не в офісі, а на дистанції: ліс, тунель, щільна забудова, тривалий забіг. Звіряємо записаний трек з еталоном, дивимося витрату батареї та втрату точок.
- Передача проєкту — вихідний код, схема даних, інструкції зі збірки та релізу, доступи до сервісів, документація за ключовими модулями.
Окремий етап — приймання: прогін за чек-лістом сценаріїв разом із замовником, щоб поведінка застосунку на маршруті збіглася з очікуваннями до релізу, а не після.
Чим фоновий трекінг відрізняється від запису в активному режимі?
Активний режим запису — це коли екран увімкнений, застосунок на передньому плані, а потік даних із датчиків іде безперервно й з максимальною частотою опитування.
У цьому стані система віддає процесу пріоритет, геолокація оновлюється на кожному кроці, акселерометр і гіроскоп працюють на повній частоті, а трек пишеться без пропусків.
Ціна такої точності — постійне навантаження на процесор і радіомодуль: за годину забігу такий режим здатен з'їсти помітну частку заряду, тому його тримають лише на коротких відрізках, де важлива кожна секунда.
Фоновий трекінг влаштований принципово інакше. Коли застосунок згорнуто або екран погашено, операційна система переводить його в окремий режим роботи у фоні й починає керувати частотою оновлень сама.
Замість безперервного потоку надходять пакетні оновлення — система будить процес рідше, групує події та віддає їх пачкою.
Це економить батарею, але між пробудженнями можуть губитися проміжні точки: на різких поворотах, під мостами та в щільній міській забудові трек стає грубішим, а дистанція й темп — менш точними.
Ключова різниця — у тому, хто ухвалює рішення про частоту опитування. В активному режимі це робить застосунок, у фоновому — операційна система, виходячи з політики енергозбереження та поточного стану пристрою.
Звідси й різні сценарії: активний режим підходить для інтервальних тренувань і коротких забігів, де потрібна посекундна точність, фоновий — для довгих дистанцій, де важливіше, щоб телефон дожив до фінішу.
На практиці грамотна розробка бігового застосунку не обирає один режим, а перемикається між ними за умовою.
Поки користувач дивиться на екран — іде активний запис; екран погас — застосунок переходить у фоновий режим із розумною частотою оновлень, а при поверненні до активності наздоганяє трек за накопиченим буфером.
Додатково згладжують дані фільтрами та відсікають викиди, щоб ривки GPS не псували підсумкову дистанцію.
Саме тому коректна робота застосунку у фоні — не одне налаштування, а зв'язка рішень: дозволи на фонову геолокацію, обробка пауз і відновлення після згортання, буферизація точок і акуратна синхронізація із сервером. Помилка в будь-якій із ланок дає або рваний трек, або розряджений телефон на середині дистанції.
Кейс: як ми скоротили втрату точок на 40% і прискорили синхронізацію
Замовник прийшов із працюючим біговим застосунком: трек маршруту писався на пристрої, а на сервер ішов пачками при появі мережі.
На довгих забігах у лісистій місцевості та в метро сесія рвалася, буфер переповнювався, і частина треку губилася безповоротно — користувач бачив «дірку» в маршруті й ішов до конкурента.
За логами частка втрачених точок сягала 12% на забігах довших за півтори години, а синхронізація після відновлення мережі займала до 40 секунд, блокуючи інтерфейс.
Що змінили в записі та передачі треку
Ми розвели запис і надсилання: точки пишуться в локальне сховище пристрою потоково, з фіксацією кожної в журналі до підтвердження запису на диск.
Надсилання йде окремим каналом — невеликими пакетами з ідемпотентними ідентифікаторами, тому повторна передача після обриву не створює дублів. Черга обмежена за розміром, а не за часом: при переповненні витісняються вже підтверджені точки, а не свіжі.
Що стало за метриками
Частка втрачених точок упала з 12% до 7% — тобто на 40% менше, і майже всі решта втрат припадають на випадки, коли користувач закриває застосунок примусово. Синхронізація після відновлення мережі скоротилася з 40 до 6 секунд: пакети йдуть паралельно, а не строго по одному.
Стабільність сесії зросла — розривів на забігах довших за дві години стало втричі менше, бо фоновий режим більше не залежить від одного довгого запиту.
| Було | Стало |
|---|---|
| Втрата точок — 12% | 7% (−40%) |
| Синхронізація — до 40 с | до 6 с |
| Розривів сесії на довгих забігах — базова лінія | втричі менше |
Ключовий інструмент тут — локальна черга з ідемпотентним записом: вона перетворює «надіслати й сподіватися» на «записати й дослати».
Для контролю цілісності треку ми звірили відновлені маршрути з еталонними записами з годинників — розбіжність за дистанцією вклалася в частки відсотка.
WorkManager
Сумніви щодо сумісності, міграції та доступів — розбираємо
Перед стартом розробки бігового застосунку майже завжди виринають одні й ті самі питання: як новий сервіс уживеться з уже працюючою інфраструктурою, що буде з накопиченою статистикою тренувань, чи можна відкотити реліз, якщо щось піде не так, і хто отримає доступи до продакшену.
Це не формальності — саме тут найчастіше ламаються інтеграції, тому ми розбираємо кожен пункт до першого рядка коду.
Сумісність з існуючою інфраструктурою. Мобільний клієнт спілкується з бекендом через версіонований API, тому старі збірки застосунку продовжують працювати, поки користувачі не оновляться.
Якщо у вас уже є акаунти, платіжний шлюз або сервіс авторизації — підключаємося до них через адаптери, не переписуючи працюючі системи. Схему сумісності фіксуємо в документі до початку робіт.
Міграція даних. Історія пробіжок, GPS-треки, пульсові зони та профілі переносяться за заздалегідь узгодженим планом: спочатку пробний прогін на копії, звірка контрольних сум, потім перенесення на бойові дані.
Зворотна міграція теж передбачена — якщо знадобиться повернутися до попередньої системи, дані не загубляться.
Відкат змін. Кожен реліз — окрема версія з можливістю відкату на попередню. Оновлення викочуються поступово, на частину аудиторії, щоб зловити проблему до масового релізу.
Що буде із застосунком, якщо користувачі не оновляться?
Старі версії продовжують працювати з попереднім API. Ми підтримуємо зворотну сумісність мінімум на кілька релізів уперед, а примусове оновлення вмикаємо лише за критичних змін — і попереджаємо користувачів заздалегідь.
Доступи та права. Продакшен, стейджинг і репозиторії — під вашим контролем: ви власник акаунтів, ми працюємо за виданими ролями з обмеженими правами. Усі дії логуються, доступи можна відкликати в будь-який момент.
Що ви отримаєте на руки по завершенні:
- вихідний код застосунку та серверної частини у вашому репозиторії;
- схему інтеграцій з існуючими сервісами;
- документацію з міграції та відкату даних;
- налаштовані середовища та політики доступів;
- інструкції зі збірки, публікації та оновлення релізів;
- регламент підтримки та передачі прав володіння.
Опишіть вашу поточну інфраструктуру та задачу — повернемося з оцінкою та планом робіт.
Терміни етапів впровадження: що і коли відбувається
Розробка бігового застосунку розбивається на етапи з чіткими межами: після кожного видно результат і можна скоригувати курс без переробки готового.
Орієнтовні терміни нижче — для типового трекера із записом маршруту, статистикою, синхронізацією з носимими пристроями та особистим кабінетом. Точний план робіт фіксуємо після аудиту: на нього впливають кількість платформ, глибина інтеграцій і вимоги до офлайн-режиму.
Терміни впровадження стискаються, якщо випускати спочатку одну платформу і додавати другу після перевірки гіпотез на живих користувачах. Паралельно готуємо інфраструктуру: збірку, автотести, канали оновлень — це прибирає ручні операції при кожному релізі.
Що якщо потрібен запуск до дати? Збираємо урізану першу версію з ядром і відкладаємо другорядне, не чіпаючи архітектуру — розширення йде без переписування.
Що якщо вимоги зміняться в процесі? План робіт перезбираємо на межі етапу, обсяг і терміни узгоджуємо заново.
Опишіть задачу — повернемося з оцінкою та планом за етапами.
