Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

앱 대기 버킷

Android 9(API 수준 28)에서는 새로운 배터리 관리 기능인 앱 대기 버킷이 도입되었습니다. 앱 대기 버킷을 사용하면 앱이 얼마나 최근에 얼마나 자주 사용되었는지에 기반해 시스템이 앱의 리소스 요청에 우선순위를 정할 수 있습니다. 앱 사용 패턴에 따라 각 앱은 5개의 우선순위 버킷 중 하나에 배치됩니다. 시스템은 앱이 어떤 버킷에 있는지에 기반해 각 앱에서 사용 가능한 기기 리소스를 제한합니다.

우선순위 버킷

시스템은 각 앱을 우선순위 버킷에 동적으로 할당하여 필요에 따라 앱을 재할당합니다. 시스템은 머신러닝을 사용하여 각 앱이 사용될 가능성을 판단하고 적절한 버킷에 앱을 할당하는 미리 로드된 앱에 의존할 수 있습니다. 시스템 앱이 기기에 없다면 시스템은 기본적으로 앱이 최근에 얼마나 사용되었는지에 따라 앱을 정렬합니다. 더 자주 활성화되는 앱은 더 높은 우선순위를 부여하는 버킷에 할당되어 더 많은 시스템 리소스를 사용할 수 있습니다. 특히 버킷은 앱 작업이 얼마나 자주 실행되는지, 앱이 얼마나 자주 알람을 트리거하는지 그리고 앱이 우선순위가 높은 Firebase 클라우드 메시징 메시지를 얼마나 자주 수신할 수 있는지 판별합니다. 이러한 제한은 기기가 배터리 전원을 사용하는 동안에만 적용됩니다. 시스템은 기기가 충전 중일 때는 앱에 이러한 제한을 적용하지 않습니다.

참고: 모든 제조업체는 비활성 앱을 버킷에 할당하는 방식에 관한 자체 기준을 설정할 수 있습니다. 개발자는 앱이 어떤 버킷에 할당되는지 영향을 주려 해서는 안 됩니다. 대신 앱이 어떤 버킷에 있더라도 잘 동작하도록 하는 데 집중하세요. 앱은 UsageStatsManager.getAppStandbyBucket()을 호출하여 현재 어떤 버킷에 있는지 알아낼 수 있습니다.

버킷은 다음과 같습니다.

  • 활성: 앱이 현재 사용중이거나 매우 최근에 사용되었습니다.
  • 작업 세트: 앱이 정기적으로 사용됩니다.
  • 자주: 앱이 매일은 아니지만 자주 사용됩니다.
  • 드문: 앱이 자주 사용되지 않습니다.

또한 설치는 되었으나 한번도 실행된 적 없는 앱에는 특별히 전혀 버킷이 있습니다. 시스템은 이러한 앱에 엄격한 제한을 가합니다.

참고: 잠자기 허용목록에 있는 앱은 앱 대기 버킷에 기반한 제한에서 제외됩니다.

참고: 다음은 예측할 수 없는 사례를 설명합니다. 반대로 예측이 머신러닝을 사용하여 동작을 예측할 때 최근 사용순에 기반하기보다는 사용자의 다음 작업을 예상하여 버킷이 선택됩니다. 예를 들어 최근에 사용한 앱이 드문 버킷으로 분류될 수 있습니다. 머신러닝에서 몇 시간 동안 앱이 사용되지 않을 것으로 예측하기 때문입니다.

활성

사용자가 현재 앱을 사용 중이거나 앱을 매우 최근에 사용했다면 앱은 활성 버킷에 있습니다. 예를 들면 다음과 같습니다.

  • 앱에서 활동을 실행했습니다.
  • 앱에서 포그라운드 서비스를 실행 중입니다.
  • 앱에 포그라운드 앱에서 사용하는 콘텐츠 제공업체와 연결된 동기화 어댑터가 있습니다.
  • 사용자가 앱에서 보낸 알림을 클릭합니다.

앱이 활성 버킷에 있다면 시스템은 앱의 작업이나 알람, FCM 메시지에 어떤 제한도 가하지 않습니다.

작업 세트

