應用程式待命值區

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 天。

  注意：裝置處於關閉狀態的持續時間不會計入互動限制。

• 應用程式在 24 小時內叫用播送或繫結的次數過多。

如果系統將應用程式排入受限制值區，就會套用以下限制：

• 每天可在 10 分鐘的批次工作階段中執行工作一次。在此工作階段期間，系統會將應用程式工作與其他應用程式的工作歸為一組。
  • 受限制的工作無法單獨執行，必須與至少一個執行中或待處理工作同時執行，這類工作可能包含任何其他工作。
• 比起位於限制較少的值區，在受限制值區的應用程式可以執行的加急作業較少。
• 應用程式每天可以觸發一次鬧鐘。此鬧鐘可以是精確鬧鐘或不精確鬧鐘。

注意：即使裝置正在充電，電源管理限制仍適用於受限制值區，這點與其他值區不同。不過，當裝置正在充電、閒置及使用非計量付費網路時，限制會放寬。

受限制值區的豁免條件

下列應用程式類型不必進入受限制值區，而且會略過閒置觸發條件，即使在 Android 12 以上版本也一樣：

• 配對裝置應用程式
• 透過展示模式在裝置上執行的應用程式
• 裝置擁有者應用程式
• 資料夾擁有者應用程式
• 永久應用程式
• VPN 應用程式
• 具備 ROLE_DIALER 角色的應用程式
• 使用者在系統設定中明確指定為提供「無限制」功能的應用程式
• 具備使用中小工具的應用程式
• 至少獲得下列其中一項權限的應用程式：
  • USE_EXACT_ALARM
  • ACCESS_BACKGROUND_LOCATION

評估優先順序值區

如要查看應用程式獲派的值區，請執行下列其中一項操作：

• 呼叫 getAppStandbyBucket()。

• 在終端機視窗中執行下列指令：

  adb shell am get-standby-bucket PACKAGE_NAME

每當應用程式排入應用程式待命值區，而該值區的值大於 STANDBY_BUCKET_ACTIVE (10) 時，系統就會對應用程式設下節流限制。

最佳做法

如果應用程式採用打盹和應用程式待命的最佳做法，處理後續的電源管理功能不會很難。不過，某些先前運作良好的應用程式行為可能會造成問題。

• 請勿試圖操控系統，將應用程式排入特定值區。系統設置優先順序的方式可能會改變，每個裝置製造商也可能選擇以自家演算法編寫用來指派值區的應用程式。建議您改為確保無論所在值區為何，應用程式都能正確運作。
• 如果應用程式沒有啟動器活動，就可能完全無法升級至使用中值區。建議您重新設計應用程式，使應用程式具有此類活動。

• 如果使用者無法與應用程式通知互動，就無法讓應用程式升級至使用中值區。在此情況下，請考慮重新設計部分通知，讓使用者可與通知互動。如要瞭解相關準則，請參閱 Material Design 的通知設計模式說明。

• 如果應用程式在收到高優先順序 Firebase 雲端通訊 (FCM) 訊息時未顯示通知，使用者就無法與應用程式互動，也就無法將應用程式升級至使用中值區。事實上，高優先順序 FCM 訊息的唯一用途，就是推送通知給使用者，因此絕不應發生這種情況。在 12L (API 級別 32) 以下版本中，如果您在 FCM 訊息未觸發使用者互動時，將這類訊息不當標示為高優先順序，可能會導致系統降低日後訊息的優先順序。

  注意：如果使用者屢次關閉通知，系統會向使用者提供在日後封鎖該通知的選項。請不要為了將應用程式保持在使用中值區，而傳送過多通知給使用者。

• 如果應用程式分為多個套件，這些套件可能會位於不同的值區，並具有不同的存取層級。若應用程式的套件獲派至不同值區，請測試應用程式，確保應用程式正常運作。