전원 및 배터리 절약

전원 효율은 Wear OS에서 특히 중요합니다. Wear OS 디자인 원칙은 기기 전력 사용량에 크게 초점을 맞춥니다. 시계가 짧은 상호작용을 위한 작은 폼 팩터이기 때문입니다.

Wear OS 기기는 큰 휴대기기에 비해 배터리가 작으므로 배터리 소모가 더 두드러집니다. 또한 Wear OS 기기는 휴대기기에 비해 충전하는 데 더 많은 노력이 필요합니다. 사용자는 하루 종일 다양한 간격으로 휴대기기를 충전할 수 있지만 기기를 충전하기 전에 Wear OS 기기를 몸에서 분리해야 합니다.

앱의 전력 효율성을 개선하려면 다음 디자인 권장사항을 따르세요.

  • 앱 디자인은 Wear OS 폼 팩터를 잘 활용해야 합니다. 모바일 앱을 직접 복사해서는 안 됩니다.
  • 기존 모바일 앱을 사용하여 특정 사용 사례를 지원하세요. 예를 들어 시계의 인터넷과 동기화는 비용이 많이 듭니다. 휴대기기가 어려운 작업을 할 수 있고 Wear OS 기기가 데이터 변경사항을 수신하는지 고려하세요.
  • 짧은 상호작용을 위해 사용 사례를 설계합니다.
  • 사용하는 Wear OS 이벤트와 이러한 이벤트의 발생 빈도를 고려하세요.

  • 가능하면 시계가 충전될 때까지 앱 작업을 연기하세요. 이는 특히 데이터 동기화, 데이터베이스 구성과 같은 데이터 집약적인 작업에 적용됩니다.

    기기가 충전 중이고 Wi-Fi에 연결되어 있다면 사용자가 앱에서 보고 싶어 할 만한 데이터, 이미지, 업데이트를 미리 가져오는 작업을 예약합니다.

이 전원 가이드는 시스템에서 앱이 언제 어떻게 실행되는지, 앱의 런타임과 배터리 소모를 제한하는 방법을 이해하는 데 도움이 됩니다. 특정 작업이 실행되는 방법(예: 앱 로드 또는 목록 스크롤)에 관한 자세한 내용은 Wear OS의 Compose 성능 가이드와 같은 성능 관련 가이드를 참고하세요.

시간 경과에 따른 배터리 사용량 모니터링

앱을 실행하는 Wear OS 기기의 배터리 통계를 분석하려면 개발 머신의 터미널 창에 다음 명령어를 입력합니다.

adb shell dumpsys batterystats

GitHub의 라이브러리에는 이 명령어와 함께 실행하는 데 유용할 수 있는 배터리 통계 파서가 있습니다.

배터리 수명에 영향을 주는 이벤트

앱을 구체적으로 고려하기 전에 Wear OS 기기의 전력을 소모하는 이벤트에 관해 더 일반적으로 생각하는 것이 좋습니다.

다음 표는 Wear OS 앱의 여러 일반적인 이벤트에서 배터리 수명에 미치는 상대적인 영향을 보여줍니다. 정확한 전력 소모는 기기에 따라 다릅니다.

이벤트 배터리 수명에 미치는 영향 완화 방법
LTE 및 Wi-Fi를 포함한 네트워크에 액세스합니다. 매우 많음 기기가 충전될 때까지 필수적이지 않은 네트워크 액세스를 연기합니다.
화면을 켜고 대화형 모드 시작 높음 사용자에게 필요 이상으로 오래 화면을 켜두도록 권장하지 않습니다. 상시 사용 설정 모드(대기 모드라고도 함)를 사용하는 환경을 제공합니다.
GPS 센서 액세스 높음 가능하면 사용자가 GPS 액세스를 요청할 때까지 기다립니다.
CPU 사용량을 높게 유지 높음 Jetpack Compose를 사용하여 흐름 사용
심박수 센서에 액세스하기 Medium 센서 API에서 콜백을 수신할 때(예: Wear OS에서 건강 관리 서비스 사용 시) 프로세서의 절전 모드 해제 시간을 사용합니다.
블루투스를 통해 다른 기기에 액세스 Medium 세션을 짧게 유지하세요.
wake lock 유지 Medium wakelock의 수동 생성을 줄이고 WorkManager를 사용합니다.

기기 사용 시간 최소화