자주 실행되지만 현재 활성 상태가 아닌 경우 앱은 작업 세트 버킷에 있습니다. 예를 들어 사용자가 거의 매일 실행하는 소셜 미디어 앱은 작업 세트에 배치될 가능성이 높습니다. 앱이 간접적으로 사용될 때에도 작업 세트 버킷으로 승격됩니다.

앱이 작업 세트에 있다면 시스템은 앱의 작업 실행 및 알람 트리거 기능에 가벼운 제한을 적용합니다. 자세한 내용은 전력 관리 제한을 참조하세요.

자주

정기적으로 사용되나 매일 사용되지 않는 경우 앱은 자주 버킷에 있습니다. 예를 들어 사용자가 헬스장에서 실행하는 운동 추적 앱은 '자주' 버킷에 있을 수 있습니다.

앱이 '자주' 버킷에 있다면 시스템은 작업을 실행하고 알람을 트리거하는 앱의 기능에 더 강력한 제한을 적용하고 높은 우선순위의 FCM 메시지에 한도를 적용합니다. 자세한 내용은 전력 관리 제한을 참조하세요.

드문

자주 사용되지 않는 경우 앱은 드문 버킷에 있습니다. 예를 들어 사용자가 호텔에 머무는 동안만 실행하는 호텔 앱은 '드문' 버킷에 있을 수 있습니다.

앱이 '드문' 버킷에 있다면 시스템은 앱의 작업 실행 및 알람 트리거 및 높은 우선순위의 FCM 메시지 수신 기능에 엄격한 제한을 적용합니다. 시스템은 앱의 인터넷 연결 기능도 제한합니다. 자세한 내용은 전력 관리 제한을 참조하세요.

권장사항

앱이 잠자기 및 앱 대기에 관한 권장사항을 이미 따르고 있다면 새로운 전력 관리 기능을 다루는 것이 어렵지 않습니다. 그러나 이전에 잘 작동한 일부 앱 동작이 문제를 일으킬 수 있습니다.

  • 앱을 원하는 버킷에 넣으려고 시스템을 조작하면 안 됩니다. 시스템의 버케팅 메서드는 변경될 수 있고 모든 기기 제조업체는 자체 알고리즘으로 자체 버케팅 앱의 작성을 선택할 수 있습니다. 그보다는 어느 버킷에 있든 앱이 적절히 동작하는지 확인하세요.
  • 앱에 런처 활동이 없다면 활성 버킷으로 승격되지 않을 수 있습니다. 이러한 활동을 갖도록 앱을 다시 디자인하는 것이 좋습니다.
  • 앱의 알림을 실행할 수 없다면 사용자는 알림과 상호작용하여 앱의 활성 버킷 승격을 트리거할 수 없습니다. 이 경우 적절한 알림을 다시 디자인하여 사용자의 응답을 허용하는 것이 좋습니다. 가이드라인은 머티리얼 디자인 알림 디자인 패턴을 참조하세요.
  • 마찬가지로 앱이 높은 우선순위의 FCM 메시지를 수신할 때 알림을 표시하지 않으면 사용자가 앱과 상호작용할 수 없으므로 앱이 활성 버킷으로 승격되지 않습니다. 사실 높은 우선순위의 FCM 메시지의 유일한 용도는 알림을 사용자에게 푸시하는 것이므로 이러한 상황이 발생해서는 안 됩니다. 사용자 상호작용을 트리거하지 않을 때 FCM 메시지를 부적절하게 높은 우선순위로 표시하면 다른 부정적인 결과를 초래할 수 있습니다. 예를 들어 앱이 할당량을 모두 사용하여 정말 긴급한 FCM 메시지가 보통 우선순위로 처리될 수 있습니다.

    참고: 사용자가 알림을 반복적으로 닫으면 시스템은 나중에 알림 차단 옵션을 사용자에게 제공합니다. 앱을 활성 버킷에 유지하려고 불필요한 알림을 사용자에게 보내지 마세요.

  • 앱이 여러 패키지로 분할된 경우 이러한 패키지는 다양한 버킷에 있을 수 있으므로 액세스 수준도 다양합니다. 다양한 버킷에 할당된 패키지로 이러한 앱을 테스트하여 앱이 제대로 동작하는지 확인해야 합니다.