針對打盹和應用程式待命進行最佳化

從 Android 6.0 (API 級別 23) 開始，Android 推出了兩項省電功能，可管理裝置未連線至充電器時的應用程式行為，藉此延長電池續航力。打盹功能會在裝置長時間未使用時延遲應用程式的背景 CPU 和網路活動，藉此降低電池耗電量。應用程式待命功能會針對使用者最近未進行互動的應用程式，延遲背景網路活動。

當裝置處於「打盹」模式時，系統會延後應用程式對某些耗用大量電力的資源存取作業，直到維護期間才會完成。如需具體限制清單，請參閱「電源管理限制」。

無論應用程式是否明確指定 API 級別 23，都須透過「打盹」和「應用程式待命」功能管理所有在 Android 6.0 以上版本中運作的應用程式行為。 為確保使用者能獲得最佳體驗，請以打盹和應用程式待命模式測試應用程式，並視需要調整程式碼。以下各節將詳細說明。

認識「打盹」功能

如果使用者將裝置未接上電源並靜止一段時間，且螢幕關閉時，裝置會進入打盹模式。在打盹模式中，系統會限制應用程式存取網路和耗用大量 CPU 的服務，藉此節省電池電力。同時防止應用程式存取網路，以及延後工作、同步和標準鬧鐘。

系統會定期結束「打盹」模式，讓應用程式完成延後的活動。在這個維護期間，系統會執行所有待處理的同步處理、工作和鬧鐘，並允許應用程式存取網路。

圖 1. 「打盹」功能可為應用程式提供週期性維護期間，可讓應用程式使用網路及處理待處理活動。

在每個維護期間結束時，系統會再次進入「打盹」模式，暫停存取網路、延後工作、同步處理和鬧鐘。系統會隨著時間逐漸縮短維護期間的排程頻率，並在裝置未接上充電器時，減少長時間閒置的情形，藉此降低電池消耗量。

當使用者透過移動裝置、開啟螢幕或接上充電器的方式喚醒裝置時，系統會結束「打盹」模式，所有應用程式都會返回一般活動。

打盹限制

「打盹」功能中的應用程式適用下列限制：

• 網路存取權已暫停。
• 系統會忽略 Wake Lock。
• 標準 AlarmManager 鬧鐘 (包括 setExact() 和 setWindow()) 會延後到下一個維護期間。
• • 如需設定在打盹狀態下觸發的鬧鐘，請使用 setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle()。
  • 使用 setAlarmClock() 設定的鬧鐘會繼續正常觸發，系統會在這些警報觸發前不久就結束「打盹」。
• 系統不會掃描 Wi-Fi。
• 系統不允許執行同步轉換介面。
• 系統不允許執行 JobScheduler。

打盹檢查清單

• 可能的話，請使用 Firebase 雲端通訊 (FCM) 進行 下游訊息傳遞。
• 如果使用者必須立即看到通知，請務必使用 高優先順序 FCM 的訊息。請您務必只針對會出現通知的郵件使用高優先順序。如需詳細指引，請參閱 FCM 說明文件：Android 訊息優先順序的說明文件。
• 在初始訊息酬載中提供足夠的資訊，就不需要後續的網路存取。
• 透過 setAndAllowWhileIdle() 和 setExactAndAllowWhileIdle() 設定重要鬧鐘。
• 在打盹中測試應用程式。

根據「打盹」功能調整應用程式

視應用程式提供的功能和服務使用的服務而定，「打盹」模式對於應用程式的影響不盡相同。許多應用程式不必經過修改，就能在打盹週期中照常運作。在某些情況下，您必須最佳化應用程式管理網路、鬧鐘、工作和同步處理的方式。應用程式應能在每個維護期間有效管理活動。

「打盹」功能可能會影響 AlarmManager 鬧鐘和計時器管理的活動，因為 Android 5.1 (API 級別 22) 以下版本中的鬧鐘不會在系統處於打盹狀態時觸發。

為協助安排鬧鐘，Android 6.0 (API 級別 23) 推出了兩個新的 AlarmManager 方法：setAndAllowWhileIdle() 和 setExactAndAllowWhileIdle()。透過這些方法，您可以設定即使裝置處於「打盹」模式，也會觸發鬧鐘。

注意：setAndAllowWhileIdle() 和 setExactAndAllowWhileIdle() 在每個應用程式每 9 分鐘都只能觸發一次鬧鐘超過一次。

