Exploring Android P : Priority Buckets
이번 구글 IO에서는 안드로이드 최신 버전인 P에 대한 새로운 내용이 많이 발표되었습니다.
Priority Buckets은 발표된 내용 중 하나로, 앱들에게 우선순위를 부여하여 배터리를 관리하는 업데이트 입니다. 앱이 얼마나 최근에 실행되었는지, 얼마나 자주 실행되는지의 기준으로 각 앱에 우선순위를 부여하는 것입니다. 이 아티클에서는 이 버킷이 무엇이고, 이에따라 앱의 동작에 어떤 영향이 있는지를 간략하게 살펴볼 예정입니다.
이 Priority Buckets는 앱들간에 더 스마트하게 주어진 자원을 분배하도록 고안되었습니다. 만약, 우리가 어떤 주기적으로 사용하는 앱을 사용하려는 중에, 자주 사용하지도 않는 앱이 백그라운드 동작을 시도하려고 하면, 우리는 현재 작업을 하는 동안, 그 백그라운드 작업을 꺼버리고 싶지 않을까요? 다른 예시로는, 우리가 자주쓰는 앱이 메세지를 받는 그때에, 자주 쓰이지도 않는 앱의 High Priority 메세지를 받는다면, 자주 쓰이지 않는 앱의 메세지를 차단시키는 것은 매우 좋은 방법일 수 있습니다. 이러한 목적들을 위해, 앱을 특정 버킷에 넣어 그룹화하는 Priority Buckets 개념이 고안되었습니다. 다음의 5가지 버킷이 존재하며, 해당 버킷에는 다른 동작규칙이 있습니다. 모든 앱들은 반드시 5가지의 버킷 중 하나에 속하게 됩니다.
- Active : 현재 유저가 사용중인 앱이 속한 버킷입니다. 이는 앱이 포그라운드이거나, 시스템 레벨 프로세스가 실행중이거나, 혹은 어떤 방식으로든 그 프로세스와 상호작용중인 것입니다. 만약, 앱에 런처 엑티비티가 없으면, 이 앱은 절대 이 버킷에 속할 수 없습니다.
- Working Set : 앱이 지금은 사용중이지 않지만, 거의 매일 사용되다시피 자주 실행되는 앱이 속한 버킷입니다.
- Frequent : 앱이 지금은 사용중이지 않지만, 일주일중에 가끔 실행되는 앱이이 속한 버킷입니다. 예를들어, 어떤 앱을 일주일에 3번정도 사용한다면, 그 앱은 이 버킷에 속하게 됩니다.
- Rare : 디바이스에서 앱이 거의 사용되지 않을 때 이 버킷에 속하게 됩니다.
- Never : 앱이 설치는 되었으나, 한번도 실행된 적이 없을 때 속하는 버킷입니다.
앱이 특정 버킷에 속하게 되면, 영원히 해당 버킷에 머무르게 되는 것은 아닙니다. 이 버킷들은 시스템이 앱의 활동에 따라 동적으로 채워질 것입니다. 즉, 한번도 사용된 적 없었던 앱이 꾸준히 사용빈도가 늘어난다면, 버킷이 변경될 것입니다. 디바이스가 머신러닝을 사용할 수 있다면, 머신러닝을 활용하여 앱의 사용빈도를 결정하고, 이 예측에 따라 버킷을 결정할 것입니다. 만약 머신러닝을 사용할 수 없는 디바이스라면, 얼마나 최근에 실행되어 있는지를 기준으로 앱을 정렬하여 버킷을 구성할 것입니다. 사용성에 따라서, 이 지표를 카운트하는 다음의 몇몇 방법들이 있습니다.
- 사용자의 앱 실행
- 사용자의 Notification 반응성 - Notification이 보여졌지만, 사용자에 의해 바로 닫힌다면 그 앱의 버킷에 영향을 미치지 않습니다.
그렇다면, 앱이 각 버킷에 속하게 되는 것이, 동작에 어떤 영향을 미치는 걸까요? 다음의 표를 통해, 시스템이 각 버킷에 제한하는 사항들을 확인할 수 있습니다.
이 제약사항들은 디바이스가 배터리 전원을 사용할 때에만 적용되기는 하지만, 이러한 상황들을 인지하고, 앱이 원하는 시나리오대로 동작하도록 최적화해야 합니다. 자세히 살펴보면, 먼저 Active 버킷에서는 제한사항이 없으므로, 크게 신경쓸 부분이 없습니다. Working Set 버킷에서는 약간의 제약사항이 추가됩니다. 이 경우에 모든 실행중인 모든 Job은 최대 2시간까지 지연될 수 있고, 모든 알람 또한 최대 6분까지 지연될 수 있습니다. Frequent 버킷에 속한 앱은 모든 Job이 최대 8시간까지 지연될 수 있고, 알람도 최대 30분까지 지연될 수 있습니다. 그리고, High priority FCM을 하루에 10개만 받을 수 있도록 제한이 추가됩니다. Rare 버킷에 속한 앱은 모든 Job 최대 24시간이 지연될 수 있고, 알람 또한 최대 2시간이나 지연될 수 있습니다. High priority FCM도 하루에 5개로 제한되며, 네트워크 제한이 추가되어 최대 24시간이나 지연될 수 있습니다.
Note : 만약 앱이 다른 패키지로 분리되어 있다면, 각각 다른 버킷에 속할 수 있습니다. 해당 패키지들 간에 같은 행동이 될 것이리고 장담하지 마세요. 다른 결과가 발생할 수 있습니다.
앱이 속한 현재 버킷을 알고 싶다면,
UsageStatsManager클래스의 getAppStandbyBucket() 메서드를 이용하세요. 앱은 각 상황에 맞게 동작하도록 구현되어야 하지만, 이 매서드는 타이밍이 중요한 상황일 때 유용할 수 있습니다. 이를 염두에 두고, 앱을 다른 버킷으로 이동시키려는 시도는 하지않아야 합니다. 디바이스 제조사별로 Priority Buckets의 배정 기준이 달라질 수 있기 때문에, 특정한 결정기준으로 앱이 버킷에 속할것이라는 장담은 할 수 없습니다. 그리고, 버킷을 이동시키기 위해 사용자의 액션을 얻으려는 메세지를 강요해서도 안됩니다. 예를 들어, 의미없는 우선순위가 높은 노티피케이션을 이용하여 사용자의 액션을 얻으려 하는 생각은 좋지 않습니다. 단, 해당 노티피케이션이 사용자에게 가치를 제공한다면 그것은 얼마든지 좋은 사례입니다. 버킷레벨을 변경하기 위해 시스템을 어뷰징하지 마세요.원문
https://medium.com/google-developer-experts/exploring-android-p-priority-buckets-d34d12059d36
