【官網翻譯】性能篇（一）應用待機羣組

前言

       本文翻譯了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消息被當成正常優先級。

★ 注意：若是用戶重複地移除通知，未來系統會給用戶限制通知的選擇權。不要僅僅爲了嘗試保持你的應用在「活躍」羣組中而使用通知給用戶發送垃圾信息。

• 若是應用被拆分爲多個包，這些包可能在不一樣的羣組中，而且有不一樣的訪問級別。你應該確保使用被分配到不一樣羣組中的包來測試應用，以確保應用正常運行。

 

結語

       本文最大限度保持原文的意思，因爲筆者水平有限，如有翻譯不許確或不穩當的地方，請指正，謝謝！