Розробка мобільного додатку для моніторингу транспорту
Диспетчер дивиться на карту — 40 вантажівок, і три з них не оновлювали позицію вже 20 хвилин. Чи зависла трансляція? Немає мережі в горах? Чи GPS-антена відключена навмисно? Це три різні сценарії з різною реакцією, і додаток має їх розрізняти — а не просто фарбувати точку в сірий колір. Наша команда має 5+ років досвіду у створенні таких систем. Ми пропонуємо розробку додатку під ключ, включаючи інтеграцію з популярними телематичними платформами та бекендом для обробки даних. Це не просто карта з маркерами — це система реального часу, де кожна точка містить метадані: швидкість, напрямок, статус двигуна, рівень заряду трекера. При нерухомості більше 5 хвилин автоматично перевіряється, чи є мережа (heartbeat від трекера) та чи увімкнено запалювання. Тільки так можна відрізнити поломку від планової стоянки.
Що насправді потрібно диспетчеру в мобільному додатку?
Додаток моніторингу — не просто «маркери на карті». Диспетчер працює з парком 20–200 одиниць і йому потрібні:
- Реальний час з метаданими: координата + швидкість + напрямок + статус двигуна + заряд батареї трекера
- Історія треку: маршрут за день/тиждень з геокодованими адресами зупинок
- Геозонування: сповіщення при в'їзді/виїзді із зони складу, будмайданчика, забороненої території
- Алерти: перевищення швидкості, довга стоянка з увімкненим двигуном, відхилення від маршруту
Все це потребує різної архітектури на клієнті. Ми вже реалізували проекти з парком від 50 до 500 одиниць, тому знаємо, як масштабувати рішення під будь-які завдання.
Як ми приймаємо дані телематики в реальному часі?
Телематичні блоки (Teltonika FMB, Wialon TK, Navixy OEM) передають дані через TCP або GPRS на сервер. Мобільний додаток не з'єднується з трекерами напряму — він отримує вже оброблений потік через WebSocket або MQTT-клієнт.
Процес прийому даних:
- Трекер надсилає сирі дані на сервер за протоколом виробника (TCP, GPRS).
- Сервер парсить дані, збагачує метаінформацією та публікує в MQTT-топік.
- Мобільний додаток підписується на топік через WebSocket та отримує оновлення в реальному часі.
На Android використовуємо OkHttp WebSocket з EventBus або SharedFlow для доставки оновлень у ViewModel. На iOS — URLSessionWebSocketTask (iOS 13+) або Starscream для більш старих target'ів. Оновлення приходять як JSON або protobuf — protobuf переважніше при великому флоті: пакет 40 машин × 10 полів у protobuf займає ~1.5 КБ проти ~8 КБ у JSON, що в 5 разів економніше по трафіку. Використання Protobuf замість JSON дозволяє економити до 80% на трафіку, що знижує витрати на мобільний інтернет для диспетчерів. Згідно з документацією protobuf, бінарний формат дозволяє зменшити розмір даних у 3-10 разів порівняно з JSON. Protobuf краще за JSON у 5 разів за об'ємом даних.
Як забезпечити продуктивність мобільного додатку з великим флотом?
200 маркерів на карті з анімацією руху — це вже напружено. Ключові рішення:
Анотації замість SVG-оверлеїв
На iOS MKAnnotationView обробляє до ~300 маркерів без помітного лагу. Понад — використовуємо MKOverlay з кастомним рендерером, який малює всі точки в одному CALayer. На Android Google Maps SDK з MarkerOptions деградує після ~500 маркерів — переходимо на Mapbox Maps SDK v10 з SymbolLayer на основі GeoJSON source: весь флот оновлюється одним викликом source.setGeoJson(featureCollection). Анотації на карті споживають у 2 рази менше ресурсів пристрою, ніж SVG-оверлеї.
Кластеризація на сервері
При зумі < 11 кластери рахуються на сервері (PostGIS ST_ClusterKMeans), клієнт отримує готові центроїди з лічильником. Локальна кластеризація (Supercluster) підходить для флотів до 300–400 одиниць. Серверна кластеризація краще клієнтської для флотів понад 400 одиниць.
Анімація руху
Позиція трекера оновлюється раз на 10–30 секунд — маркер не повинен «стрибати». ValueAnimator з LatLngInterpolator (Android) або CABasicAnimation з CGPoint interpolation (iOS) — маркер плавно «ковзає» до нової точки.
Порівняння методів кластеризації:
| Метод | Макс. кількість маркерів | Latency |
|---|---|---|
| Supercluster (клієнт) | ~400 | <100ms |
| PostGIS ST_ClusterKMeans (сервер) | Необмежено | <50ms (з індексом) |
Порівняння форматів даних:
| Формат | Розмір пакету (40 машин) | Економія трафіку |
|---|---|---|
| JSON | ~8 КБ | — |
| Protobuf | ~1.5 КБ | в 5 разів |
Як будується історія треку та геокодування в мобільному додатку?
Трек за день — це 2000–8000 точок залежно від інтервалу запису. Відображаємо через Polyline / MKPolyline, але не весь трек одразу: завантажуємо bbox видимої області карти та запитуємо точки тільки для неї. При зумі «весь день» — дискретизуємо трек алгоритмом Douglas-Peucker на сервері.
Адреси зупинок — reverse geocoding через Google Maps Geocoding API або OpenStreetMap Nominatim (self-hosted). Кешуємо результати в SQLite, щоб не повторювати запити при скролі історії.
Що робити з алертами та сповіщеннями?
Перевищення швидкості, геозонні події, довга стоянка — тригери обчислюються на сервері, push-сповіщення приходить через FCM/APNs. На iOS використовуємо UNNotificationCategory з UNNotificationAction — прямо зі сповіщення можна відкрити карту з конкретним транспортним засобом.
Геозони — полігони GeoJSON, перевірка ST_Contains в PostgreSQL + PostGIS при кожному вхідному повідомленні від трекера. Мобільний клієнт тільки відображає геозони та отримує алерти — не обчислює перетини локально.
Типові помилки при реалізації сповіщень: відсутність обробки фонового стану, невірне налаштування геозон, забуття про оновлення токенів APNs/FCM.
Що входить у розробку?
- Аналіз протоколів телематичних пристроїв та API існуючої платформи
- Дизайн інтерфейсу диспетчера: карта, список транспорту, історія, сповіщення
- Розробка всіх модулів: прийом даних, відображення на карті, геозони, алерти, історія треків
- Навантажувальне тестування з імітацією 200+ трекерів
- Публікація в App Store та Google Play, налаштування push-сповіщень
- Документація та навчання диспетчерів
- Технічна підтримка після запуску
Кроки розробки мобільного додатку:
- Аналіз вимог та протоколів телематики.
- Проектування архітектури серверної та клієнтської частин.
- Розробка серверного модуля прийому та обробки даних.
- Розробка мобільного клієнта (карта, геозони, алерти).
- Навантажувальне тестування з імітацією 200+ трекерів.
- Публікація в магазини додатків та налаштування push.
- Технічна підтримка після запуску.
Скільки часу займає розробка?
MVP (карта + реальний час + історія): 6–10 тижнів. Повна платформа з геозонами, алертами, аналітикою пробігу та звітами: 3–5 місяців. Вартість розраховується індивідуально після аудиту вашої інфраструктури.
Ми гарантуємо стабільну роботу при навантаженні до 500 одиниць техніки. Зв'яжіться з нами для оцінки вашого проекту — отримайте консультацію з архітектури та термінів. Замовте розрахунок вартості — це безкоштовно.