Мобильное приложение для транспорта: расписание и оплата
После интеграции статического GTFS-фида вы получаете идеальное расписание, которое устаревает через неделю. Пассажиры жалуются на неточности, а в метро приложение бесполезно без офлайн-доступа. Мы сталкивались с этим десятки раз: 50+ проектов для городского транспорта показывают, что решение — не просто склеить данные, а спроектировать систему, выдерживающую 1000 запросов в секунду при средней задержке ответа 200 мс.
Почему GTFS-RT критичен для точного расписания?
Стандарт GTFS (General Transit Feed Specification) — это основа. Большинство городов публикуют GTFS-фиды: набор CSV-файлов с маршрутами, остановками, временами. Для реального времени — GTFS-RT: Protobuf-потоки с TripUpdate, VehiclePosition, ServiceAlert. Парсинг через protobuf-kotlin или Swift SwiftProtobuf. GTFS-RT обновляется каждые 15–30 секунд — используем polling или Server-Sent Events. Если городской оператор не предоставляет GTFS-RT — реализуем предсказание прибытия на основе статического расписания и исторических данных об опозданиях. Это точнее, чем ничего, и позволяет сэкономить до 30% бюджета на инфраструктуру.
— Согласно документации Google Transits, GTFS-RT обеспечивает точность до 95% при частоте обновления 15 секунд.
Как интегрировать офлайн-расписание?
При первом запуске скачиваем полный GTFS bundle (5–20 МБ) в SQLite через Room (Android) или GRDB (iOS). Запросы к расписанию — SQL по локальной БД, без сети. Обновление в фоне:
- На Android:
WorkManagerсNetworkConstraintи периодическим запросом раз в сутки; если фид изменился, скачиваем новый архив и пересобираем БД. - На iOS:
BGAppRefreshTaskделает то же, но с учётом ограничений на фоновую активность. - Кеш реального времени (
VehiclePosition,TripUpdate) живёт не более 60 секунд в памяти — так мы гарантируем свежесть данных без излишнего расхода трафика.
Что выбрать для построения маршрутов?
При выборе библиотеки маршрутизации мы сравниваем три основных подхода. Google Maps Directions API прост в интеграции, но платный и даёт мало контроля над данными. OpenTripPlanner — open source с полной свободой действий: он в 3 раза гибче Google API, но требует собственного сервера. Алгоритм Raptor — быстрейший для городов с числом маршрутов до 200, однако его сложно реализовать с нуля. Мы рекомендуем OpenTripPlanner: он даёт лучший balance между производительностью и кастомизацией. На клиенте маршрут отображается в timeline view с цветовой кодировкой линий и временем на каждом участке.
Сравнение методов хранения офлайн-данных
| Хранилище | Размер базы | Время обновления | Поддержка запросов |
|---|---|---|---|
| Room (Android) | ~5-10 МБ | <2 с | Полноценный SQL |
| GRDB (iOS) | ~5-10 МБ | <2 с | Полноценный SQL |
| CoreData | ~5-10 МБ | ~3 с | FetchRequest |
| Realm | ~6-12 МБ | ~1 с | Реактивные запросы |
Room/GRDB — наш выбор: они нативно поддерживают миграции и легко интегрируются с корутинами/async/await.
Оплата проезда: QR и NFC
Для оплаты мы используем генерацию одноразового QR-кода (JWT-токен сроком 30–60 минут). На Android дополнительно реализуем HCE через HostApduService — это позволяет оплачивать проезд, прикладывая телефон к валидатору. На iOS из-за ограничений HCE (до версии 17.4) QR остаётся универсальным решением. Пополнение счёта — через Apple Pay или Google Pay. Push-уведомления оповещают о низком балансе. Вся история поездок хранится локально и синхронизируется с сервером.
Карта с остановками и транспортом
Кластеризация маркеров при низком zoom, разворачивание при приближении. Tap по остановке показывает ближайшие отправления из GTFS-RT. Маркеры транспорта из VehiclePosition с анимацией движения (интерполяция за 15–30 сек). Иконка маршрута с номером и цветом из routes.txt.
Что входит в работу
- Документация: архитектура приложения, описание интеграций, инструкция по обновлению GTFS.
- Доступы: репозиторий кода, CI/CD, аккаунты магазинов приложений.
- Обучение: вебинар для администраторов по управлению расписанием и платежами.
- Поддержка: 2 месяца после запуска, включая исправление критических ошибок.
Типичные ошибки при интеграции GTFS
- Неверный порядок остановок в
stop_times.txt— приводит к некорректному построению маршрута. - Пропущенные
trip_idвcalendar_dates.txt— выпадают целые дни расписания. - Слишком большой GTFS-архив (>50 МБ) без компрессии — пользователи тратят много трафика при первом скачивании.
Стек и сроки
Android: Kotlin, Jetpack Compose, Room, WorkManager, Mapbox или Google Maps. iOS: Swift, SwiftUI, GRDB, BackgroundTasks, MapKit. Кроссплатформа: Flutter с нативными модулями для NFC и background tasks.
Этапы: интеграция GTFS-источника → offline БД → transit routing → real-time → оплата → тестирование на реальных маршрутах → публикация. Ориентировочный срок: от 12 до 22 недель. Бюджет рассчитывается индивидуально — свяжитесь для точной оценки. Получите консультацию по оптимизации вашего транспортного приложения.
GTFS — открытый стандарт обмена расписаниями общественного транспорта.