절전 모드 해제 잠금 사용 사례 식별 및 최적화

이 문서는 앱에서 wake lock 사용 사례를 식별하고 최적화하는 데 도움이 되며, 이 사용 사례와 관련된 다른 라이브러리나 시스템 API에서 획득한 wake lock이 있는지도 강조 표시합니다. 이러한 wake lock은 앱에 기인하므로 문제가 있는 wake lock의 소스를 정확히 파악하기 어려울 수 있습니다. API를 잘못 사용하면 명시적으로 wake lock을 획득하지 않더라도 앱이 과도한 wake lock 사용으로 신고될 수 있습니다.

이 문서에는 wake lock 디버깅 도구를 사용할 때 또는 비정상 종료 및 ANR 보고서에서 발생할 수 있는 몇 가지 일반적인 wake lock 이름이 나와 있습니다. 이러한 이름은 라이브러리나 시스템 API에서 가져올 수도 있고 난독화될 수도 있습니다. 디버깅 도구를 사용하여 오작동하는 wake lock을 식별한 다음 이 문서에서 wake lock 이름을 검색하면 어떤 API가 문제를 일으키는지 확인하고 사용 최적화 방법에 관한 권장사항을 찾을 수 있습니다.

이 문서에서는 wake lock을 획득하는 일반적인 사용 사례를 설명하고, 다양한 API 및 라이브러리에서 사용하는 wake lock 이름을 자세히 설명하며, wake lock 사용을 최적화하고 줄이기 위한 권장사항과 권장사항을 제공합니다.

AlarmManager

AlarmManager는 wake lock을 획득하고 이를 호출 앱에 할당합니다. AlarmManager는 알람이 울릴 때 wake lock을 획득하고 알람 브로드캐스트의 onReceive() 메서드 실행이 완료되면 잠금을 해제합니다.

wake lock 이름

AlarmManager는 *alarm*라는 이름으로 wake lock을 만듭니다. 별표는 wake lock 이름의 일부이며 와일드 카드를 나타내지 않습니다.

추천

알람 동작을 최적화하려면 다음 권장사항을 따르세요.

  • 알람 유형 선택을 참고하여 부정확한 알람과 정확한 알람 중 하나를 선택하세요. 알람이 정확할 필요가 없다면 부정확한 알람을 사용하여 시스템에 예약 유연성을 더 많이 제공하세요. 그러면 배터리 수명을 개선할 수 있습니다.
  • 시스템에서 적용하는 알람 할당량을 숙지하고 이를 준수하도록 앱을 설계합니다.
  • onReceive() 메서드에서 긴 작업을 실행하지 말고 알람 후 추가 처리가 필요한 경우 작업자를 예약합니다.

오디오 및 미디어

미디어 API는 오디오를 녹음하거나 재생할 때 wake lock을 획득할 수 있습니다. wake lock은 통화 앱에 기여합니다.

wake lock 이름

미디어 API는 Audio로 시작하는 다양한 이름의 wake lock을 획득합니다.

  • AudioBitPerfect: 무손실 USB 오디오 재생에 사용됩니다.
  • AudioDirectOut: TV 또는 특수 기기에서 무손실 오디오를 재생하는 데 사용됩니다.
  • AudioDup: 블루투스 또는 USB를 사용하여 연결된 동안 알림 재생에 사용됩니다.
  • AudioIn: 마이크가 활성 상태인 동안 캠코더 모드에서 오디오 캡처에 사용됩니다.
  • AudioMix: 일반 기기로 오디오를 재생하는 데 사용됩니다.
  • AudioOffload: 이 모드를 지원하는 앱에서 장기 음악 전용 재생에 사용됩니다.
  • AudioSpatial: 서라운드 오디오를 지원하는 기기에서 다중 채널 영화 또는 음악 오디오를 재생하는 데 사용됩니다.
  • AudioUnknown: 다른 상황이 적용되지 않는 경우에 사용됩니다.
  • MmapCapture: 지연 시간이 짧은 오디오 캡처에 사용됩니다.
  • MmapPlayback: 게임 또는 전문 오디오 애플리케이션과 같은 지연 시간이 짧은 재생에 사용됩니다.

추천

다음과 같은 방법을 권장합니다.

  • Audio로 시작하는 wake lock 이름을 선언하지 않습니다.
  • 미디어 API를 사용하는 경우 wake lock을 직접 획득할 필요가 없습니다. API를 사용하여 필요한 wake lock을 획득할 수 있습니다.
  • 미디어 API를 사용하는 경우 더 이상 필요하지 않으면 미디어 세션과 연결된 포그라운드 서비스를 종료합니다.

