웨어러블용 Android 앱을 빌드한다는 것은 화면이 꺼질 때 실제 작업이 시작된다는 의미입니다. WHOOP는 회원이 운동, 회복, 수면, 스트레스에 신체가 어떻게 반응하는지 이해하는 데 도움이 되며, Android를 사용하는 많은 WHOOP 회원에게 안정적인 백그라운드 동기화 및 연결은 이러한 통계를 가능하게 합니다.

올해 초 Google Play는 Android vitals에 새로운 측정항목인 과도한 부분 wake lock을 출시했습니다. 이 측정항목은 24시간 동안 누적된 면제되지 않은 wake lock 사용 시간이 2시간을 초과하는 사용자 세션의 비율을 측정합니다. 이 측정항목의 목표는 우수한 사용자 경험을 제공하는 데 중요한 배터리 소모의 가능한 원인을 파악하고 해결하는 데 도움을 주는 것입니다.

2026년 3월 1일부터 품질 기준을 계속 충족하지 않는 앱은 Google Play 검색 노출 영역에서 제외될 수 있습니다. 또한 Google Play 스토어 등록정보에 앱이 예상보다 많은 배터리를 사용할 수 있음을 나타내는 경고가 표시될 수도 있습니다.

WHOOP의 선임 Android 엔지니어인 Mayank Saini에 따르면 Android vitals에서 앱의 과도한 부분 wake lock 비율을 권장 기준인 5%를 초과하는 15%로 표시한 후 이 '팀에 Android 효율성을 높일 기회를 제공'했습니다.

팀은 Android vitals 측정항목을 백그라운드 작업이 CPU를 필요 이상으로 오랫동안 절전 모드 해제 상태로 유지하고 있다는 명확한 신호로 간주했습니다. 이 문제를 해결하면 낭비되는 백그라운드 시간을 줄이고 안정적이고 시기적절한 블루투스 연결 및 동기화를 유지하면서 우수한 사용자 경험을 계속 제공할 수 있습니다.

문제 파악

시작할 위치를 파악하기 위해 팀은 먼저 Android vitals를 통해 측정항목에 영향을 미치는 wake lock에 관한 자세한 통계를 확인했습니다. Android vitals 과도한 부분 wake lock 대시보드를 참조하여 과도한 부분 wake lock에 가장 큰 영향을 미치는 요소가 WorkManager worker 중 하나 (대시보드에서 androidx.work.impl.background.systemjob.SystemJobService로 식별됨)임을 파악할 수 있었습니다. WHOOP '상시 사용 환경'을 지원하기 위해 앱은 WorkManager를 사용하여 주기적인 동기화 및 웨어러블에 반복 업데이트 제공과 같은 백그라운드 작업을 실행합니다. 

팀은 백그라운드에서 작업을 실행하는 동안 WorkManager가 wake lock을 획득한다는 것을 알고 있었지만 Android vitals에 과도한 부분 wake lock 측정항목이 도입되기 전에는 WorkManager뿐만 아니라 모든 백그라운드 작업이 어떻게 배포되는지 알 수 없었습니다.

대시보드에서 WorkManager를 주요 기여자로 식별한 후 팀은 가장 많은 기여를 하는 worker를 파악하고 문제를 해결하는 데 집중할 수 있었습니다.

내부 측정항목 및 데이터를 활용하여 원인을 더 좁히기

WHOOP는 이미 WorkManager 측정항목을 모니터링하기 위한 내부 인프라를 설정했습니다. 다음 항목을 주기적으로 모니터링합니다.

1. 평균 런타임: worker가 실행되는 시간
2. 시간 제한: worker가 완료되는 대신 시간 제한되는 빈도
3. 재시도: 작업이 시간 제한되거나 실패한 경우 worker가 재시도하는 빈도
4. 취소: 작업이 취소된 빈도

worker의 성공 및 실패뿐만 아니라 더 많은 항목을 추적하면 팀에서 작업의 효율성을 파악할 수 있습니다.

내부 측정항목은 일부 worker의 평균 런타임이 높음 을 표시하여 조사를 더 좁힐 수 있었습니다. 

