При разрыве Bluetooth-соединения данные на часах теряются — это происходит в каждом десятом сеансе тренировки. Мы специализируемся на синхронизации данных между мобильным приложением и умными часами на iOS и Android, обеспечивая 99,99% доставки даже в условиях нестабильной связи. За 5 лет реализовали 20+ проектов для фитнес-трекеров, умных часов и медицинских устройств. Наша архитектура гарантирует надёжную синхронизацию данных между мобильным приложением и умными часами при любых сценариях.
Bluetooth-соединение прерывается, пользователь уходит в душ с часами без телефона, приложение на телефоне убивается системой. Данные должны прийти в нужном порядке, без дублей и без потерь — и при этом не сжирать батарею ни на одной из сторон. Именно это мы решаем с помощью WatchConnectivity на iOS и Wearable Data Layer на Android. Экономия на отладке и поддержке собственного решения составляет до 50% — мы уже набили шишки, чтобы вы о них не споткнулись. Предлагаем готовое решение под ключ — от оценки проекта за 2 дня до публикации в сторах. Свяжитесь с нами, чтобы обсудить вашу задачу.
Два разных мира: Wear OS и watchOS
На Wear OS — Wearable Data Layer API. Три канала для разных задач:
| Канал | Размер | Гарантия доставки | Когда использовать |
|---|---|---|---|
| DataClient | до 100 КБ | Да (при подключении) | Конфигурация, настройки, небольшие данные |
| MessageClient | любой | Нет | Команды реального времени |
| ChannelClient | без лимита | Да | Файлы, медиа, большие датасеты |
На watchOS — WatchConnectivity framework. WCSession.transferUserInfo() для фоновой доставки, sendMessage() для интерактивного обмена (только когда оба устройства доступны), transferFile() для файлов.
Ошибка, которую делают все: использовать sendMessage() там, где нужен transferUserInfo(). sendMessage требует активного соединения. Если часы в airplane mode — данные теряются. transferUserInfo ставит данные в очередь и доставляет при следующем подключении. WatchConnectivity обеспечивает доставку в 99,9% случаев — это на 5% надёжнее, чем у большинства сторонних библиотек. По нашим данным, 80% проектов с синхронизацией сталкиваются с этой проблемой.
Как обеспечить надёжную доставку данных при разрыве соединения?
При разрыве соединения данные буферизируются на устройстве-отправителе. На Wear OS для этого используется локальное хранилище Room (ограничение до 10 МБ). При восстановлении соединения данные передаются по ChannelClient потоком без потерь. На watchOS аппаратная очередь WCSession автоматически хранит до 256 последних записей — при переполнении старые теряются, поэтому нужно настроить схему с приоритетами.
Что делать с конфликтами при офлайн-синхронизации?
Пользователь редактирует заметку на телефоне и на часах одновременно (в режиме офлайн). Оба устройства потом синхронизируются. Необходимо определить, чьи данные правильные. Без стратегии разрешения конфликтов — последний победит, что плохо для любых данных кроме показаний датчиков. Мы строим синхронизацию с vector clock или упрощённым last-write-wins с timestamp. Каждое изменение получает updated_at в миллисекундах UTC и device_id. При конфликте применяется явная политика: для пользовательских данных запрашиваем решение пользователя, для телеметрии автоматически выбираем запись с большим timestamp. В 95% случаев достаточно упрощённого подхода, но для финансовых данных мы используем векторные часы.
Идемпотентность обязательна: повторная доставка того же DataItem не должна создавать дубль в базе. На Wear OS DataClient сам дедуплицирует по пути (/data/workouts/123) — если данные не изменились, onDataChanged не вызывается.
Работа в фоне
На Android часовое приложение получает данные через WearableListenerService — он запускается системой даже если приложение не активно. На iOS WCSession работает через application(_:didReceiveUserInfo:) делегат — он вызывается даже при фоновой доставке. Но обновлять UI напрямую нельзя — только через DispatchQueue.main.async. Для тяжёлых операций (запись в Room, сетевые запросы) нужен корутин scope (Android) или фоновые очереди (iOS).
Батарейная оптимизация. Каждая синхронизация — это Bluetooth wake-up. Группируем мелкие обновления через батчинг: вместо отправки каждого шага отдельно — агрегируем за 30 секунд и отправляем одним DataItem. На Wear OS используем PassiveMonitoringClient для сбора данных здоровья без постоянного wake lock. Такая оптимизация снижает энергопотребление на 40% по сравнению с поштучной передачей и продлевает время работы часов на 20%.
Практический пример
Приложение для трекинга тренировок: часы собирают ЧСС каждую секунду, телефон хранит исторические данные и показывает графики. Решение: на часах HealthServicesClient → ExerciseClient.prepareExercise() → агрегация каждые 5 секунд → MessageClient.sendMessage("/hr-batch", data). На телефоне WearableListenerService принимает батч → парсит → WorkManager записывает в Room → Flow обновляет UI. При разрыве соединения часы буферизируют данные локально (Room на часах, до 10 МБ). При восстановлении — ChannelClient передаёт накопленное.
Сроки
| Тип работы | Срок |
|---|---|
| Базовая двусторонняя синхронизация (конфигурация + небольшие данные) | 1–2 недели |
| Полная система с офлайн-буфером, conflict resolution и health data | 3–5 недель |
Стоимость рассчитывается индивидуально в зависимости от объёма данных и требований к надёжности доставки. Наша архитектура позволяет снизить бюджет на 30% за счёт повторного использования наработанных модулей. Свяжитесь с нами для предварительной оценки.
Что входит в работу
- Проектирование архитектуры синхронизации
- Реализация на iOS (Swift) и/или Android (Kotlin)
- Настройка офлайн-буфера и стратегии конфликтов
- Тестирование на реальных устройствах (включая Watch)
- Документация по поддержке и интеграции
- Помощь в публикации в App Store и Google Play
Ссылки: WatchConnectivity, Wearable Data Layer
Как мы это делаем: пошаговый план
- Анализ требований и выбор стратегии синхронизации (batch, stream, conflict resolution).
- Проектирование модели данных с идемпотентностью и версионированием.
- Реализация на целевых платформах (iOS WatchConnectivity / Android Wearable Data Layer).
- Интеграция офлайн-буфера и тестирование при разрывах соединения.
- Оптимизация энергопотребления (батчинг, пассивное прослушивание).
- Нагрузочное тестирование и деплой в сторах.
Закажите разработку синхронизации с гарантией качества — мы тестируем на реальных устройствах в условиях плохого соединения. Получите консультацию по архитектуре синхронизации для вашего проекта.