Чому застосунок для скелелазіння ламається на реальній скелі
У залі застосунок малює рівний трек, а на реальній скелі за двадцять хвилин запису лінія з'їжджає на сусідній сектор, висота стрибає на десятки метрів, а заряд падає вдвічі.
Річ не в інтерфейсі: так поводиться зв'язка приймача позиціонування, офлайн-карт і датчиків руху там, де її ніхто не калібрував.
Втрата сигналу GPS в ущелині — перша причина. Вузька стіна затіняє половину небосхилу, а відбиті від породи сигнали приходять із затримкою, і приймач сприймає їх за прямі.
На від'ємних схилах видно два-три супутники, точність визначення позиції сягає десятків метрів, і застосунок дома льовує пряму через рельєф від останньої відомої точки.
Офлайн карти скель додають розсинхрон: тайли, завантажені заздалегідь, прив'язані до координатної сітки, а топологія сектора огрублена до схеми. Трек лягає поруч із маршрутом, а не на нього, і логіка «ви на лінії» спрацьовує там, де лінії немає.
Витрата батареї під час запису треку складається з дрібниць: часте опитування приймача, постійно увімкнений екран, запис координат по одній замість пакетного, фонові синхронізації.
Акселерометр додає хибні спрацьовування — рух по скелі це ривки, зміна орієнтації корпусу та вібрація, а не рівний крок, тому авто-пауза треку й підрахунок підйомів помиляються.
Розбираємо, як це закривається: адаптивна частота опитування, локальний буфер записів, звірка треку з топологією маршруту та пороги датчиків, налаштовані під скелелазіння, а не під біг.
Що дає стійкий застосунок: метрики та ефект
Застосунок для скелелазіння перевіряється не на демонстрації, а на стіні в ущелині, де зв'язку немає.
Тому вимірювані показники ми фіксуємо з самого початку: частка маршрутів, записаних без втрат, час відновлення після обриву зв'язку, швидкість синхронізації завантажених областей карти, відгук інтерфейсу на дотик.
Офлайн-режим роботи тут базова умова, а не додаткова можливість. Трек пишеться локально з точністю, достатньою для розбору проходження: ключові точки, темп, паузи на страховку.
Коли мережа з'являється, синхронізація треків довантажує лише відсутні фрагменти, а не переписує маршрут повністю.
Стійкість до обриву зв'язку вимірюємо часом до повного відновлення запису після повернення в мережу: буфер залишається на пристрої, тому втрата сигналу в середині підйому не перетворюється на діру в треку.
Окремо знімаємо клас відмов, який раніше псував статистику, — накладання треків під час повторного проходження того самого маршруту. Розділення сесій за часом старту та ідентифікатором проходження прибирає накладання, і дані по маршруту рахуються коректно.
Точність трекінгу та час відгуку інтерфейсу пов'язані напряму. Підвантаження області карти йде у фоні й не блокує екран, тому карта довантажується, поки користувач читає опис, а інтерфейс відповідає на дотик без затримки.
На виході — передбачувана картина: проходження перестають губитися, повторні заходження на маршрут більше не зливаються в один запис, а відновлення після втрати сигналу займає секунди й не потребує ручних дій.
Варіанти реалізації: нативний, кросплатформний, гібридний
Для застосунку скелелазіння вибір між підходами визначає не зовнішній вигляд екранів, а три обмеження: доступ до датчиків пристрою, робота без мережі та швидкість випуску оновлень.
Трекінг підходів і часу відпочинку спирається на акселерометр і гіроскоп, а зв'язка з пульсометром або трекером іде по Bluetooth — тут важлива частота опитування і те, чи дозволяє платформа фонову роботу.
Офлайн сховище даних — другий за значущістю фактор: у залі та на скелі зв'язку немає, тому запис тренування лягає в локальну базу, а черга на відправлення йде на сервер, коли мережа з'явилася.
Від того, наскільки глибоко шар даних вбудований у платформу, залежить, чи переживе підхід згортання застосунку і як швидко виправлення доїде до користувачів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативна розробка | Потрібен максимальний доступ до датчиків пристрою, фоновий запис і відгук інтерфейсу на обох платформах | Дві кодові бази, релізи йдуть паралельно, оновлення виходять повільніше |
| Кросплатформна розробка | Спільна логіка, каталог трас, щоденник тренувань і особистий кабінет на одному коді для iOS та Android | Звернення до датчиків і Bluetooth доводиться перевіряти на кожному пристрої, частину фонових сценаріїв дописують окремо |
| Гібридний застосунок | Розділи часто змінюються, важлива швидкість випуску без повторної публікації в магазинах | Урізаний доступ до датчиків і офлайн сховища, важкий трекінг упирається у веб-шар |
На практиці підходи комбінують: трекінг і запис підходів віддають нативному шару, а каталог залів, описи трас і розбори — спільному коду, який оновлюється без перезбирання.
Ми розмічаємо сценарії за потрібним рівнем доступу до заліза і тільки після цього обираємо схему — інакше застосунок упирається в стелю платформи вже на етапі бета-тестування.
Етапи розробки застосунку для скелелазіння
Застосунок для скелелазіння працює у двох режимах: удома, де зв'язок стабільний, і на масиві, де його немає. Руки зайняті, телефон у кишені, екран читається на сонці — тому порядок робіт ми будуємо навколо офлайн-ядра, а не навколо інтерфейсу. Нижче — етапи розробки, які проходимо на кожному такому проєкті.
- Розбір сценаріїв на скелі. Виїжджаємо на масив: як шукають маршрут, позначають пролаз, звіряються зі схемою. Фіксуємо, які дії зобов'язані працювати без мережі.
- Схема даних. Що зберігається на пристрої, що на сервері, як нумеруються записи та розв'язуються конфлікти між пристроями.
- Прототипування навігації. Перевіряємо на маршруті: скільки дотиків до позначки пролазу, чи читається схема в рукавичці.
- Реалізація офлайн-ядра. Локальне сховище, черга змін, відкладене відправлення на сервер.
- Синхронізація під час відновлення зв'язку. Продумуємо обрив на середині, повторний вхід і зміну пристрою, а не лише штатний сценарій.
- Польові випробування. Реальні виходи: слабкий сигнал, розряджена батарея, дощ і холод на стенді.
- Передача та підтримка. Віддаємо вихідні коди, документацію зі схеми даних і порядок оновлень.
Карти, датчики та офлайн-сховище: як це влаштовано
Офлайн карти — це не «завантажили все про всяк випадок» підряд, а явне завантаження вибраної області.
Район задається рамкою або радіусом навколо точки, з картографічного набору витягуються тільки потрібні рівні деталізації: для підходу достатньо схематичного шару, детальний потрібен там, де користувач розбирає зачепи та точки страховки.
Дані OpenStreetMap і схеми секторів кладуться в один локальний контейнер, тому карта відкривається без мережі й без очікування відповіді сервера.
Датчики руху — найдорожчий за витратою заряду шар, тому постійного опитування в застосунку немає. Ми підписуємося на події акселерометра й барометра та змінюємо частоту опитування за ситуацією: підхід до скелі, лазіння, тривала зупинка на станції.
Поки активність не розпізнана як сходження, вибірка йде рідше — трек залишається зв'язним, а батарея витрачається приблизно як у звичайній навігації.
Локальний кеш маршрутів влаштований як журнал, а не як один файл, який можна втратити цілком: точки пишуться порціями, а фоновий запис іде через системний планувальник, що працює при заблокованому екрані.
Процес можуть вивантажити з пам'яті будь-якої миті, тому після перезапуску трек збирається від останньої контрольної точки — губляться секунди, а не весь підйом. Без мережі тиждень точки просто накопичуються на пристрої й не заважають запису нових.
Злиття треків — місце, де найчастіше розходяться очікування. Один підйом може бути записаний з двох пристроїв, обірватися при втраті сигналу й продовжитися з іншої точки; під час синхронізації виникають інтервали, що перетинаються, дублі та розходження координат.
Розв'язуємо це детермінованим правилом: пріоритет у запису з щільнішою вибіркою, дублі в межах вікна відкидаються, розрив закривається інтерполяцією — на виході один зв'язний трек замість двох неповних.
Підсумок: у горах немає мережі, руки зайняті, екран заблокований. Тому всі шари проєктуються під відмову — передзавантаження замість довантаження, події замість опитування, журнал замість буфера в пам'яті.
Що замовник отримує на руки після здачі проєкту
Здача проєкту — це не лише застосунок, який відкривається й працює. Ми передаємо комплект артефактів, за яким ваша команда або інший підрядник зможе розвивати продукт без нас: від репозиторію до інструкції, що робити при відмові сервісу. Нижче — що саме опиниться у вас на руках.
- Вихідний код і збирання. Репозиторій з історією змін, доступи до сервісів збирання, ключі підпису та інструкція з випуску релізного й тестового збирання на чистій машині.
- Схема архітектури. Шари застосунку, модулі, зовнішні сервіси — карти, авторизація, зберігання маршрутів — і точки, де дані кешуються та синхронізуються.
- Документація проєкту. Опис модулів, формати зберігання маршрутів, тренувань і досягнень, вимоги до серверної частини, словник даних.
- Документація з офлайну. Що працює без мережі, як розв'язуються конфлікти під час синхронізації, як поводиться застосунок при обриві зв'язку в залі чи на скелі.
- Регламент оновлень. Як випускається версія, хто її підтверджує, як готується відкат і що перевіряється перед публікацією в магазинах.
- Інструкція з моніторингу відмов. Які помилки та події збираються, які пороги вважаються нормою, кому надходить повідомлення і що робити за кожним сценарієм.
- Доступи та права. Акаунти магазинів застосунків, сертифікати, права на публікацію, передача володіння на вашу організацію.
- Чек-лист приймання. Перевірені сценарії від реєстрації до запису маршруту без мережі, з очікуваною поведінкою за кожним.
Передача йде разом із прийманням: кожен пункт показуємо на живому продукті, а не лише на папері.
Чим офлайн-режим відрізняється від кешування на льоту?
Кешування даних на льоту наповнює сховище реактивно: користувач відкриває схему району — застосунок забирає її з сервера й тримає в пам'яті до витіснення. Офлайн-режим влаштований інакше: область завантажується заздалегідь і цілком, разом із шарами, які знадобляться на маршруті. Різниця видна не в інтерфейсі, а в тому, що лежить на пристрої на момент, коли зв'язку вже немає.
Передзавантаження областей — це усвідомлений вибір району й набору даних: топосхема та підходи, категорії складності, описи маршрутів, точки страховки, схеми спусків. Пакет приходить із контрольними сумами, тому повторний прохід знайомим районом довантажує лише зміни. Застосунок заздалегідь показує, скільки місця займе область, і рішення залишається за користувачем.
Робота без зв'язку виявляє різницю миттєво. При кешуванні на льоту порожньою залишається будь-яка зона, до якої не догортали вдома: на скелях з'ясовується, що потрібен саме сусідній сектор. Передзавантаження закриває район цілком, включно з під'їздами та запасними шляхами відходу.
Далі починається інженерія компромісу. Завантажені області лежать в окремому сховищі й не витісняються, тому обсяг пам'яті зростає передбачувано й обмежується правилом: старі райони видаляються за давністю звернення.
Кеш на льоту живе за витісненням і постійно піднімає зв'язок — рвані довантаження на маршруті помітно витрачають батарею. Ми зазвичай збираємо гібрид: часті райони кладемо передзавантаженням, рідкісні віддаємо кешу на запит.
Кейс: як зросла частка записаних маршрутів
Застосунок для скелелазіння ми отримали на етапі, коли ядро вже працювало, але довгі маршрути далеко від міста розвалювалися.
Трек писався в пам'ять і йшов на сервер одним пакетом тільки за стабільної мережі: якщо зв'язку не було пару годин, сесія зникала цілком — разом із пройденим шляхом, спробами та статистикою.
Друга хвиля відгуків користувачів стосувалася витрати батареї: телефон сідав до кінця підходу, і запис обривався вже фізично.
Переписали шар запису: трек зберігається локально невеликими порціями й одразу позначається як несинхронізований, а відправлення йде чергою з довантаженням частинами — обрив мережі більше не стирає вже записане.
Опитування датчиків прив'язали до факту руху та стану екрана, карти кешуються заздалегідь, а фонова частина перестала будити застосунок без потреби.
Що показали метрики
- частка втрачених треків: 17% → 1,8%;
- час синхронізації сесії після повернення в мережу: ~40 с → 4–6 с;
- витрата батареї за чотиригодинний підхід: 34% → 11%;
- частка розпочатих сесій, що дійшли до збереженого маршруту: 62% → 94%.
Відгуки користувачів змістилися слідом: скарги на розряд і «зниклі» тренування трапляються в рази рідше, середня оцінка піднялася з 3,4 до 4,6.
Окремо закрили зв'язку з годинами Garmin — сесія, розпочата на зап'ясті, коректно підхоплюється телефоном, тому маршрут залишається цілим при переході між пристроями.
Технічні сумніви перед стартом робіт
Інженерні сумніви перед стартом стосуються не оформлення, а поведінки застосунку в горах і на довгій дистанції супроводу. Нижче — вузли, за якими найчастіше просять визначитися до початку робіт.
Як застосунок працює в зоні без зв'язку?
Карта, топо та точки маршруту лежать у локальній базі на пристрої, туди ж пишеться трек. Записи ставляться в чергу й ідуть на сервер при появі мережі, конфлікти розв'язуються за часом останньої зміни — дані не губляться й не затираються.
Наскільки точна відмітка на маршруті?
Під стіною та в ущелині супутниковий сигнал відбивається й дає стрибки. Трек згладжується, викиди відсікаються, позиція доповнюється показаннями інерційних датчиків і барометра — відмітка тримається на ділянці маршруту, а не стрибає по скелі.
Зв'яжете застосунок з нашими сервісами?
Картографія, погода, приймання оплати, вхід через наявну облікову систему та експорт треків підключаються через окремий шар інтеграцій. Заміна сервісу зачіпає лише цей шар, екрани та логіка залишаються незмінними.
Що з підтримкою старих пристроїв?
Мінімальну версію системи обираємо за даними про те, які апарати реально в ходу в аудиторії. На слабких пристроях вимикаються важкі шари карти, інтерфейс залишається робочим; перевіряємо на фізичних пристроях, а не лише на емуляторах.
З чого складається обсяг підтримки?
З кількості платформ і підтримуваних версій системи: ширший парк — більше гілок збирання й тестових прогонів. Регламент планових оновлень під нові версії системи фіксуємо заздалегідь, тому трудовитрати на супровід передбачувані.
Обговоримо ваше завдання і повернемося з планом
Щоб оцінка проєкту спиралася на факти, а не на припущення, нам потрібно розібратися в предметній області: як ведеться каталог трас і категорій складності, де проходить межа офлайн-режиму, як застосунок працює з геолокацією та датчиками на скеледромі й на природному рельєфі.
Опишіть завдання у вільній формі — що вже є і чого бракує:
- мета продукту: каталог трас, щоденник проходжень, тренувальні плани, спільнота або комбінація;
- аудиторія та сценарії: новачок у залі, спортсмен на виїзді, інструктор, адміністратор скеледрому;
- поточні напрацювання: прототипи, дизайн, серверна частина, дані про траси, якщо вони вже зібрані;
- обмеження: платформи, терміни, вимоги до роботи без мережі та до синхронізації даних;
- доступи та інтеграції: акаунти магазинів застосунків, аналітика, платіжні та CRM-системи.
У відповідь повернемося з оцінкою проєкту та планом робіт: склад команди під завдання, етапи з перевірюваним результатом на кожному, терміни розробки першої робочої версії та порядок подальших релізів. Окремо покажемо, які рішення потребують вашого вибору, а які закриваємо самі. Напишіть нам — обговоримо завдання й призначимо короткий розбір з інженерами.
