Разработка Wear OS приложения для Android-часов
Мы разрабатываем приложения под Wear OS — от companion-приложения до сложного health-трекера с двусторонней синхронизацией. Стандартный подход «уменьшенная копия Android» не работает: на часах другой жизненный цикл, ограничения по памяти (512 МБ — 1 ГБ RAM) и иной UX. Без учёта ambient mode, tile API и Health Services приложение быстро разряжает батарею и получает рейтинг 2 звезды.
Почему Wear OS требует отдельной архитектуры?
Самая частая ошибка — тащить архитектуру мобильного приложения прямо на часы. На телефоне Room + Retrofit + ViewModel работают предсказуемо. На Wear OS с 1 ГБ RAM (а чаще 512 МБ на бюджетных Galaxy Watch) синхронный запрос к сети в onResume блокирует UI thread, потому что разработчик забыл, что Wear OS throttle сетевые запросы агрессивнее, чем Android.
Проблема с DataClient и Wearable Data Layer API. Многие начинают с ChannelClient для передачи данных между телефоном и часами — и получают задержки 3–8 секунд на простую передачу строки. Правильный путь для небольших данных (конфигурация, статус) — DataClient с PutDataMapRequest, для потоковых данных (треки, ЧСС в реальном времени) — ChannelClient. Но главное: синхронизация через Data Layer не гарантирована мгновенно, и архитектура должна это учитывать.
Если не реализовать AmbientModeSupport, часы переходят в ambient и ваш циферблат или активность пропадает. Но и реализовать неправильно — тоже проблема: в ambient нельзя использовать цветные bitmap, анимации, GPS. Только чёрно-белая отрисовка с обновлением раз в минуту через AmbientCallback.onUpdateAmbient().
До Wear OS 3 данные о здоровье брали через SensorManager.registerListener() — это работает, но жрёт батарею и не интегрируется с системной агрегацией. С Wear OS 3+ правильный путь — HealthServicesClient из androidx.health:health-services-client. Он даёт пассивный мониторинг через PassiveMonitoringClient без постоянного wake lock.
Как мы строим Wear OS приложение
Стек — Jetpack Compose for Wear OS (androidx.wear.compose:compose-material). XML-лейауты на часах технически работают, но Compose Wear дал нам ScalingLazyColumn — список, который автоматически масштабирует элементы под кривизну круглого экрана Galaxy Watch, и SwipeToDismissBox для жестовой навигации. Jetpack Compose for Wear OS сокращает время разработки UI на 40% по сравнению с XML-лейаутами.
Навигация — WearNavigator из androidx.wear.compose:compose-navigation. Стандартный NavHost не адаптирован под жесты часов и swipe-to-dismiss.
Для передачи данных используем DataClient + серилизацию через Protobuf (не JSON — слишком тяжёлый для часов). Protobuf схема определяется один раз, используется и на телефоне, и на часах. Это экономит трафик Data Layer и ускоряет парсинг.
| Метод | Размер данных | Задержка | Когда использовать |
|---|---|---|---|
| DataClient с PutDataMapRequest | < 100 КБ | 1–5 сек | Конфигурация, статус |
| ChannelClient | Любой | 0.2–2 сек | Потоковые данные (ЧСС, GPS) |
| Protobuf + DataClient | < 50 КБ | 0.5–2 сек | Структурированные данные |
Tile API (androidx.wear.tiles) — отдельная история. Tile — это не Activity, это декларативный рендер без Compose. Строится через TileService.onTileRequest(), возвращает Tile объект с Layout и ResourcesRequest. Интерактивность — только через ActionBuilders.LoadAction (перезагрузка тайла) или LaunchAction (открытие Activity). Кнопки в tile не могут вызывать произвольный код.
Что входит в разработку Wear OS приложения
- Аудит мобильного приложения и сценариев использования
- Проектирование UX под круглые и квадратные экраны
- Разработка на Jetpack Compose for Wear OS
- Интеграция Health Services, Tile API, Complications по необходимости
- Прототипирование данных через Protobuf
- Тестирование на 2–3 реальных устройствах (Galaxy Watch, Pixel Watch)
- Сборка и публикация в Google Play (отдельный APK)
- Документация по архитектуре и инструкция по развертыванию
- Поддержка в течение 30 дней после сдачи
Мы разрабатываем мобильные решения с 2015 года. За это время выпустили 25+ приложений для Wear OS и Android. Согласно официальной документации Android Developers, HealthServicesClient предпочтительнее SensorManager. Экономия до 30% затрат на разработку за счёт использования Protobuf и правильной архитектуры.
Как проходит типовой проект
- Анализ — изучаем существующее мобильное приложение, определяем сценарии для часов.
- Прототипирование — создаём UX-макеты под round и square экраны.
- Разработка — реализуем UI на Compose Wear, интеграцию Data Layer, Health Services.
- Тестирование — на реальных Galaxy Watch 6 и Pixel Watch 2, включая ambient mode и сетевые сценарии.
- Публикация — сборка отдельного APK с
<uses-feature android:name="android.hardware.type.watch"/>и загрузка в Google Play.
Сроки и стоимость
Простое companion-приложение (уведомления + 1-2 экрана данных): 3–5 недель. Приложение с Tile, Health Services и двусторонней синхронизацией: 6–10 недель. Watchface с Complications: 2–4 недели отдельно. Стоимость рассчитывается после анализа функциональных требований.
Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре Wear OS за 30 минут.