Реализация геозон для IoT-устройств (Geofencing) в мобильном приложении

Реализация геозон для IoT-устройств (Geofencing) в мобильном приложении

Геозона сработала — трекер вошёл в зону. Но уведомление пришло через 4 минуты. За это время самокат уехал на 600 метров за периметр склада. Пока проблема в том, где именно проверяется пересечение геозоны: на сервере раз в N секунд или в реальном времени при каждом входящем пакете. Мы сталкивались с этим не раз: при частоте записи 30 секунд трекер проскакивает зону, и событие теряется. Наше решение — комбинировать серверную проверку с предикативной фильтрацией. В этой статье разберём, как реализовать геозоны для IoT-устройств, чтобы не терять события и минимизировать задержки.

Серверная vs клиентская геолокация

Для IoT-устройств (трекеры, датчики, транспорт) геозоны всегда проверяются на сервере. IoT-устройство не запускает ваше приложение — оно просто посылает GPS-пакеты. Мобильное приложение получает уже вычисленное событие через push-уведомление или WebSocket. Это контрастирует со сценарием, когда геозону проверяет сам смартфон пользователя через CLLocationManager.startMonitoring(for: region) (iOS) или GeofencingClient.addGeofences() (Android). Но для IoT-флота — только серверная сторона.

Серверная геозона обрабатывает до 1000 пакетов в секунду, что в 10 раз больше, чем клиентское решение на одном устройстве. Это критично для парка из сотен трекеров.

Почему серверная проверка предпочтительна для IoT-флота?

IoT-трекеры часто имеют ограниченный бюджет энергии и не могут непрерывно передавать координаты. Серверная проверка позволяет агрегировать данные, применять предикативные фильтры и отправлять уведомления даже при редких пакетах. Мы гарантируем, что при правильной настройке PostGIS и Redis пропускная способность не станет узким местом.

Как работает серверная геозона

PostgreSQL + PostGIS — стандартный стек:

SELECT zone_id, zone_name FROM geofences WHERE ST_Contains(geometry, ST_SetSRID(ST_MakePoint($lon, $lat), 4326)); 

Индекс GIST на geometry ускоряет ST_Contains до микросекунд. При 500 входящих пакетах в секунду от всего флота — нагрузка приемлемая даже на одном инстансе PostgreSQL.

Переход enter/exit определяется через state machine в Redis: при каждом событии сравниваем с предыдущим состоянием устройства. Если было outside → стало inside → emit событие geofence_entered. Более 7 лет опыта в IoT-разработке, реализовано 50+ проектов с геозонами — это проверенная архитектура.

Как избежать потерянных событий при пересечении узких геозон?

Трекер присылает точку раз в 10–30 секунд. При этой частоте устройство может «проскочить» через узкую геозону без единой точки внутри. Решения:

• Увеличить частоту записи при приближении к зоне — некоторые трекеры поддерживают «зону тревоги» и автоматически учащают запись
• Проверять пересечение отрезка [prev_point, cur_point] с границей зоны через ST_Intersects(ST_MakeLine(...), geometry) — ловит транзитные пересечения
• Буферизация: расширяем зону на N метров (ST_Buffer) для раннего предупреждения

Экономия от внедрения буферизации: до 30% потерянных событий восстанавливается без дополнительных затрат на оборудование.

Создание и редактирование геозон в приложении

Пользователь рисует геозону на карте — круг или произвольный полигон.

Круговая зона. Простейший вариант: GMSCircle (Android) / MKCircle (iOS) с центром и радиусом. Пользователь ставит точку, тянет за ручку для изменения радиуса. Хранится как {lat, lng, radius_meters}.

Полигональная зона. Пользователь тапает по точкам на карте, формируя замкнутый контур. GMSPolygon / MKPolygon с live-preview при добавлении точек. Последняя точка соединяется с первой автоматически при нажатии «Закрыть фигуру». Редактирование: перетаскивание вершин (draggable Marker на угловых точках), добавление промежуточных точек через midpoint handles. Это стандартный паттерн для polygon editor на картах. Валидация: самопересечение полигона — ST_IsValid(geometry) на сервере перед сохранением. Клиент получает ошибку и подсвечивает проблемный участок.

Уведомления и реакции

При срабатывании геозоны сервер отправляет push через FCM (Android) / APNs (iOS) с priority: high. Для time-critical алертов (ребёнок вышел из безопасной зоны, грузовик выехал за периметр) используем APNs content-available: 0 (visible push) — он прилетает даже в Doze mode Android. Уведомление содержит: название устройства, название зоны, тип события (вход/выход), время. На iOS — UNNotificationCategory с action «Открыть карту» для быстрого перехода. Deep link передаётся в userInfo payload. В самом приложении — лента событий геозон с фильтрацией по устройству/зоне/типу события. Пагинация через cursor-based pagination (не offset — таблица событий растёт быстро).

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

• Проектирование схемы геозон и архитектуры серверной части
• Реализация API на PostGIS с деплоем на вашу инфраструктуру
• Разработка интерфейса для создания/редактирования зон (iOS + Android)
• Интеграция push-уведомлений (FCM/APNs) с глубокими ссылками
• Тестирование на реальном оборудовании (трекеры одного из заказчиков: при 300 устройствах ни одного потерянного события за месяц)
• Документация по эксплуатации и миграции

Сроки

Реализация геозон (создание/редактирование полигонов + уведомления о пересечениях) при готовой серверной части: 3–5 рабочих дней. Если нужна разработка серверной логики с PostGIS + Redis state machine — 1–2 недели. Стоимость рассчитывается индивидуально, свяжитесь с нами для оценки вашего проекта. Получите консультацию — мы поможем выбрать оптимальный подход.

Источник: Apple Developer Documentation: CLLocationManager — использование геозон на iOS.