前言
本文翻譯了Android開發者文檔中的一篇官方文檔，用於介紹Android9的一個新特性——應用待機群組（App Standby Buckets）。
中國版官網原文地址為：https://developer.android.google.cn/topic/performance/appstandby。
路徑為：Android Developers > Docs > 指南 > Best practies > App Standby Buckets
正文
Android 9（API level 28）引入了一個新的電池管理特征，應用待機群組。應用待機群組幫助系統根據應用的最近使用時間和使用頻率給應用對資源的請求排出優先次序。基於應用的使用模式，每一個應用被放置到5個群組中的一個。系統根據應用所在的群組，會限制每一個應用對設備資源的使用。
群組優先級
系統將每一個應用動態分配到某一優先級的群組中，並根據需要重新分配應用。系統可能依賴一個預加載的應用，該應用使用機器學習來決定每一個應用被使用的可能性，並且將應用分配到適當的群組中。如果系統應用沒有展示在設備上，系統會默認根據他們最近被使用時間進行排序。更多活躍的應用被分配到給予應用更高優先級的群組中，從而讓這些應用能夠使用更多的系統資源。特別地，群組決定了應用工作運行的頻率，應用可能觸發警報的頻率，以及應用可能收到高優先級【FCM】消息的頻率。僅僅只有當設備正在使用電池電源的時候這些限制才適用；當設備正在充電的時候，系統不會把這些限制條件強加到應用上。
★ 注意：每一個廠商都可以為非活躍應用如何分配群組設置他們自己的標准。你不應該去嘗試影響你的應用被分配到哪一個群組。相反，你應該聚焦於確保你的應用無論可能在哪個群組都表現良好。你的應用可以通過調用一個新的方法【UsageStatsManager.getAppStandbyBucket】找到它當前在哪一個群組中。
這些群組是：
- 活躍：應用當前正在被使用或者最近剛剛被使用過
- 工作集：應用經常被使用
- 頻繁：應用經常被使用，但不是每天
- 罕見：應用不是頻繁使用
另外，還有一個特殊的“從不”群組，為那些安裝后從來沒有使用過的應用而設計。系統給這些應用強加了幾個限制。
★ 注意：那些在Doze白名單中的應用在基於限制的應用待機群組中是豁免的。
★ 注意：下面的描述適用於非預測性的場景。相反，當預測使用機器學習來預測行為時，群組被選擇是為了用戶接下來的行為，而不是基於最近的使用。例如，一個最近被使用的應用可能以分配到“罕見”群組而告終，因為機器學習預測該應用可能在接下來的幾個小時內都將不會被使用。
活躍
如果用戶正在使用一款app或者非常頻繁使用一款應用，那么這款應用就在“活躍”群組中。例如：
- 該應用啟動了一個activity
- 該應用正在運行一個前台service
- 該應用擁有一個與被前台應用使用的內容提供者相關聯的同步適配器
- 用戶點擊了來自該應用的通知。
如果一款應用在“活躍”群組中，系統將不會放置任何限制在應用的工作、警報或FCM信息上。
工作集
如果應用經常運行但當前不是活躍的，那么這款應用處於“工作集”群組。例如，一款用戶大部分時間都啟動着的社交媒體應用很有可能在“工作集”群組中。如果應用被間接使用，那么也會被提升到“工作集”群組中。
如果應用在“工作集”群組中，系統會強加一些輕微的限制到它運行工作和觸發警報的能力上。詳情請查看【電量管理限制】。
頻繁
如果應用定期使用，但不是每天都必需的，那么它在“頻繁”群組中。例如，一款用戶在健身房運行的用於追蹤鍛煉的應用就有可能在“頻繁”群組中。
如果應用在“頻繁”群組中，系統會施加更大的限制在它運行工作和觸發警報的能力上，並對高優先級的FCM消息上施加上限。詳情請查看【電量管理限制】。
罕見
如果一款應用不經常使用，那么它在“罕見”群組中。例如，只有當用戶待在某家旅館時才會運行的該旅館應用，可能會在“罕見”群組中。
如果應用在“罕見”群組中，系統會對它運行工作、觸發警報以及接收高優先級FCM消息的能力施加嚴格的限制。系統也會限制該應用連接到因特網的能力。詳情請查看【電量管理限制】。
最好的實踐
如果應用已經為Doze和應用待機遵循了最好的實踐，那么處理新的電量管理特征就不是難事。可是，一些以前工作得很好的應用行為可能會導致一些問題。
- 不要試圖篡改系統來把你的應用放入到指定的某個群組或其它群組中。系統把應用分配到群組的方法可以改變，並且每一個設備廠商都可以選擇用他們自己的算法來寫他們自己的用於分群組的應用。相反，你應該確保應用無論在哪個群組中都應該合適地表現。
- 如果應用沒用用於啟動的Activity，它可能永遠都不會提升到“活躍”群組中。你可能要重新設計你的應用讓它擁有這樣的Activity。
- 如果應用的通知是失效的，那么用戶將無法通過與通知交互來把觸發應用提升到“活躍”群組。在這種情況下，你可能需要重新設計一些合適的通知，好讓這些通知允許來自用戶的響應。想了解指導意見，請查看材料設計【通知設計模式】。
- 相似地，如果應用在收到高優先級FCM消息的時候沒有顯示通知，這將不會給用戶和應用交互的機會來提升該應用到“活躍”群組。實際上，使用高優先級FCM消息的唯一意圖是給用戶推送通知，所以這種情形應該絕對不能發生。如果在沒有觸發用戶交互時，你不恰當地標記FCM消息為高優先級，這樣會導致其他負面的影響；例如，這樣會導致你的應用耗盡它的配額，導致真正緊急的FCM消息被當成正常優先級。
★ 注意：如果用戶重復地移除通知，將來系統會給用戶限制通知的選擇權。不要僅僅為了嘗試保持你的應用在“活躍”群組中而使用通知給用戶發送垃圾信息。
- 如果應用被拆分為多個包，這些包可能在不同的群組中，並且有不同的訪問級別。你應該確保使用被分配到不同群組中的包來測試應用，以確保應用正常運行。
結語
本文最大限度保持原文的意思，由於筆者水平有限，若有翻譯不准確或不妥當的地方，請指正，謝謝！