제품 소식

Android vitals wake lock 측정항목을 사용하여 앱 배터리 최적화

7분 읽기
Alice Yuan
개발자 관계팀 엔지니어

배터리 수명은 사용자 환경의 중요한 측면이며 wake lock은 중요한 역할을 합니다. wake lock을 과도하게 사용하고 있나요? 이 블로그 게시물에서는 wake lock이 무엇인지, wake lock 사용에 관한 권장사항은 무엇인지, Play Console 측정항목을 사용하여 자체 앱의 동작을 더 잘 이해하는 방법을 알아봅니다.

Android vitals의 과도한 부분적인 wake lock 사용

이제 Play Console은 주요 실적 지표로 과도한 부분적인 wake lock 사용에 중점을 두고 배터리 소모를 모니터링합니다.

이 기능은 과도한 사용자 인식 비정상 종료 및 ANR이라는 기존 핵심 측정항목 안정성 지표와 함께 배터리 효율성의 중요성을 높입니다.Google은 과도한 wake lock에 관한 비정상적인 동작 기준을 정의했습니다. 2026년 3월 1일부터 제목이 이 품질 기준을 충족하지 않는 경우 추천과 같은 눈에 띄는 검색 표시 경로에서 제목을 제외할 수 있습니다. 경우에 따라 앱이 과도한 배터리 소모를 일으킬 수 있음을 사용자에게 알리기 위해 스토어 등록정보에 경고를 표시할 수 있습니다.

warning.png

Android vitals 개요의 과도한 wake lock 경고.

휴대기기의 경우 Android vitals 측정항목은 화면이 꺼져 있고 앱이 백그라운드에 있거나 포그라운드 서비스를 실행하는 동안 획득한 면제되지 않은 wake lock에 적용됩니다. Android vitals는 다음과 같은 경우 부분적인 wake lock 사용이 과도하다고 간주합니다.

오디오, 위치, JobScheduler 사용자 시작 API로 만든 wake lock은 wake lock 계산에서 제외됩니다.

wake lock 이해

wake lock은 사용자가 기기와 활발하게 상호작용하지 않는 경우에도 앱이 기기의 CPU를 계속 실행할 수 있도록 하는 메커니즘입니다. 

부분적인 wake lock은 화면이 꺼져 있어도 CPU를 계속 실행하여 CPU가 저전력 '일시중지' 상태로 전환되지 않도록 합니다. 전체 wake lock은 화면과 CPU를 모두 계속 실행합니다.

부분적인 wake lock을 획득하는 방법에는 두 가지가 있습니다.

  • 앱은 특정 사용 사례를 위해 PowerManager API를 사용하여 wake lock을 수동으로 획득하고 해제합니다. 이는 포그라운드 서비스(사용자가 인지할 수 있는 작업을 위한 플랫폼 수명 주기 API)와 함께 획득되는 경우가 많습니다.
  • 또는 wake lock은 다른 API에 의해 획득되고 API 사용으로 인해 앱에 할당됩니다. 자세한 내용은 권장사항 섹션을 참고하세요.

wake lock은 사용자가 시작한 대용량 파일 다운로드 완료와 같은 작업에 필요하지만 과도하거나 부적절하게 사용하면 배터리가 크게 소모될 수 있습니다. 앱이 몇 시간 동안 wake lock을 유지하거나 제대로 해제하지 못하여 사용자가 앱과 상호작용하지 않을 때도 배터리 소모가 크게 발생한다고 불만을 제기하는 사례가 있었습니다.

wake lock 사용 권장사항

과도한 wake lock 사용을 디버그하는 방법을 알아보기 전에 wake lock 권장사항을 따르고 있는지 확인하세요. 

다음 네 가지 중요한 질문을 고려하세요.


1. 대체 wake lock 옵션을 고려해 보셨나요?

수동 부분적인 wake lock 획득을 고려하기 전에 다음 의사 결정 흐름도를 따르세요.

wakelock.png

wake lock을 수동으로 획득할 시점을 결정하는 흐름도

  1. 화면을 계속 켜야 하나요?
  2. 애플리케이션에서 포그라운드 서비스를 실행하고 있나요?
    • 아니요: wake lock을 수동으로 획득할 필요가 없습니다.
  3. 기기가 일시중지되면 사용자 환경에 해로운가요?
    • 아니요: 예를 들어 기기가 절전 모드에서 해제된 후 알림을 업데이트하는 데는 wake lock이 필요하지 않습니다.
    • 예: 외부 기기와의 지속적인 통신과 같이 기기가 일시중지되지 않도록 하는 것이 중요한 경우 계속 진행합니다.
  4. 이미 기기를 절전 모드에서 해제하는 API가 있나요?
  5. 이러한 모든 질문에 답변하고 대안이 없다고 판단한 경우 wake lock을 수동으로 획득해야 합니다.

