전원 및 배터리 절약

전력 효율은 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 Wear OS에서 건강 관리 서비스를 사용할 때와 같이 센서 API에서 콜백을 수신할 때 프로세서의 절전 모드 해제 시간을 사용합니다.
블루투스를 통해 다른 기기에 액세스 Medium 세션을 짧게 유지합니다.
wakelock 유지 Medium wakelock의 수동 생성을 줄이고 WorkManager를 사용합니다.

화면 켜짐 시간 최소화

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

  • 화면 켜기 잠금: 가능하면 항상 사용하지 마세요. 테스트하려면 시스템 설정에서 디스플레이 항상 켜기를 사용 중지하고 제한 시간 내에 화면이 꺼지는지 관찰하세요.
  • 애니메이션: 정교한 애니메이션을 최소화하고 간단한 전환에 집중하여 더 전문적인 느낌을 줍니다. 특히 장시간 실행되는 애니메이션과 루프는 피하는 것이 좋습니다. 루프가 필요한 경우 루프 사이에 일시중지를 추가하세요(최소 애니메이션 자체 길이).
  • 대기 모드에서 깨어 있는 시간: 피트니스 사용 사례와 같이 필요한 경우 상시 사용 설정을 지원합니다. 앱에 상시 사용 설정이 필요한 경우 기기가 대기 모드일 때 앱이 다음을 실행하는지 확인합니다.

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

CPU 사용량 최소화

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

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

wakelock 최소화

대부분의 경우 wakelock과 같이 앱의 절전 모드를 방해하는 모든 작업은 피해야 합니다. 예를 들어 건강/피트니스 앱에서는 장기 실행 운동에 wakelock이 필요하지 않습니다. Wear OS에서 건강 관리 서비스를 사용할 때와 같이 센서 API에서 콜백을 수신할 때 프로세서의 절전 모드 해제 시간을 사용합니다.

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

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

Battery Historian을 사용하면 긴 wakelock 개별 발생 횟수뿐만 아니라 유지된 wake lock의 총 횟수 및 지속 시간에 관한 요약을 확인할 수 있습니다. 앱에서 보유한 wakelock의 수와 지속 시간을 검사하고 이 정보를 앱의 대화형 사용 패턴과 비교합니다.

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

앱이 비활성화되는 방식 검사

다음과 같은 주요 기기 이벤트가 발생할 때 활성 앱의 동작을 고려합니다.

  • 화면이 꺼지고 기기가 대기 모드로 전환됩니다.
  • 앱이 스와이프하여 닫혔습니다.

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

에너지 프로파일러

Energy Profiler는 Android 스튜디오 메뉴에서 View > Tool Windows > Profiler를 선택하여 액세스할 수 있습니다.

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

Perfetto

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

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

앱의 예약된 작업 분석

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

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

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

또한 Battery Historian 그래프를 검사하고 각 JobScheduler 항목을 확인합니다. 포인터를 특정 항목 위로 가져가면 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 노출 영역 전체에서 데이터의 일관성을 유지하는 데도 도움이 됩니다.