Розробка Wear OS приложення (Android-годинники)
Wear OS 4 — це вже не «зменшена копія Android». Там інший життєвий цикл, інші обмеження по пам'яті та інший спосіб думати про 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 не гарантована миттєво, та архітектура має це урахувати.
Ambient mode. Якщо не реалізувати AmbientModeSupport, годинник переходить в ambient та ваш циферблат або активність пропадає. Але і реалізувати неправильно — теж проблема: в ambient не можна використовувати кольорові bitmap, анімації, GPS. Лише чорно-біла відрисовка з оновленням раз в хвилину через AmbientCallback.onUpdateAmbient().
Health Services API vs застарілий SensorManager. До 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 для жестової навігації.
Навігація — 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). Кнопки в tile не можуть викликати довільний код.
Тест на реальному залізі обов'язковий. Емулятор Wear OS в Android Studio не відтворює поведінку ambient mode, throttling мережі та реальне споживання батареї. Тестуємо на Galaxy Watch 6 (Wear OS 4, Exynos W930) та Pixel Watch 2 (Wear OS 4, Snapdragon W5 Gen 1).
Процес роботи
Починаємо з аудиту існуючого мобільного додатка — які дані потрібні на часах, який сценарій використання (спорт, сповіщення, управління розумним домом). Це визначає, потрібен ли Tile, Complication, Watchface або повноцінне додаток.
Проектування UX під round/square екрани (Galaxy Watch та Pixel Watch — різні пропорції). Розробка з Compose Wear. Інтеграція Health Services якщо потрібен біометричний мониторинг. Тестування на 2–3 пристроях різних поколінь.
Публікація через Google Play з окремим APK для Wear OS (<uses-feature android:name="android.hardware.type.watch"/>). З Wear OS 3 часове додаток можна встановлювати незалежно від телефонного.
Сроки
Простой companion-додаток (сповіщення + 1-2 екрана даних): 3–5 тижнів. Додаток з Tile, Health Services та двусторонней синхронізацією: 6–10 тижнів. Watchface з Complications: 2–4 тижні окремо. Вартість розраховується після аналізу функціональних вимог.