此外，針對網路存取權的「打盹」限制也可能會影響您的應用程式，特別是當應用程式依賴即時訊息 (例如滴答或通知) 時。如果應用程式需要永久連線至網路才能接收訊息，則應盡可能使用 Firebase 雲端通訊 (FCM)。

如要確認應用程式透過打盹功能確認應用程式的行為符合預期，您可以使用 ADB 指令強制系統進入及退出「打盹」模式，並觀察應用程式的行為。詳情請參閱「使用打盹和應用程式待命測試」。

瞭解應用程式待命

應用程式待命可讓系統在使用者未主動使用應用程式時，判斷應用程式是否處於閒置狀態。當使用者在特定時間內未輕觸應用程式，且不符合下列任何條件時，系統會做出此判斷：

• 使用者明確啟動應用程式。
• 應用程式目前在前景有程序 (可以是活動或前景服務，或是由其他活動或前景服務使用)。

  注意：建議您僅針對使用者會預期系統立即執行或不會中斷的工作使用前景服務。例如將相片上傳到社群媒體，或是在音樂播放器應用程式不在前景的情況下播放音樂。請勿啟動前景服務，以免系統判定應用程式處於閒置狀態。

• 應用程式會產生通知，使用者會在鎖定畫面或通知匣中看到。
• 應用程式為使用中的裝置管理員應用程式 (例如裝置政策控制器)。雖然裝置管理員應用程式通常會在背景執行，但因為裝置管理員應用程式必須隨時能從伺服器接收政策，因此絕對不會進入「應用程式待命」模式。

使用者將裝置插入電源供應器時，系統會將應用程式從待命狀態釋出，以自由存取網路及執行任何待處理工作及同步處理。如果裝置長時間閒置，系統會允許閒置應用程式網路大約每天一次存取一次。

在裝置處於閒置狀態時使用 FCM 與應用程式互動

Firebase 雲端通訊 (FCM) 是一項雲端對裝置服務，可讓您支援 Android 裝置後端服務和應用程式之間的即時下游訊息傳遞。FCM 會提供單一的雲端永久連線；需要即時通訊的所有應用程式都可以共用這個連線。這個共用連線會讓多個應用程式不必維護另外的永久連線，從而快速消耗電力，進而大幅最佳化電池耗電量。因此，如果您的應用程式需要與後端服務整合訊息功能，強烈建議您盡可能使用 FCM，而不要維持自己的永久網路連線。

FCM 已經過最佳化，可與打盹和應用程式待命模式搭配使用。FCM 高優先順序訊息可讓您穩定喚醒應用程式，以便與使用者互動。在打盹模式或應用程式待命模式中，系統會傳送訊息，並授予應用程式暫時存取網路服務和部分 Wake Lock，然後再將裝置或應用程式傳回閒置狀態。針對具有時效性且使用者可察覺的通知，請考慮使用高優先順序的訊息，以便在打盹模式中傳送。 高優先順序的訊息預計會收到通知。詳情請參閱 FCM 的指南，瞭解高優先順序訊息的相關資訊。

如果訊息不會產生通知，例如在背景中讓應用程式內容保持在最新狀態，或是啟動資料同步處理，則適合以一般優先順序 FCM 訊息傳送。如果裝置未處於休眠狀態，則會立即傳送一般優先順序的訊息。如果裝置處於打盹模式，裝置會在定期打盹維護期間或使用者喚醒裝置後立即收到。

一般來說，如果應用程式需要下游訊息，則應使用 FCM。如果您的應用程式已使用 FCM，請確認應用程式只會針對會向使用者顯示通知的訊息使用高優先順序的訊息。

其他用途的支援

幾乎所有應用程式都可使用 FCM 訊息來管理網路連線、鬧鐘、工作和同步處理作業，藉此支援「打盹」。如果用途較小，可能尚未足夠。在此情況下，系統會提供可設定的應用程式清單，這些項目分別不受打盹和應用程式待命最佳化功能的約束。

部分豁免項目的應用程式可在打盹和應用程式待命期間使用網路，並保留部分 Wake Lock。不過，應用程式仍會受到其他限制，就跟其他應用程式一樣。舉例來說，應用程式的工作和同步處理作業會延後 (在 API 級別 23 以下)，也不會觸發一般 AlarmManager 鬧鐘。應用程式可以呼叫 isIgnoringBatteryOptimizations()，確認目前是否列於豁免清單中。