2. wake lock 이름을 올바르게 지정하고 있나요?

wake lock을 수동으로 획득할 때는 디버깅을 위해 올바른 이름 지정이 중요합니다.

  • 이메일 주소와 같은 이름에 개인 식별 정보 (PII)를 포함하지 마세요. PII가 감지되면 wake lock이 _UNKNOWN으로 로깅되어 디버깅이 방해됩니다.
  • 클래스 또는 메서드 이름을 사용하여 프로그래매틱 방식으로 wake lock 이름을 지정하지 마세요. 이러한 이름은 Proguard와 같은 도구로 난독화될 수 있습니다. 대신 하드 코딩된 문자열을 사용하세요.
  • wake lock 태그에 카운터 또는 고유 식별자를 추가하지 마세요. wake lock이 실행될 때마다 동일한 태그를 사용하여 시스템에서 이름별로 사용량을 집계할 수 있도록 해야 비정상적인 동작을 더 쉽게 감지할 수 있습니다.

3. 획득한 wake lock이 항상 해제되나요?

wake lock을 수동으로 획득하는 경우 wake lock 해제가 항상 실행되도록 하세요. wake lock을 해제하지 못하면 배터리가 크게 소모될 수 있습니다. 

예를 들어 processingWork() 중에 포착되지 않은 예외가 발생하면 release() 호출이 발생하지 않을 수 있습니다. 대신 try-finally 블록을 사용하여 예외가 발생하더라도 wake lock이 해제되도록 할 수 있습니다.

또한 wake lock에 제한 시간을 추가하여 특정 기간 후에 해제되도록 하여 무기한 유지되지 않도록 할 수 있습니다.

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. wake-up 빈도를 줄일 수 있나요?

주기적인 데이터 요청의 경우 앱이 기기를 절전 모드에서 해제하는 빈도를 줄이는 것이 배터리 최적화의 핵심입니다. wake-up 빈도를 줄이는 몇 가지 예는 다음과 같습니다.

  • WorkManager: PeriodicWorkRequests에서 주기적 간격을 늘립니다.
  • SensorManager: 리스너를 등록할 때 maxReportLatencyMs를 지정하여 일괄 처리를 활용합니다.
  • 통합 위치 정보 제공자:
    • 가장 최근에 캐시된 위치에 getLastLocation을 사용하여 위치 검색 빈도를 줄입니다.
    • 배터리 소모가 적은 업데이트 방법에는 setPriority(PRIORITY_PASSIVE)를 사용합니다.
    • 또한 setMinUpdateIntervalMillis로 최소 업데이트 간격을 설정하여 위치 일괄 처리 메커니즘을 활용할 수 있습니다.

자세한 내용은 wake lock 권장사항 문서를 참고하세요.

과도한 wake lock 사용 디버그

최선을 다하더라도 과도한 wake lock 사용이 발생할 수 있습니다. Play Console에서 앱에 플래그가 지정된 경우 디버그하는 방법은 다음과 같습니다.

Play Console을 사용한 초기 식별

Android vitals 과도한 부분적인 wake lock 대시보드는 앱과 연결된 면제되지 않은 wake lock 이름의 분석을 제공하여 영향을 받는 세션과 기간을 보여줍니다. 문서를 사용하여 wake lock 이름이 앱에서 유지되는지 아니면 다른 API에서 유지되는지 식별하는 데 도움이 되도록 하세요.

breakdowns2.png

과도한 wake lock 태그를 보기 위해 분석 섹션으로 아래로 스크롤된 Android vitals 과도한 부분적인 wake lock 대시보드

작업자/작업에서 유지하는 과도한 wake lock 디버그

이 wake lock 이름으로 작업자에서 유지하는 wake lock을 식별할 수 있습니다.

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

작업자에서 유지하는 wake lock 이름의 전체 변형 목록은 문서에서 확인할 수 있습니다. 이러한 wake lock을 디버그하려면 Background Task Inspector를 사용하여 로컬에서 디버그하거나 getStopReason을 활용하여 현장에서 문제를 디버그할 수 있습니다. 

Android 스튜디오 Background Task Inspector

taskinspector.png


Background Task Inspector의 화면 캡처로, 자주 재시도하고 실패한 작업자 'WeatherSyncWorker'를 식별할 수 있었습니다.

WorkManager 문제를 로컬에서 디버그하려면 에뮬레이터 또는 연결된 기기 (API 수준 26 이상)에서 이 도구를 사용하세요. 작업자 목록과 상태 (완료됨, 실행 중, 대기 중)를 표시하여 세부정보를 검사하고 작업자 체인을 이해할 수 있습니다. 

예를 들어 시스템 제한에 도달하여 작업자가 자주 실패하거나 재시도하는지 확인할 수 있습니다. 