블루투스

플랫폼 블루투스 API는 블루투스 작업이 발생하는 동안 주로 커널 wake lock을 보유하며, 이는 애플리케이션에 기인하지 않습니다.

추천

  • 컴패니언 기기 페어링을 사용하여 블루투스 기기를 페어링하면 블루투스 페어링 중에 수동 wake lock을 획득하지 않아도 됩니다.
  • 백그라운드에서 통신 가이드를 참고하여 백그라운드 블루투스 통신을 실행하는 방법을 알아보세요.
  • 커뮤니케이션이 지연되어도 사용자에게 영향이 없는 경우 WorkManager를 사용하면 충분합니다. 수동 wake lock이 필요하다고 판단되면 블루투스 활동 또는 활동 데이터 처리 기간에만 wake lock을 유지합니다.

기기 센서

걸음 수, 가속도계, 자이로스코프 데이터와 같은 기기 센서 데이터를 추적하는 방법에는 여러 가지가 있습니다.

Wear OS에서는 Wear 건강 관리 서비스를 사용하여 고도, 심박수, 이동 거리와 같은 기기 데이터를 가져옵니다.

다른 애플리케이션에서 데이터를 수집하는 경우 WorkManager와 결합된 헬스 커넥트를 사용하여 주기적으로 데이터를 가져올 수 있습니다.

걸음 수 또는 이동 거리의 변화를 추적하는 등의 시나리오에서는 모바일의 Recording API를 WorkManager와 함께 사용하여 주기적으로 데이터를 가져올 수 있습니다. 과거 걸음 수 데이터(예: 일일 총 걸음 수 또는 지난 6시간 동안의 걸음 수)에 액세스하기 위해 헬스 커넥트는 Android 14 이상을 실행하는 기기의 온디바이스 걸음 수 추적도 지원합니다.

경우에 따라 SensorManager를 사용하여 맞춤 기기 센서 추적이 필요할 수 있습니다. SensorManager는 센서가 isWakeUpSensor API를 사용하여 식별할 수 있는 절전 모드 해제 센서가 아닌 한 앱을 대신하여 wake lock을 획득하지 않습니다.

추천

센서를 사용하여 높은 샘플링 레이트로 기록하면 배터리가 크게 소모될 수 있습니다. 다음은 배터리 소모 및 wake lock 사용을 줄이기 위한 권장사항입니다.

  • 걸음 수 또는 이동 거리를 추적하는 경우 Recording API를 사용하여 배터리를 효율적으로 사용하는 방식으로 데이터를 기록합니다. Android 14 이상을 실행하는 기기의 경우 이전 기기 및 집계된 걸음 수에 액세스하려면 헬스 커넥트를 고려하세요.
  • Wear OS에서 수동 센서 추적을 하려면 Wear 건강 관리 서비스를 사용하여 배터리 사용량을 최적화하세요.
  • SensorManager로 센서를 등록할 때 30초를 초과하는 maxReportLatencyUs를 정의하여 센서 일괄 처리 로직을 사용하고 애플리케이션이 수신하는 인터럽트 수를 줄입니다. 이후 사용자 상호작용, 위치 검색 또는 예약된 작업과 같은 다른 트리거에 의해 기기가 절전 모드에서 해제되면 시스템은 캐시된 센서 데이터를 즉시 전달합니다.
  • 앱에 위치 데이터와 센서 데이터가 모두 필요한 경우 이벤트 검색 및 처리를 동기화합니다. 시스템이 위치 업데이트를 위해 보유하는 짧은 wake lock에 센서 판독값을 통합하면 CPU를 절전 모드 해제 상태로 유지하기 위해 wake lock이 필요하지 않습니다. 작업자 또는 단기 wake lock을 사용하여 이 결합된 데이터의 업로드 및 처리를 처리합니다.

Firebase 클라우드 메시징 (FCM)

Firebase 클라우드 메시지 (FCM) 브로드캐스트를 앱에 전송하는 동안 wake lock이 획득됩니다. FCM 브로드캐스트 onMessageReceived() 메서드가 실행을 완료하면 wake lock이 해제됩니다.

wake lock 이름

기기에서 FCM 메시지를 수신하면 GOOGLE_C2DM이라는 이름으로 짧은 wake lock이 유지됩니다. Android 16 이상에서는 wake lock 이름이 GCM_MESSAGE입니다.

추천

