부분적인 장기간 wake lock

부분적인 wake lock은 시스템 시간 초과가 발생하거나 사용자가 전원 버튼을 눌러 기기의 화면이 꺼진 후에 개발자가 CPU를 계속 실행할 수 있게 하는 PowerManager API의 메커니즘입니다. 앱이 acquire()PARTIAL_WAKE_LOCK 플래그와 함께 호출하여 부분적인 wake lock을 획득합니다. 앱이 백그라운드에서 실행되는 동안(앱의 일부가 사용자에게 표시되지 않음) 부분적인 wake lock이 오랫동안 유지되면 장기간 wake lock이 됩니다. 이 상태는 기기가 저전력 상태로 전환되지 않도록 하기 때문에 기기의 배터리를 소모합니다. 부분적인 wake lock은 필요할 때만 사용하고 더 이상 필요하지 않을 때 즉시 해제해야 합니다.

앱에 부분적인 장기간 wake lock이 있는 경우 이 페이지의 안내에 따라 문제를 진단하고 해결할 수 있습니다.

문제 감지

앱의 부분적인 wake lock이 장기간 wake lock이 되는 것을 항상 알 수 있는 것은 아닙니다. 앱을 이미 게시했다면 Android vitals를 사용하여 문제를 인식할 수 있습니다.

Android vitals

Android vitals를 사용하면 앱이 부분적인 장기간 wake lock을 나타낼 때 Play Console을 통해 알림을 보냄으로써 앱의 성능을 개선할 수 있습니다. Android vitals는 백그라운드에서 배터리 세션에 1시간 길이의 부분적인 wake lock이 1회 이상 발생하는 경우 부분적인 wake lock을 장기간 wake lock으로 보고합니다.

배터리 세션의 정의는 플랫폼 버전에 따라 다릅니다.

  • Android 10에서 배터리 세션은 24시간 기간 동안 수신된 모든 배터리 보고의 집계입니다. Android 10에서 배터리 보고는 두 번의 배터리 충전(20% 이하에서 80% 이상으로의 충전 또는 배터리 잔량에 관계없이 100%로의 충전) 사이의 간격을 의미합니다.
  • Android 11에서 배터리 세션은 고정된 24시간 기간입니다.

표시된 배터리 세션 수는 측정된 모든 앱 사용자의 집계입니다. Google Play에서 Android vitals 데이터를 수집하는 방법에 관한 자세한 내용은 Play Console 문서를 참고하세요.

앱에 불필요한 부분적인 장기간 wake lock이 있다는 것을 알았다면 다음 단계는 문제를 해결하는 것입니다.

문제 해결

wake lock은 초기 버전의 Android 플랫폼에서 도입되었지만 시간이 경과함에 따라 이전에 wake lock이 필요했던 많은 사용 사례를 이제 WorkManager와 같은 최신 API를 통해 보다 효율적으로 지원할 수 있습니다.

이 섹션에 wake lock을 해결하기 위한 도움말이 포함되어 있지만 장기적으로는 권장사항 섹션에 있는 권장사항을 따르도록 앱을 이전하는 것을 고려하세요.