내부 측정항목 외에도 팀은 Android 스튜디오의 Background Task Inspector 를 사용하여 관련 wake lock에 특히 중점을 두고 관심 있는 worker를 검사하고 디버깅하여 Android vitals에 표시된 측정항목과 일치시켰습니다.

조사: worker 옵션 구분

WHOOP는 일부 worker에 일회성 및 주기적 일정을 모두 사용합니다. 이렇게 하면 앱에서 동일한 성공 기준을 가진 동일한 작업에 동일한 Worker 로직을 재사용할 수 있으며 타이밍만 다릅니다.

내부 측정항목을 사용하면 검색 범위를 특정 worker로 좁힐 수 있지만 worker가 일회성인지, 주기적인지, 아니면 둘 다인지 알 수 없었습니다. 따라서 WorkManager의 setTraceTag 메서드 를 사용하여 동일한 Worker의 일회성 및 주기적 옵션을 구분하는 업데이트를 출시했습니다.

이 추가 세부정보를 사용하면 과도한 부분 wake lock이 있는 세션에 가장 큰 영향을 미치는 Worker 옵션 (주기적 또는 일회성)을 명확하게 식별할 수 있습니다. 그러나 데이터에서 두 옵션 모두 다른 옵션보다 더 많은 영향을 미치지 않는 것으로 나타나 팀은 놀랐습니다.

WHOOP의 Android 엔지니어 II인 Manmeet Tuteja는 '이 분할을 통해 문제가 두 옵션 모두에서 발생하고 있음을 확인할 수 있었으며, 이는 일정 구성이 아니라 worker 구현 내의 공유 비즈니스 로직 문제를 가리키는 것이었습니다'라고 말했습니다.

worker 동작 자세히 알아보고 근본 원인 해결

worker 내부의 로직을 살펴봐야 한다는 것을 알고 있는 팀은 조사 중에 표시된 worker의 worker 동작을 다시 검토했습니다. 특히 작업이 멈추고 완료되지 않는 인스턴스를 찾고 있었습니다.

이 모든 것이 과도한 wake lock의 근본 원인을 찾는 데 도움이 되었습니다.

진행하기 전에 WHOOP 센서에 연결될 때까지 기다리도록 설계된 CoroutineWorker 

센서가 연결되지 않은 상태에서 작업이 시작되면 센서가 연결되어 있는지 나타내는 whoopSensorFlow가 null이었습니다. SensorWorker는 이를 조기 종료 조건으로 처리하지 않고 계속 실행되어 연결을 무기한 기다렸습니다. 결과적으로 WorkManager는 작업이 시간 제한될 때까지 부분 wake lock을 유지하여 백그라운드 wake lock 사용량이 많아지고 SensorWorker가 원치 않게 자주 다시 예약되었습니다.

이 문제를 해결하기 위해 WHOOP팀은 핵심 비즈니스 로직을 실행하기 전에 연결 상태를 확인하도록 worker 로직을 업데이트했습니다.

센서를 사용할 수 없는 경우 worker가 종료되어 시간 제한 시나리오를 방지하고 wake lock을 해제합니다. 다음 코드 스니펫은 솔루션을 보여줍니다.

  class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

과도한 부분 wake lock이 있는 세션 90% 감소

수정사항을 출시한 후 팀은 Android vitals 대시보드를 계속 모니터링하여 변경사항의 영향을 확인했습니다. 

결과적으로 WHOOP는 Worker에 변경사항을 구현한 후 30일 만에 과도한 부분 wake lock 비율이 15% 에서 1%미만으로 감소 했습니다. 

변경사항으로 인해 작업이 완료되지 않고 시간 제한되는 인스턴스가 줄어들어 평균 런타임이 단축되었습니다. 

백그라운드 작업의 효율성을 개선하려는 다른 개발자를 위한 WHOOP팀의 조언은 다음과 같습니다.

시작하기

앱의 과도한 부분 wake lock을 줄이거나 worker 효율성을 개선하려는 경우 Android vitals에서 앱의 과도한 부분 wake lock 측정항목을 확인하고 wake lock 문서에서 권장사항 및 디버깅 전략을 자세히 알아보세요.