使用者可以依序前往「設定」>「電池」>「電池最佳化」，手動設定豁免的應用程式清單。或者，系統也提供多種方式，讓應用程式要求使用者不受限制：

• 大多數應用程式都應叫用包含 ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS 的意圖。
• 符合可接受用途的應用程式可以改為叫用包含 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 意圖動作的意圖，讓使用者直接將應用程式新增至豁免清單，而不必前往系統設定。

注意：Google Play 政策禁止應用程式直接要求不受 Android 6.0 以上版本 (打盹和應用程式待命) 的電源管理功能限制，除非應用程式的核心功能受到負面影響。

應用程式可以呼叫 isIgnoringBatteryOptimizations()，確認目前是否列於豁免清單中。

使用打盹和應用程式待命功能進行測試

為確保使用者能獲得良好體驗，建議您在打盹和應用程式待命模式中全面測試應用程式。

使用打盹功能測試應用程式

您可以按照下列步驟測試打盹模式：

1. 使用 Android 6.0 (API 級別 23) 以上版本的系統映像檔設定硬體裝置或虛擬裝置。
2. 將裝置連線至開發機器，然後安裝應用程式。
3. 執行應用程式，並讓應用程式保持啟用狀態。
4. 執行下列指令，強制系統進入閒置模式：

   $ adb shell dumpsys deviceidle force-idle
   

5. 準備就緒後，請執行下列指令，結束閒置模式：

   $ adb shell dumpsys deviceidle unforce
   

6. 執行下列指令，重新啟用裝置：

   $ adb shell dumpsys battery reset
     

7. 重新啟用裝置後，觀察應用程式的行為。確認應用程式在裝置結束打盹模式時可以順利復原。

使用應用程式待命測試您的應用程式

如何使用應用程式測試應用程式待命模式：

1. 使用 Android 6.0 (API 級別 23) 以上版本的系統映像檔設定硬體裝置或虛擬裝置。
2. 將裝置連線至開發機器，然後安裝應用程式。
3. 執行應用程式，並讓應用程式保持啟用狀態。
4. 執行下列指令，強制應用程式進入應用程式待機模式：

   $ adb shell dumpsys battery unplug
   $ adb shell am set-inactive <packageName> true

5. 使用下列指令模擬喚醒應用程式：

   $ adb shell am set-inactive <packageName> false
   $ adb shell am get-inactive <packageName>

6. 觀察應用程式喚醒後的行為。確認應用程式可以順利從待機模式復原。請特別留意應用程式的通知和背景工作是否繼續正常運作。

符合豁免資格的用途

下表重點介紹幾種用途，以及應用程式能否在這類情況下使用 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 意圖動作。一般來說，除非「打盹」或「應用程式待命」功能會破壞應用程式的核心功能，或是有技術原因導致應用程式無法使用 FCM 高優先順序訊息，否則您的應用程式不應出現在清單中。

詳情請參閱其他用途的支援服務 。

類型	使用案例	可以使用 FCM 嗎？	允許豁免？	附註
即時通訊、即時通訊或通話應用程式。	當裝置處於打盹模式或應用程式處於「應用程式待命」模式時，需要向使用者傳送即時訊息。	是，使用 FCM	不接受	應使用 FCM 高優先順序訊息喚醒應用程式及存取網路。
		是，但沒有使用 FCM 高優先順序的訊息。
即時通訊、即時通訊或通話應用程式；企業 IP 應用程式。		不可以，因為其他訊息傳遞服務或打盹和應用程式待命的技術依附元件會破壞應用程式的核心功能，因此無法使用 FCM。	可接受
「安全」應用程式	旨在確保使用者和家庭安全的應用程式。	依適用情況提供。	可接受
自動化任務應用程式	應用程式的核心功能會排定自動化動作，例如即時通訊、語音通話或新相片管理。	依適用情況提供。	可接受
週邊裝置隨附應用程式	應用程式的核心功能會保持與週邊裝置的永久連線，以便提供週邊裝置網際網路存取權。	依適用情況提供。	可接受
	應用程式只需定期連線至週邊裝置，或是需要連線至透過標準藍牙設定檔連線的裝置 (例如無線耳機) 即可。	依適用情況提供。	不接受