FCM 동작을 최적화하려면 다음 권장사항을 따르세요.

  • FCM 전송 빈도를 최적화합니다.
  • 메시지를 실제로 즉시 전송해야 하는 경우가 아니면 우선순위가 높은 FCM을 사용하지 마세요.
  • onMessageReceived() 메서드를 최대한 빨리 완료하거나 추가 처리가 필요한 경우 작업을 계속하도록 작업자를 예약합니다. 자세한 내용은 Firebase 가이드를 참고하세요.

JobScheduler

JobScheduler 작업은 백그라운드에서 작업을 실행하는 동안 wake lock을 획득합니다. wake lock은 작업자를 만든 앱에 기여한 것으로 간주됩니다.

wake lock 이름

JobScheduler에서 획득한 wake lock 이름은 실행 중인 Android 시스템 버전과 작업 목적에 따라 다릅니다.

꺾쇠괄호로 묶인 항목은 변수입니다. 예를 들어 '<package_name>'은 앱 패키지의 이름이며 리터럴 텍스트 <package name>가 아닙니다. 하지만 *job*는 별표가 있는 문자 시퀀스 *job*입니다. 별표는 와일드 카드로 사용되지 않습니다.

Android 15 이하

사용자가 시작한 작업은 다음 패턴을 따르는 이름으로 wake lock을 만듭니다.

*job*u/@<name_space>@/<package_name>/<classname>

다른 작업은 다음 패턴을 사용합니다.

*job*/@<name_space>@/<package_name>/<classname>
Android 16 QPR2 이상

사용자가 시작한 작업은 다음 패턴을 따르는 이름으로 wake lock을 만듭니다.

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

신속 처리 작업은 다음 패턴을 사용합니다.

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

일반 작업은 다음 패턴을 사용합니다.

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
예

네임스페이스가 backup이고 트레이스 태그가 started인 신속 처리 작업이 있다고 가정해 보겠습니다. 패키지 이름은 com.example.app이고 작업을 만든 클래스는 com.backup.BackupFileService입니다.

Android 15 이하를 실행하는 기기에서는 wake lock의 이름이 다음과 같이 지정됩니다.

*job*/@backup@/com.example.app/com.backup.BackupFileService

Android 16 QPR2 이상을 실행하는 기기에서 wake lock의 이름은 다음과 같습니다.

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

추천

  • 사용자가 시작한 다운로드/ 업로드 사용 사례에 수동 wake lock을 획득하지 않습니다. 대신 사용자 시작 데이터 전송 (UIDT) API를 사용하세요. 이는 사용자가 시작한 장기 실행 데이터 전송 작업을 위해 지정된 경로입니다.
  • JobScheduler에서 만든 wake lock의 wake lock 사용량이 많은 경우 특정 시나리오에서 완료되지 않도록 작업을 잘못 구성했기 때문일 수 있습니다. 특히 STOP_REASON_TIMEOUT가 많이 발생하는 경우 작업 중지 이유를 분석하는 것이 좋습니다.
  • JobScheduler 작업 사용을 감사합니다. 특히 작업 예약 API의 배터리 사용 최적화 가이드를 따르세요.

위치

LocationManager 및 FusedLocationProviderClient는 wake lock을 사용하여 기기 위치를 가져오고 전달합니다. wake lock은 이러한 API를 호출한 앱에 기여한 것으로 간주됩니다.

wake lock 이름

위치 서비스는 다음 이름을 사용합니다.

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

추천

  • 위치 사용 최적화 가이드를 참고하세요. 제한 시간 구현, 위치 요청 일괄 처리 활용, 수동적 위치 업데이트 활용을 고려하세요.
  • 위치 데이터를 캐시하기 위해 별도의 연속 wake lock을 획득하지 마세요. 이는 중복되므로 삭제해야 합니다. FusedLocationProvider 또는 LocationManager API를 사용하여 위치 업데이트를 요청하면 시스템은 위치 이벤트 콜백 중에 기기 절전 모드 해제를 자동으로 트리거합니다. 대신 위치 이벤트를 메모리나 저장소에 저장하고 WorkManager를 사용하여 위치 이벤트를 주기적으로 처리합니다.

원격 메시지

이 섹션에서는 앱이 연결을 유지하거나 다른 기기의 이벤트에 반응해야 할 수 있는 원격 메시징과 관련된 시나리오를 설명하며, 이는 wake lock 사용에 영향을 미칠 수 있습니다. 일반적인 사용 사례는 다음과 같습니다.

  • 로컬 네트워크를 통해 연결된 외부 기기에서 발생하는 이벤트를 모니터링해야 하는 동영상 또는 사운드 모니터링 호환 앱
  • 데스크톱 변형과 네트워크 소켓 연결을 유지하는 메시지 앱