Wear OS 앱에서 다음과 같은 화면 사용 원칙을 따르세요.

  • 화면 켜기 잠금: 가능하면 사용하지 않는 것이 좋습니다. 테스트하려면 시스템 설정에서 항상 켜져 있는 화면을 사용 중지하고 화면이 제한 시간 내에 꺼지는지 관찰합니다.
  • 애니메이션: 정교한 애니메이션을 최소화하고 간단한 전환에 집중하여 좀 더 전문적으로 보이도록 하세요. 특히 장시간 실행되는 애니메이션과 루프는 피하는 것이 좋습니다. 루프가 필요한 경우 루프 사이에 애니메이션 자체의 길이만큼 일시중지를 추가합니다.

  • 대기 모드의 깨어 있는 시간: 피트니스 사용 사례와 같이 필요한 경우 상시 사용 설정을 지원합니다. 앱에 상시 사용 설정이 필요한 경우 기기가 대기 모드일 때 앱이 다음을 실행하는지 확인합니다.

    • 기기 화면에서 조명이 켜지는 비율을 줄입니다.
    • 애니메이션을 표시하지 않습니다.
    • onAmbientUpdate() 콜백 도중을 제외하고 화면의 콘텐츠를 업데이트하지 않습니다.

CPU 사용량 최소화

Wear OS 앱에서 다음 CPU 사용 원칙을 따르세요.

  • 사용법을 짧게
  • 관련 작업을 일괄 처리하여 앱의 프로세스가 유휴 상태인 시간을 최대화합니다.

wakelock 최소화

대부분의 경우 wakelock과 같이 앱이 절전 모드로 전환되지 못하게 하는 작업은 피하세요. 예를 들어 건강 및 피트니스 앱의 경우 오래 실행되는 운동에는 wakelock이 필요하지 않습니다. 센서 API에서 콜백을 수신할 때(예: Wear OS에서 건강 관리 서비스 사용 시) 프로세서의 절전 모드 해제 시간을 사용합니다.

앱이 다음 중 하나를 실행하는 경우와 같이 wakelock을 획득해도 괜찮은 몇 가지 경우가 있습니다.

  • 백그라운드에서 미디어를 재생합니다.
  • WorkManager 또는 JobScheduler를 사용합니다. 백그라운드에서 작업을 실행할 때 시스템은 개발자를 대신하여 wakelock을 유지합니다.

Battery Historian을 사용하면 긴 wakelock의 개별 발생과 유지 중인 wakelock의 총 개수 및 지속 시간을 확인할 수 있습니다. 앱이 보유하고 있는 wakelock의 수와 지속 시간을 검사하고 이 정보를 앱의 대화형 사용 패턴과 비교합니다.

  • 예기치 않은 wakelock 확인
  • 기간이 예상보다 길면 네트워크 가용성과 같은 일부 종속 항목에서 작업이 차단되는지 고려합니다.

앱이 어떻게 비활성화되는지 검사

다음과 같은 주요 기기 이벤트가 발생할 때 활성 앱이 어떤 작업을 하는지 고려하세요.

  • 화면이 꺼지고 기기가 대기 모드로 전환됩니다.

  • 앱이 스와이프하여 닫힙니다.

앱 활동을 분석하려면 다음 섹션에 나와 있는 도구를 사용하세요.

에너지 프로파일러

에너지 프로파일러는 Android 스튜디오 메뉴에서 View > Tool Windows > Profiler를 선택하여 액세스할 수 있습니다.

  1. 화면이 꺼지고 기기가 대기 모드로 전환될 때 시스템 트레이스를 검사합니다.
  2. 계속 진행되는 작업과 기기의 CPU 사용량 수준을 찾습니다.

Perfetto

Perfetto를 사용하면 트레이스를 기록한 다음 앱을 검사하여 화면이 꺼지거나 기기가 대기 모드로 전환되거나 사용자가 앱의 활동을 닫을 때 작업을 실행하는 스레드가 있는지 확인할 수 있습니다.

맞춤 이벤트를 정의하여 도메인별 이벤트를 비롯한 앱의 중요한 이벤트를 표시합니다. 미디어 앱의 경우 여기에는 재생목록 가져오기, 특정 미디어 항목 다운로드, 재생 시작, 재생 중지와 같은 작업이 포함됩니다. 이러한 이벤트를 정의하면 Perfetto에서 이벤트를 확인하고 타이밍을 앱의 CPU 및 전력 사용량과 비교할 수 있습니다.

앱의 예약된 작업 분석

WorkManager를 사용하여 예약된 작업을 사용하면 앱에서 백그라운드 작업을 실행할 수 있습니다. 일부 백그라운드 작업은 주기적이어야 하지만, 작업을 너무 자주 실행하거나 장시간 실행하지는 마세요. 기기의 배터리가 소모될 수 있습니다.

Battery Historian을 사용하여 전체 (시스템 통계 > Jobscheduler 통계) 및 앱별로 (앱 통계 > 예약된 작업) 예약된 작업의 실행을 검사합니다. 총 개수와 총 지속 시간을 확인합니다.

  • 작업이 매우 자주 실행되는 경우 이 실행 빈도를 줄이는 것이 좋습니다.
  • 총 실행 시간이 예상과 일치하며 훨씬 길지 않은지 확인합니다.

