Розробка 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 агресивніше тротлить мережеві запити, ніж 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. Офіційна документація Android Developers рекомендує HealthServicesClient замість SensorManager.
Як вибрати правильний API для синхронізації?
Різні API підходять для різних сценаріїв. Ось порівняння:
| Метод | Розмір даних | Затримка | Коли використовувати |
|---|---|---|---|
| DataClient з PutDataMapRequest | < 100 КБ | 1–5 сек | Конфігурація, статус |
| ChannelClient | Будь-який | 0.2–2 сек | Потокові дані (ЧСС, GPS) |
| Protobuf + DataClient | < 50 КБ | 0.5–2 сек | Структуровані дані |
Порівняння Protobuf vs JSON
Protobuf працює в 5 разів швидше за JSON на Wear OS завдяки меншому розміру та бінарному формату. Економія трафіку до 70%.Як ми будуємо Wear OS додаток
Стек — Jetpack Compose for Wear OS (androidx.wear.compose:compose-material). XML-лейаути на годиннику технічно працюють, але Compose Wear дав нам ScalingLazyColumn — список, який автоматично масштабує елементи під кривизну круглого екрану Galaxy Watch, та SwipeToDismissBox для жестової навігації. Compose скорочує час розробки UI на 40% у порівнянні з XML.
Навігація — WearNavigator з androidx.wear.compose:compose-navigation. Стандартний NavHost не адаптований під жести годинника та swipe-to-dismiss.
Для передачі даних використовуємо DataClient + серіалізацію через Protobuf (не JSON — занадто важкий). Protobuf схема визначається один раз і використовується на всіх платформах. Це економить трафік Data Layer та прискорює парсинг.
Tile API (androidx.wear.tiles) — окрема історія. Tile — це не Activity, це декларативний рендер без Compose. Будується через TileService.onTileRequest(), повертає об'єкт Tile з Layout та ResourcesRequest. Інтерактивність — тільки через ActionBuilders.LoadAction (перезавантаження тайла) або LaunchAction (відкриття Activity).
Що входить в розробку Wear OS додатку
- Аудит мобільного додатку та сценаріїв використання
- Проектування UX під круглі та квадратні екрани
- Розробка на Jetpack Compose for Wear OS
- Інтеграція Health Services, Tile API, Complications за необхідності
- Прототипування даних через Protobuf
- Тестування на 2–3 реальних пристроях (Galaxy Watch, Pixel Watch)
- Збірка та публікація в Google Play (окремий APK)
- Документація по архітектурі та інструкція з розгортання
- Підтримка протягом 30 днів після здачі
Маємо 5+ років на ринку та понад 25 реалізованих проєктів для Wear OS та Android. Економія до 30% витрат завдяки Protobuf та правильній архітектурі. Приклад вартості: простий companion-додаток від $5000.
Як проходить типовий проект
- Аналіз — вивчаємо існуючий мобільний додаток, визначаємо сценарії для годинника.
- Прототипування — створюємо 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 хвилин.