Реалізація GPS-трекінгу транспорту в мобільному IoT-додатку
GPS-трекер на транспортному засобі надсилає пакет кожні 10 секунд. Це 8640 записів на добу на один об'єкт. При 50 транспортних засобах — 432 000 точок на день. Ми вирішуємо задачу відображення поточної позиції в реальному часі та перегляду історії без гальм за допомогою оптимізованої клієнт-серверної архітектури на Flutter/React Native. Ключова складність — не просто отримати координати, а забезпечити плавне відображення на карті без лагів при високій частоті оновлень. Ми реалізуємо WebSocket-з'єднання для миттєвої доставки даних, дискретизацію маршрутів за алгоритмом Дугласа-Пекера та кластеризацію маркерів для роботи з флотом будь-якого розміру. Такий підхід дозволяє економити до 30% бюджету порівняно з паралельною розробкою двох нативних додатків.
Як забезпечити real-time оновлення позиції?
Мобільний додаток отримує дані через WebSocket, а не polling. Різниця відчутна:
| Параметр | Polling (HTTP) | WebSocket (Server-Sent Events) |
|---|---|---|
| Затримка | від 10 секунд | 1–2 секунди |
| Навантаження на сервер | N запитів на секунду | одне з'єднання |
| Трафік | заголовки + тіло при кожному запиті | мінімальний оверхед |
Ми використовуємо WebSocket з бінарним протоколом (наприклад, WebSocket в Dart/TypeScript). Сервер пушить оновлення відразу після отримання пакета від трекера, затримка мінімальна. WebSocket знижує затримку в 5–10 разів порівняно з polling, що критично для екстрених алертів.
Скільки точок можна відображати на карті без втрати продуктивності?
Історія за день — від 5 000 до 15 000 точок. Рендерити їх усі — лаг на слабких пристроях. Рішення: дискретизація за алгоритмом Дугласа-Пекера (Douglas-Peucker) на сервері. При zoom 10 достатньо ~500 точок, при zoom 17 — повна деталізація. Клієнт запитує трек з параметром зуму.
Для відображення великої кількості транспортних засобів використовуємо кластеризацію: маркери групуються при віддаленні, показуючи лічильник. На Flutter використовуємо Supercluster, на нативних платформах — GMSMarkerClusterer (Android) / CMClusterAnnotationView (iOS).
Отримання даних від IoT-трекерів
Апаратні GPS-трекери (Teltonika FMB140, Queclink GV620, Concox GT06N) надсилають дані по TCP/UDP на сервер телематики. Мобільний додаток не взаємодіє з трекером безпосередньо — це завдання сервера. Клієнт отримує оброблений потік через WebSocket або REST API.
Різниця між WebSocket і polling у цьому сценарії відчутна. Polling кожні 10 секунд на 50 об'єктів = постійні HTTP-запити, overhead на handshake, затримка до 10 секунд. WebSocket з серверними подіями: сервер пушить оновлення відразу при отриманні нового пакета від трекера, затримка — 1–2 секунди, немає зайвих запитів.
Відображення на карті
Кожен трекер — маркер на карті з іконкою транспортного засобу, напрямком руху (bearing) і статусом. Три ключові моменти:
Bearing-анімація. Трекер змінює напрямок — іконка повертається плавно. На Android: ObjectAnimator.ofFloat(marker, "rotation", oldBearing, newBearing).setDuration(500). На iOS: CABasicAnimation(keyPath: "transform.rotation.z") на шарі маркера.
Плавне переміщення. Маркер рухається до нової координати без стрибків. Використовуємо ValueAnimator з LatLngInterpolator на Android; на iOS — CABasicAnimation з CGPoint interpolation через MKAnnotationView.coordinate.
Кластеризація. При zoom нижче 12 окремі маркери зливаються. Обираємо кластеризатор під платформу: Supercluster (Flutter), GMSMarkerClusterer (Android) або CMClusterAnnotationView (iOS). Кластер показує лічильник транспортних засобів всередині.
Історія треку
Історія за день — від 5 000 до 15 000 точок. Малювати Polyline з 10 000 точок напряму — лаг при render. Два підходи:
Дискретизація Дугласа-Пекера на сервері. При запиті історії сервер спрощує трек з епсілон-параметром, залежним від рівня зуму: при zoom 10 достатньо ~500 точок, при zoom 17 — повна деталізація. Клієнт запитує трек з параметром зуму.
LOD при прокручуванні. Завантажуємо трек за вибраний період шматками при скролі часового слайдера. Поза видимою областю — не рендеримо.
Зупинки в треку обчислюються на сервері: кластер точок з speed < 5 км/год довше N хвилин = зупинка. Адреса — reverse geocoding через Google Maps Geocoding API або Nominatim, кешується в базі.
Швидкість та алерти
Перевищення швидкісного режиму, різке гальмування, різке прискорення — обчислюється з сирих даних телематики (speed, accelerometer якщо трекер підтримує). Алерт надсилається через FCM/APNs push з high priority. У додатку — UNNotificationCategory з action «Відкрити карту» для iOS, PendingIntent з deep link для Android.
Геозонні алерти: в'їзд/виїзд із зони. Перевірка ST_Contains в PostGIS при кожному вхідному пакеті — сотні тисяч перевірок на добу при великому флоті. Оптимізація: просторовий індекс GIST на geometry колонці, R-tree на геозонах в пам'яті (GeoHashing для первинної фільтрації).
Що робити, якщо кількість геозон перевищує 1000?
При великій кількості геозон продуктивність перевірки критична. Ми використовуємо наступний підхід:
| Кількість геозон | Час перевірки ST_Contains | Оптимізація |
|---|---|---|
| 100 | 0.5 мс | без індексу |
| 1000 | 5 мс | GIST індекс |
| 10000 | 50 мс | R-tree + GeoHash |
Такий стек дозволяє обробляти до 10 000 геозон із затримкою менше 50 мс на одну перевірку.
З практики: трекінг цементовозів
Подробиці кейсу
35 машин, інтервал запису 15 сек, історія на 90 днів. Проблема при перегляді історії за місяць: Polyline з 720 000 точок вішав UI на 4–5 секунд на Samsung A32. Після впровадження динамічної дискретизації (200 точок при zoom 10, 5000 при zoom 16) — відображення стало плавним.
Що входить у роботу над проєктом
- Розробка серверного API телематики (якщо потрібно)
- Інтеграція з популярними трекерами (Teltonika, Queclink, Concox)
- Мобільний додаток на Flutter/React Native з підтримкою iOS та Android
- Налаштування WebSocket-з'єднання та push-сповіщень (FCM/APNs)
- Реалізація геозон та алертів
- Документація по API та навчання команди замовника
- Технічна підтримка протягом 1 місяця після запуску
Терміни та вартість
Терміни реалізації: від 2 до 6 тижнів залежно від складності інтеграції та вимог до функціоналу. Вартість розраховується індивідуально після аналізу вашого проєкту. Ми гарантуємо якість та дотримання термінів завдяки досвіду 5+ років та понад 20 успішних проєктів у сфері IoT та телематики. Середня вартість володіння таким рішенням на 5 років нижча на 40% за рахунок єдиної кодової бази.
Отримайте консультацію щодо вашого проєкту — ми оцінимо складність інтеграції та запропонуємо оптимальне рішення. Замовте розробку додатку для GPS-трекінгу з гарантією якості.