자세한 내용은 Background Task Inspector 문서를 참고하세요.

WorkManager getStopReason

과도한 wake lock이 있는 작업자를 현장에서 디버그하려면 WorkManager 2.9.0+에서 WorkInfo.getStopReason()을 사용하거나 JobScheduler의 경우 SDK 31+에서 사용할 수 있는 JobParameters.getStopReason()을 사용하세요. 

이 API는 작업자가 중지된 이유 (예: STOP_REASON_TIMEOUT, STOP_REASON_QUOTA)를 로깅하여 런타임 기간 소진으로 인한 빈번한 제한 시간 초과와 같은 문제를 정확히 파악하는 데 도움이 됩니다.

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

자세한 내용은 작업 예약 API의 배터리 사용 최적화를 참고하세요.

다른 유형의 과도한 wake lock 디버그

수동으로 유지되는 wake lock 또는 wake lock을 유지하는 API와 관련된 더 복잡한 시나리오의 경우 시스템 트레이스 수집을 사용하여 디버그하는 것이 좋습니다.

시스템 트레이스 수집

시스템 트레이스 는 일정 기간 동안의 시스템 활동에 관한 세부 기록을 캡처하여 CPU 상태, 스레드 활동, 네트워크 활동, 작업 기간 및 wake lock 사용과 같은 배터리 관련 측정항목에 관한 통계를 제공하는 강력한 디버깅 도구입니다.

여러 가지 방법으로 시스템 트레이스를 캡처할 수 있습니다.

powermgmt.png

Android 앱 및 서비스 탭의 Perfetto UI에서 'power:PowerManagement' Atrace 카테고리를 사용 설정합니다. 

선택한 방법과 관계없이 기기 상태 트랙을 볼 수 있도록 'power:PowerManagement' Atrace 카테고리를 수집하는 것이 중요합니다. 

Perfetto UI 검사 및 SQL 분석

시스템 트레이스는 Perfetto UI 에서 열고 검사할 수 있습니다. 트레이스를 열면 타임라인에 다양한 프로세스의 시각화가 표시됩니다. 이 가이드에서 중점적으로 다룰 트랙은 '기기 상태'에 있는 트랙입니다.

perfetto.png


'상위 앱', '화면 상태', '장기간 wake lock', '작업' 트랙과 같은 '기기 상태' 아래의 트랙을 고정하여 장기 실행 wake lock 슬라이스를 시각적으로 식별합니다.

각 블록에는 이벤트 이름, 이벤트가 시작된 시간, 이벤트가 종료된 시간이 나열됩니다. Perfetto에서는 이를 슬라이스라고 합니다.

여러 트레이스를 확장 가능한 방식으로 분석하려면 Perfetto의 SQL 분석을 사용하면 됩니다. SQL 쿼리는 기간별로 정렬된 모든 wake lock을 찾아 과도한 사용에 가장 큰 영향을 미치는 요인을 식별하는 데 도움이 됩니다.

다음은 총 기간별로 정렬된 시스템 트레이스에서 발생한 모든 wake lock 태그를 합산하는 쿼리의 예입니다.

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

현장 트레이스 수집에 ProfilingManager 사용

재현하기 어려운 문제의 경우 ProfilingManager (SDK 35에 추가됨)는 개발자가 시작 및 종료 트리거를 사용하여 현장에서 시스템 트레이스를 수집할 수 있는 프로그래매틱 API입니다. 프로필 수집의 시작 및 종료 트리거 지점을 더 세밀하게 제어할 수 있으며 기기 성능에 미치는 영향을 방지하기 위해 시스템 수준의 비율 제한을 적용합니다. 

트레이스를 프로그래매틱 방식으로 캡처하고, 프로파일링 데이터를 분석하고, 로컬 디버그 명령어를 사용하는 방법을 비롯하여 현장 시스템 트레이스 수집을 구현하는 방법에 관한 자세한 단계는 ProfilingManager 문서를 참고하세요.

ProfilingManager를 사용하여 수집된 시스템 트레이스는 수동으로 수집된 트레이스와 비슷하지만 시스템 프로세스 및 기타 앱 프로세스는 트레이스에서 수정됩니다.

결론

Android vitals의 과도한 부분적인 wake lock 측정항목은 배터리 소모를 줄이고 앱 품질을 개선하는 데 개발자를 지원하기 위한 Google의 지속적인 노력의 일부일 뿐입니다. 

wake lock을 이해하고 올바르게 구현하면 앱의 배터리 성능을 크게 최적화할 수 있습니다. 대체 API를 활용하고, wake lock 권장사항을 준수하고, Background Task Inspector, 시스템 트레이스, ProfilingManager와 같은 강력한 디버깅 도구를 사용하는 것이 Google Play에서 앱의 성공을 보장하는 데 중요합니다.

작성자:

계속 읽기