또한 각 JobScheduler 항목을 살펴보며 Battery Historian 그래프를 검사합니다. 특정 항목 위에 포인터를 가져가면 Battery Historian에서 실행 중인 작업의 소유자를 표시합니다. 다음을 고려하세요.

  • 앱의 경우 실행 시간이 타당해야 합니다.
  • 작업이 앱이 실행되는 동안 발생하는지 또는 작업이 주기적인 백그라운드 작업을 나타내는지 고려합니다.

센서

Wear OS 기기에는 GPS와 같은 다양한 센서가 있습니다. 대부분의 경우 SensorManager와 직접 상호작용하는 대신 Wear OS의 건강 관리 서비스를 사용합니다. 많은 경우 건강 관리 서비스는 데이터를 지능적으로 일괄 처리하여 배터리 성능을 개선합니다.

앱의 센서 사용량을 분석하려면 개발 머신의 터미널 창에서 다음 명령어를 실행합니다.

adb shell dumpsys sensorservice

이 명령어의 결과는 다음과 같습니다.

  • 현재 및 이전 센서 등록
  • 센서 구성(설정된 경우 일괄 처리 포함)
  • 최근에 샘플링한 데이터입니다.

센서에서 등록 취소 테스트

앱이 센서 데이터를 예상대로 가져오는 것을 중지하는지 확인하려면 다음 시나리오를 테스트하세요.

  1. 앱을 스와이프하여 닫습니다.
  2. 손바닥으로 화면을 탭합니다. 그러면 화면이 꺼지거나 화면이 대기 모드로 전환됩니다.

이전 섹션의 ADB 명령어를 사용하여 센서가 등록되지 않은 것으로 올바르게 표시되는지 확인합니다.

데이터 계층

Data Layer API를 사용하는 경우 각 전송은 전력을 소비합니다. 특히 이 API를 사용하여 데이터를 전송하는 경우 데이터를 수신하기 위해 앱이 절전 모드에서 해제되어야 합니다. 따라서 신중하게 API를 사용해야 합니다.

Data Layer API 사용에 관한 추가 권장사항은 다음과 같습니다.

  • 앱이 활성 상태가 될 때까지 기다린 후 WearableListenerService를 사용하여 리스너를 설정합니다.

  • 빠른 업데이트를 구성하는 대신 상태 변경사항을 전송합니다. 이러한 상태 변경을 통해 Wear OS 기기가 운동 세션이 시작된 때와 같이 로컬 데이터 계산을 실행할 수 있습니다.

    UI를 업데이트하는 상태 변경사항만 전송합니다. 예를 들어 활동 화면에 소수점 이하 한 자리까지만 '달린 킬로미터'라고 표시되면 사용자가 다른 미터 앞으로 이동할 때마다 Wear OS에 상태 변경사항을 전송하지 마세요.

앱에서 Data Layer API 사용량을 분석하려면 개발 머신의 터미널 창에서 다음 명령어를 실행합니다.

adb shell dumpsys activity service WearableService

이 명령어의 결과에는 다음이 포함됩니다.

  • RpcService: MessageClient를 사용하여 호출되는 빈도와 경로를 확인할 수 있습니다.
  • DataService: DataClient를 사용하여 데이터 항목이 설정되는 빈도를 확인할 수 있습니다.

건강/피트니스 앱

건강 및 피트니스 앱을 유지하는 경우 건강 서비스를 사용하여 앱의 센서 사용을 최적화하세요.

  • ExerciseClient의 경우 Battery Historian을 사용하여 대기 모드에서 올바른 동작을 확인합니다. ExerciseUpdate 데이터를 수신할 때 앱의 절전 모드가 1~2분 이상 자주 해제되지 않는지 확인하세요.
  • 종일 일반 건강 모니터링의 경우 백그라운드에서 건강 및 피트니스 데이터를 모니터링하는 방법에 관한 가이드에 설명된 대로 PassiveMonitoringClient를 사용하세요.

카드 및 정보 표시

앱에서 카드 또는 정보 표시를 지원한다면 다음 권장사항을 따르세요.

  • 자동 새로고침을 사용 중지하거나 새로고침 빈도를 2시간 이상으로 늘립니다.
  • Firebase 클라우드 메시징 (FCM) 또는 적절한 예약된 작업을 사용하여 데이터 업데이트를 전송합니다. 업데이트 속도가 빠르면 시스템이 사용자 또는 플랫폼이 작업을 실행하는 데 필요한 데이터에 액세스할 수 있는 것보다 빠른 속도로 반복 작업을 예약할 수 있으므로 주의해야 합니다.
  • 사용자가 상호작용하지 않을 때는 카드 또는 정보 표시 작업을 예약하지 마세요.
  • 오프라인 우선 접근 방식을 사용합니다.
  • 기본 앱, 카드, 정보 표시에서 단일 데이터베이스를 공유합니다. 이렇게 하면 UI 노출 영역 전반에서 데이터를 일관되게 유지할 수 있습니다.