이러한 원격 메시지 시나리오에서 대부분의 절전 모드 해제는 커널 wake lock입니다. 커널 wake lock은 앱에 기여하지 않으므로 여기에 나열할 연결된 wake lock 이름이 없습니다.

추천

  • 네트워크 이벤트를 서버 측에서 처리할 수 있는 경우 FCM을 사용하여 클라이언트에서 정보를 수신합니다. FCM 데이터의 추가 처리가 필요한 경우 신속 작업자를 예약할 수 있습니다.
  • 소켓 연결을 사용하여 클라이언트 측에서 이벤트를 처리해야 하는 경우 이벤트 인터럽트를 수신 대기하는 데 wake lock이 필요하지 않습니다. 데이터 패킷이 Wi-Fi 또는 무선 라디오에 도착하면 무선 하드웨어가 커널 wake lock 형식으로 인터럽트를 트리거합니다. 그런 다음 작업자를 예약하거나 wake lock을 획득하여 데이터를 처리할 수 있습니다.
  • 예를 들어 ktor-network를 사용하여 네트워크 소켓에서 데이터 패킷을 수신 대기하는 경우 패킷이 클라이언트에 전송된 경우에만 wake lock을 획득해야 합니다.

WorkManager

WorkManager 작업자는 백그라운드에서 작업을 실행하는 동안 wake lock을 획득합니다. wake lock은 작업자를 만든 앱에 기여한 것으로 간주됩니다.

wake lock 이름

WorkManager에서 획득한 wake lock 이름은 실행 중인 Android 시스템 버전에 따라 다릅니다.

Android 15 이하

WorkManager 작업은 다음 패턴을 따르는 이름으로 wake lock을 만듭니다.

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 QPR2 이상

신속 처리 작업은 다음 패턴을 따르는 이름으로 wake lock을 만듭니다.

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

일반 작업은 다음 패턴을 따릅니다.

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

기본적으로 <trace_tag>는 작업자 이름입니다.

예

BackupFileWorker라는 빠른 작업자가 있다고 가정해 보겠습니다. 패키지 이름은 com.example.app입니다.

Android 15 이하를 실행하는 기기에서는 wake lock의 이름이 다음과 같이 지정됩니다.

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Android 16 QPR2 이상을 실행하고 WorkManager 2.10.0+를 사용하는 기기에서 wake lock의 이름은 다음과 같습니다.

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

추천

  • Android 16 QPR2 이상에서 wake lock 태그를 더 상세하게 표시하려면 WorkManager 버전을 최신 안정화 버전으로 업그레이드하세요.
  • WorkManager worker 사용을 감사합니다. 특히 작업 예약 API의 배터리 사용 최적화에 관한 가이드를 따르는지 확인합니다. Android 16 QPR2 이상에서 wake lock 태그를 더 상세하게 만들려면 작업자의 setTraceTag 메서드를 사용하여 작업자를 예약한 클래스와 같은 디버그 정보를 더 추가합니다.
  • WorkManager에서 만든 wake lock의 wake lock 사용량이 높은 경우 특정 시나리오에서 완료되지 않도록 작업자를 잘못 구성했기 때문일 수 있습니다. 특히 STOP_REASON_TIMEOUT가 많이 발생하는 경우 작업자 중지 이유를 분석하는 것이 좋습니다.
  • 작업자 중지 이유를 로깅하는 것 외에도 작업자 디버깅에 관한 문서를 참고하세요. 또한 시스템 트레이스를 수집하고 분석하여 wake lock이 획득되고 해제되는 시점을 파악하는 것이 좋습니다.

_UNKNOWN

디버깅 도구에서 wake lock 이름에 개인 식별 정보 (PII)가 포함되어 있다고 판단하면 실제 wake lock 이름을 표시하지 않습니다. 대신 wake lock에 _UNKNOWN 라벨을 지정합니다. 예를 들어 wake lock 이름에 이메일 주소가 포함된 경우 도구에서 이 작업을 실행할 수 있습니다.

추천

wake lock 이름 지정 권장사항을 따르고 wake lock 이름에 개인 식별 정보를 사용하지 않습니다. 앱에 기인한 _UNKNOWN라는 이름의 wake lock을 찾으면 어떤 wake lock인지 확인하고 다른 이름을 지정합니다.