Разработка мобильного приложения для мониторинга транспорта

Диспетчер смотрит на карту — 40 грузовиков, и три из них не обновляли позицию уже 20 минут. Зависла ли трансляция? Нет сети в горах? Или GPS-антенна отключена намеренно? Это три разных сценария с разной реакцией, и приложение должно их различать — а не просто красить точку в серый цвет. Наша команда имеет 5+ лет опыта в создании таких систем. Мы предлагаем разработку приложения под ключ, включая интеграцию с популярными телематическими платформами и бекендом для обработки данных. Это не просто карта с маркерами — это система реального времени, где каждая точка содержит метаданные: скорость, направление, статус двигателя, уровень заряда трекера. При неподвижности более 5 минут автоматически проверяется, есть ли сеть (heartbeat от трекера) и включено ли зажигание. Только так можно отличить поломку от плановой стоянки.

Что на самом деле нужно диспетчеру?

Приложение мониторинга — не просто «маркеры на карте». Диспетчер работает с парком 20–200 единиц и ему нужны:

• Реальное время с метаданными: координата + скорость + направление + статус двигателя + заряд батареи трекера
• История трека: маршрут за день/неделю с геокодированными адресами остановок
• Геозонирование: уведомление при въезде/выезде из зоны склада, стройплощадки, запрещённой территории
• Алерты: превышение скорости, долгая стоянка с заведённым двигателем, отклонение от маршрута

Всё это требует разной архитектуры на клиенте. Мы уже реализовали проекты с парком от 50 до 500 единиц, поэтому знаем, как масштабировать решение под любые задачи.

Как мы принимаем данные телематики в реальном времени?

Телематические блоки (Teltonika FMB, Wialon TK, Navixy OEM) передают данные через TCP или GPRS на сервер. Мобильное приложение не соединяется с трекерами напрямую — оно получает уже обработанный поток через WebSocket или MQTT-клиент.

Процесс приёма данных:

1. Трекер отправляет сырые данные на сервер по протоколу производителя (TCP, GPRS).
2. Сервер парсит данные, обогащает метаинформацией и публикует в MQTT-топик.
3. Мобильное приложение подписывается на топик через 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, бинарный формат позволяет уменьшить размер данных в 3-10 раз по сравнению с JSON.

Как обеспечить производительность карты с большим флотом?

200 маркеров на карте с анимацией движения — это уже напряжённо. Ключевые решения:

Аннотации вместо SVG-оверлеев

На iOS MKAnnotationView обрабатывает до ~300 маркеров без заметного лага. Свыше — используем MKOverlay с кастомным рендерером, который рисует все точки в одном CALayer. На Android Google Maps SDK с MarkerOptions деградирует после ~500 маркеров — переходим на Mapbox Maps SDK v10 с SymbolLayer на основе GeoJSON source: весь флот обновляется одним вызовом source.setGeoJson(featureCollection).

Clustering на сервере

При зуме < 11 кластеры считаются на сервере (PostGIS ST_ClusterKMeans), клиент получает готовые центроиды с счётчиком. Локальная кластеризация (Supercluster) подходит для флотов до 300–400 единиц.

Анимация движения

Позиция трекера обновляется раз в 10–30 секунд — маркер не должен «прыгать». ValueAnimator с LatLngInterpolator (Android) или CABasicAnimation с CGPoint interpolation (iOS) — маркер плавно «скользит» к новой точке.

Сравнение методов кластеризации:

Сравнение форматов данных:

Как строится история трека и геокодирование?

Трек за день — это 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 при каждом входящем сообщении от трекера. Мобильный клиент только отображает геозоны и получает алерты — не вычисляет пересечения локально.

Что входит в разработку?

• Анализ протоколов телематических устройств и API существующей платформы
• Дизайн интерфейса диспетчера: карта, список транспорта, история, уведомления
• Разработка всех модулей: приём данных, отображение на карте, геозоны, алерты, история треков
• Нагрузочное тестирование с имитацией 200+ трекеров
• Публикация в App Store и Google Play, настройка push-уведомлений
• Документация и обучение диспетчеров
• Техническая поддержка после запуска

Сколько времени занимает разработка?

MVP (карта + реальное время + история): 6–10 недель. Полная платформа с геозонами, алертами, аналитикой пробега и отчётами: 3–5 месяцев. Стоимость рассчитывается индивидуально после аудита вашей инфраструктуры.

Мы гарантируем стабильную работу при нагрузке до 500 единиц техники. Свяжитесь с нами для оценки вашего проекта — получите консультацию по архитектуре и срокам. Закажите расчет стоимости — это бесплатно.