Android 9 (API 級別 28) 以上版本支援應用程式待命值區。應用程式待命值區會根據應用程式的使用時間和使用頻率,協助應用程式優先處理資源要求。根據應用程式使用模式,每個應用程式都會排入五個優先順序值區的其中之一。系統會根據應用程式所在的值區,限制每個應用程式可用的裝置資源。
優先值區
系統會以動態方式指派每個應用程式至一個優先順序值區,並視需要重新指派應用程式。系統可能需要仰賴使用機器學習技術的預先載入應用程式,判斷每個應用程式的使用機率,然後將應用程式指派到適當的值區。如果裝置上沒有系統應用程式,系統會預設根據應用程式的上次使用時間排序應用程式。活動較頻繁的應用程式會指派至賦予較高優先順序的值區,以便為該應用程式提供更多系統資源。具體來說,值區會決定應用程式工作的執行頻率,以及應用程式觸發鬧鐘的頻率。這些限制只有在裝置使用電池電力時才適用;如果裝置正在充電,系統不會對應用程式強制執行這些限制。
注意:針對非使用中應用程式如何指派至值區,每個製造商都可以設定各自的條件。建議不要嘗試改變應用程式指派的值區,而是專注於確保應用程式無論在哪個值區都能正常運作。應用程式可以呼叫
UsageStatsManager.getAppStandbyBucket()
以找出其目前所在的值區。
值區為:
- 使用中:應用程式目前正在使用或最近使用過。
- 工作組:應用程式會定期使用。
- 常用:應用程式經常使用,但不是每天都會使用。
- 很少使用:應用程式不常使用。
- 受限制:應用程式會耗用大量系統資源,或可能有不理想的行為。
此外,對於曾經安裝但從未執行的應用程式,也有特殊的「永不」值區。系統對這類應用程式設有嚴格的限制。
注意:若應用程式列在打盹豁免清單中,就不受應用程式待命值區相關限制。
注意:下列說明僅適用於沒有預測功能的案例。相反地,當預測功能使用機器學習技術預測行為時,選擇值區的依據是系統對使用者接下來動作的預期,而非上次使用時間。舉例來說,最近使用過的應用程式可能會指派至很少使用的值區,因為機器學習預測使用者不會持續使用應用程式數小時。
使用中
如果使用者正在使用應用程式,或是最近使用過應用程式,應用程式就會在「使用中」值區中。例如:
- 應用程式已經啟動一項活動
- 應用程式正在執行前景服務
- 應用程式的同步轉換介面與前景應用程式所用的內容供應器相關聯
- 使用者點選應用程式通知
如果應用程式位在使用中值區,系統就不會對應用程式的工作或鬧鐘設下任何限制。
使用者互動會將應用程式排入「使用中」值區
在 Android 9 (API 級別 28) 以上版本中,當使用者以特定方式與應用程式互動時,系統會暫時將應用程式排入使用中值區。如果使用者停止與應用程式互動,經過一段時間後,系統會根據使用記錄將應用程式排入其中一個值區。
以下列舉可觸發這項系統行為的互動情形:
使用者輕觸應用程式傳送的通知。
使用者按下媒體按鈕,與應用程式中的前景服務互動。
使用者在與 Android Automotive OS 互動時連線至應用程式,而且應用程式在這個作業系統中使用前景服務或
CONNECTION_TYPE_PROJECTION
。
工作組
若應用程式經常執行,但目前並未處於使用中的狀態,就會排入工作組值區。舉例來說,使用者最常啟動的社群媒體應用程式可能就位於工作組中。如果是間接使用的應用程式,也會升級至工作組值區。
假使應用程式位於工作組,系統會對其執行工作及觸發鬧鐘的功能設下輕微限制。詳情請參閱「電源管理限制」。
常用
如果應用程式經常使用,但不一定是每天使用,則會指派至「常用」值區。舉例來說,使用者在健身房執行的健身追蹤應用程式可能就位於常用值區。
假使應用程式位於常用值區,系統會對其執行工作及觸發鬧鐘的功能設下較嚴格的限制。詳情請參閱「電源管理限制」。
很少使用
不常使用的應用程式會指派至很少使用值區。舉例來說,使用者只有在飯店入住期間才會執行的飯店應用程式,可能就位於很少使用值區中。
假使應用程式位於很少使用值區,系統會對其執行工作及觸發鬧鐘的功能設下嚴格限制。此外,系統也會限制這類應用程式的網際網路連線功能。詳情請參閱「電源管理限制」。
受限制
這是 Android 12 (API 級別 31) 中新加入的值區,也是優先順序最低且限制最嚴格的值區。系統會考量應用程式的行為,例如使用者與應用程式互動的頻率,藉此判斷是否將應用程式排入受限制值區。
在 Android 13 (API 級別 33) 以上版本中,除非應用程式符合豁免條件,否則系統會在下列情況將應用程式排入受限制值區:
使用者未與應用程式互動的時間達到特定天數。在 Android 12 (API 級別 31) 和 12L (API 級別 32) 中,此天數為 45 天;Android 13 則減少為 8 天。
如果系統將應用程式排入受限制值區,就會套用以下限制:
- 每天可在 10 分鐘的批次工作階段中執行工作一次。在此工作階段期間,系統會將應用程式工作與其他應用程式的工作歸為一組。
- 受限制的工作無法自動執行,至少必須同時有另一項工作 (任何其他工作都行) 正在執行/等待處理才能執行。
- 比起位於限制較少的值區,在受限制值區的應用程式可以執行的加急作業較少。
- 應用程式每天可以觸發一次鬧鐘。此鬧鐘可以是精確的鬧鐘或不精確的鬧鐘。
不必進入受限制值區的豁免條件
下列類型的應用程式不必進入「受限制」應用程式待命值區,而且會略過閒置觸發條件,即使在 Android 12 以上版本中也一樣:
- 配對裝置應用程式
- 透過展示模式在裝置上執行的應用程式
- 裝置擁有者應用程式
- 設定檔擁有者應用程式
- 永久應用程式
- VPN 應用程式
- 具備
ROLE_DIALER
角色的應用程式 - 使用者在系統設定中明確指定為提供「無限制」功能的應用程式
- 具備使用中小工具的應用程式
- 在子母畫面 (PiP) 模式下顯示的應用程式
- 畫面上正在使用的應用程式
- 至少獲得下列其中一項權限的應用程式:
最佳做法
如果應用程式已經採用打盹和應用程式待命的最佳做法,處理新的電源管理功能應該不會太難。不過,先前使用效果不錯的應用程式行為現在可能會導致問題發生。
- 請勿試圖操控系統,將應用程式指派至某個值區或改變所在值區。系統的值區劃分方法可能會改變,每個裝置製造商也可能選擇以自家演算法編寫值區劃分應用程式。建議您改為確保應用程式不論處於哪個值區,都能以正確的方式運作。
- 如果應用程式沒有啟動器活動,就可能完全無法升級至使用中值區。此時建議您重新設計應用程式,使應用程式具有此類活動。
- 如果應用程式的通知無法採取行動,使用者將無法透過與通知互動,觸發升級應用程式至使用中值區。在這種情況下,建議您重新設計幾種合適的通知,以便使用者回應。如要瞭解相關準則,請參閱質感設計的通知設計模式說明。
- 同樣地,如果應用程式在收到高優先順序 Firebase 雲端通訊 (FCM) 訊息時未顯示通知,就沒有機會讓使用者與應用程式互動,也無法進而將應用程式升級至使用中值區。事實上,高優先順序 FCM 訊息的唯一用途就是向使用者推送通知,因此不應發生這種情形。在 12L (API 級別 32) 以下版本中,如果您在 FCM 訊息未觸發使用者互動時,將這類訊息不當標示為高優先順序,可能會導致系統將日後訊息的優先順序降低。
注意:如果使用者屢次關閉通知,系統會向使用者提供在日後封鎖該通知的選項。請不要為了將應用程式保持在使用中值區,而傳送過多通知給使用者!
- 如果應用程式分割成多個套件,這些套件可能會位於不同的值區中,因此會有不同的存取層級。若應用程式的套件會指派至不同值區,建議您一定要測試這類應用程式,確保相關運作方式正確無誤。
測試
如要查看應用程式所在的值區,請執行下列其中一項操作:
- 呼叫
getAppStandbyBucket()
。 -
在終端機視窗中執行下列指令:
adb shell am get-standby-bucket PACKAGE_NAME
每當應用程式放入應用程式待命值區,而其值又大於 STANDBY_BUCKET_ACTIVE
(10),系統就會節流應用程式。