newWakeLock(int, String) 또는 WakefulBroadcastReceiver 서브클래스 호출과 같은 wake lock을 획득하는 코드의 위치를 확인하고 수정하세요. 다음은 몇 가지 팁입니다.

  • wake lock이 만들어진 소스의 위치를 쉽게 식별할 수 있도록 패키지, 클래스 또는 메서드 이름을 wake lock 태그 이름에 포함하는 것이 좋습니다. 다음은 몇 가지 추가적인 도움말입니다.
    • 이름에서 이메일 주소와 같은 개인 식별 정보(PII)를 제외하세요. 그러지 않으면 기기가 wake lock 이름 대신 _UNKNOWN을 로깅합니다.
    • Proguard로 난독화되었을 수 있으므로 프로그래매틱 방식(예: getName() 호출)으로 클래스 또는 메서드 이름을 가져오면 안 됩니다. 대신 하드 코딩된 문자열을 사용하세요.
    • wake lock 태그에 카운터 또는 고유 식별자를 추가하지 마세요. wake lock 모두에는 고유 식별자가 있으므로 시스템에서 동일한 메서드로 만들어진 wake lock을 집계할 수 없습니다.
  • 코드가 획득한 모든 wake lock을 해제하는지 확인하세요. 이는 모든 acquire() 호출에 대응하는 release() 호출이 있는지 확인하는 것보다 더 복잡합니다. 다음은 확인할 수 없는 예외로 인해 해제되지 않은 wake lock의 예입니다.

    Kotlin

    @Throws(MyException::class)
    fun doSomethingAndRelease() {
        wakeLock.apply {
            acquire()
            doSomethingThatThrows()
            release()  // does not run if an exception is thrown
        }
    }

    Java

        void doSomethingAndRelease() throws MyException {
            wakeLock.acquire();
            doSomethingThatThrows();
            wakeLock.release();  // does not run if an exception is thrown
        }

    다음은 올바른 버전의 코드입니다.

    Kotlin

    @Throws(MyException::class)
    fun doSomethingAndRelease() {
        wakeLock.apply {
            try {
                acquire()
                doSomethingThatThrows()
            } finally {
                release()
            }
        }
    }

    Java

        void doSomethingAndRelease() throws MyException {
            try {
                wakeLock.acquire();
                doSomethingThatThrows();
            } finally {
                wakeLock.release();
            }
        }
  • wake lock이 더 이상 필요하지 않으면 해제되어야 합니다. 예를 들어 wake lock을 사용하여 백그라운드 작업이 완료되도록 하는 경우 해당하는 작업이 완료될 때 해제가 발생하는지 확인하세요. wake lock이 해제되지 않고 예상보다 더 오래 유지되면 백그라운드 작업에 예상보다 많은 시간이 걸릴 수 있습니다.

코드의 문제를 해결한 후 다음 Android 도구를 사용하여 앱이 wake lock을 올바르게 해제하는지 확인하세요.

  • dumpsys - 기기의 시스템 서비스 상태 정보를 제공하는 도구입니다. wake lock 목록이 포함된 전원 서비스의 상태를 보려면 adb shell dumpsys power를 실행하세요.

  • Battery Historian - Android 버그 신고의 출력을 전원 관련 이벤트의 시각적 표현으로 파싱하는 도구입니다.

권장사항

일반적으로 앱은 사용자의 배터리를 너무 쉽게 소모하는 부분적인 wake lock을 피해야 합니다. Android는 이전에 부분적인 wake lock이 필요했던 거의 모든 사용 사례의 대체 API를 제공합니다. 부분적인 wake lock의 한 가지 남은 사용 사례는 화면이 꺼져 있을 때 음악 앱이 계속 재생되도록 하는 것입니다. wake lock을 사용하여 작업을 실행한다면 백그라운드 처리 가이드에 설명된 대안을 고려하세요.

부분적인 wake lock을 사용해야 한다면 다음 권장사항을 따르세요.

  • 앱의 일부가 포그라운드에 남아 있는지 확인하세요. 예를 들어 서비스를 실행해야 하는 경우 대신 포그라운드 서비스를 시작하세요. 포그라운드 서비스는 앱이 아직 실행 중이라고 사용자에게 시각적으로 표시합니다.
  • wake lock을 획득하고 해제하는 로직은 가능한 한 단순해야 합니다. wake lock 로직이 복잡한 상태 시스템, 시간 제한, 실행기 풀 또는 콜백 이벤트에 연결되면 해당하는 로직의 미세한 버그로 인해 wake lock이 예상보다 더 오래 유지될 수 있습니다. 이러한 버그는 진단 및 디버그가 어렵습니다.