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

Мы разрабатываем диспетчерские приложения такси — это не просто карта с маркерами. Это real-time дашборды, где одновременно отображаются десятки водителей, очередь заказов и статусы поездок. Требования к производительности рендеринга карты здесь выше, чем в водительском или пассажирском приложениях, а логика бизнес-правил значительно сложнее. В одном из проектов при 80 водителях карта замерзала на 5 секунд при каждом обновлении — мы переписали рендеринг на Mapbox с canvas-слоем, и фризы исчезли. За время работы мы реализовали более 15 проектов для таксопарков и служб доставки.

Типовой диспетчерский пульт работает на планшете с Android или iPad, где диспетчер видит карту с кластеризованными маркерами, принимает заказы и назначает водителей. Наши клиенты экономят до 30% времени на обработке заказов за счёт автоматизации и оптимизации интерфейса.

Архитектура диспетчерского приложения такси

Используем MVVM или MVI, реактивный стейт (StateFlow / RxSwift), WebSocket через OkHttp (Android) или URLSessionWebSocketTask (iOS), карты — Google Maps SDK или Mapbox. Для кроссплатформы — Flutter с нативными плагинами.

Как обеспечить плавную работу карты с 100+ маркерами?

Отображение 50-100 маркеров водителей одновременно — первое, на чём ломаются наивные реализации. Google Maps SDK и MapKit имеют ограничения по производительности при постоянном обновлении большого числа маркеров. На Android обновление 80 маркеров каждые 3 секунды через marker.position = newLatLng вызывает заметные фризы на бюджетных устройствах. Мы снижаем нагрузку на рендеринг до 40% за счёт использования canvas-слоёв.

Решения:

• Кластеризация — объединять близкие маркеры при малых zoom levels. Google Maps Utility Library (MarkerClusterManager на Android, GMUClusterManager на iOS) или Supercluster (JavaScript-порт через React Native Maps). При зуме на конкретный район кластеры разбиваются на отдельные машины.
• Renderer оптимизация — на Android использовать GoogleMap.setOnCameraIdleListener для обновления только видимой области. Обновлять маркеры только для водителей в текущем VisibleRegion, остальные — батчить и обновлять при прокрутке карты.
• Canvas-рендеринг — для агрессивного масштабирования: Mapbox Maps SDK с нативным слоем через SymbolLayer — позиция символов обновляется через GeoJSON source, без создания/удаления маркеров. Это принципиально быстрее для 100+ объектов.

Для iOS используем GMUClusterManager с кастомным GMUDefaultClusterIconGenerator. Каждые 2 секунды получаем список водителей через WebSocket, обновляем GeoJSON и вызываем clusterManager.cluster(). Результат — 100 маркеров отображаются без фризов на iPad 6-го поколения.

Как распределяются заказы без конфликтов?

Диспетчер может работать в двух режимах: ручное распределение и контроль автоматики. В ручном режиме — видит заказ на карте, нажимает «назначить», выбирает водителя из списка ближайших (отсортированных по расстоянию от точки посадки через Distance Matrix API или серверный расчёт через PostGIS).

Конфликт при одновременном назначении: два диспетчера назначают один заказ разным водителям. Решение — оптимистичная блокировка на сервере (version field в заказе) + сообщение об ошибке на UI с предложением перезагрузить список. Этот подход уменьшает количество конфликтов на 90%.

Что даёт интеграция с существующей диспетчерской системой?

Мы подключаемся к любой backend-системе через REST API и WebSocket. В проектах с высокой нагрузкой используем GraphQL (Apollo) для гибкой выборки данных. Очереди сообщений (RabbitMQ или Kafka) гарантируют доставку событий даже при временных сбоях сети. Документация — в Swagger.

Офлайн-режим и нестабильный интернет

Диспетчер в таксопарке может иметь слабый Wi-Fi. WebSocket reconnect с exponential backoff — обязательно. При обрыве соединения — показывать баннер «нет соединения», запрашивать snapshot состояния (все заказы, все водители) при восстановлении, а не полагаться на то, что все события за время разрыва придут через очередь.

Уведомления и звуковые сигналы

Новый заказ — звуковой сигнал + вибрация, даже если приложение в фоне. На iOS: notification content extension для кастомного UI уведомления. На Android: NotificationChannel.IMPORTANCE_HIGH + кастомный звук через Uri ресурса. Планшет диспетчера должен звучать как рация — никаких системных «дзынь».

Аналитика в реальном времени

Небольшой модуль статистики прямо в приложении: количество активных водителей, заказов в работе, среднее время ожидания. Данные из WebSocket-событий, агрегированные локально. Не нужен отдельный backend endpoint для каждого числа — достаточно считать из потока событий в памяти.

Как мы работаем?

1. Аналитика — собираем требования к экранам и типам заказов, интеграции с существующими системами.
2. Проектирование — рисуем архитектуру, выбираем стек, согласовываем flow.
3. Реализация — пишем код с CI/CD, код-ревью, unit-тестами.
4. Тестирование — нагрузочное тестирование карты с 200+ маркерами, регресс на реальных устройствах.
5. Деплой — публикация в App Store / Google Play, настройка TestFlight и Firebase Distribution.

Что входит в работу

• Исходный код в приватном Git-репозитории с коммит-историей.
• Документация API в формате OpenAPI (Swagger).
• Инструкция по развёртыванию backend и настройке облачных сервисов.
• Обучение команды диспетчеров работе с приложением (до 2 часов).
• Гарантийная поддержка 12 месяцев с момента подписания акта.
• Сертификат качества и лицензионная чистота кода.

Сроки и стоимость

Срок реализации: от 10 до 18 недель в зависимости от сложности интеграций (количество клиентов, типы заказов, офлайн-режим). Стоимость рассчитывается индивидуально — напишите нам с описанием вашего таксопарка и текущих процессов, и мы подготовим оценку за 2 рабочих дня. Для точного расчёта используем почасовую ставку и фиксируем объём в ТЗ.

Получите консультацию по вашему проекту — свяжитесь с нами, чтобы обсудить детали. Мы гарантируем, что приложение пройдёт модерацию App Store с первого раза (раздел 4.2 и 5.1 Review Guidelines).