自 Android 6.0（API 23）起，系統引入兩項電池優化機制：低電耗模式（Doze Mode）與應用待機模式（App Standby）。它們通過限制後台活動來延長續航，但也帶來了應用行為改變，特別是依賴後台運行、網絡長連接或定時任務的業務場景，如 MDM 系統應用。
1. 低電耗模式（Doze Mode）
觸發條件
設備滿足以下條件時進入 Doze：
- 屏幕關閉。
- 設備未連接電源。
- 長時間保持靜止狀態（加速度變化極小）。
根據官方文檔，如果用户將設備置於“未充電且靜止且屏幕關閉”狀態，設備將進入 Doze。([Android Developers][1])
從 Android 7.0 起，即使設備並未完全靜止，只要屏幕關閉且未充電，系統也會啓用輕度 Doze 模式。([Android Developers][2])
限制內容
根據官方説明，進入 Doze 後系統對於應用執行的限制包括：([Android Developers][1])
- 網絡訪問暫停。
- 喚醒鎖（Wake Lock）被忽略。
- 標準 AlarmManager 的鬧鐘（如
setExact()、setWindow()）延遲執行。 - WiFi 掃描暫停。
- 同步適配器（SyncAdapter）與 JobScheduler 任務延遲。
系統會在週期性的“維護窗口”（maintenance window）中短暫允許後台任務運行，隨後再次進入休眠模式。([Android Open Source Project][3])
恢復條件
當下列條件之一發生時，設備將退出 Doze 模式：
- 用户點亮屏幕。
- 設備開始充電。
- 檢測到設備移動或用户交互。
這些均為系統檢測到“設備不再閒置”的標誌。([Android Open Source Project][3])
對 MDM 的影響
對於需要持續後台運行、保持連接的 MDM 應用而言，Doze 模式帶來重大挑戰：
- 策略下發可能延遲。
- 心跳或長連接可能被中斷。
- 後台同步、遠程指令響應不及時。
- 定時任務、上報任務可能在維護窗口之前無法執行。
因此，對於關鍵後台任務，應考慮使用如 AlarmManager.setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle() 等接口，以降低 Doze 限制影響。([Android Developers][1])
2. 應用待機模式（App Standby）
觸發條件
當某個應用長期未被用户打開或交互時，系統可能將其判定為“空閒應用”。包括以下判斷標準：
- 最近是否由用户直接啓動。
- 是否有前台 Activity 或前台服務。
- 是否存在用户交互行為。
官方文檔指出：從 Android 6.0 開始，系統會管理所有應用的閒置行為，若用户長時間未與應用交互，系統會限制其後台網絡或 CPU 活動。([Android Git Repositories][4])
限制內容
應用處於待機狀態後，系統可能執行以下限制：
- 後台網絡訪問受限。
- 後台任務（JobScheduler、AlarmManager）調度延遲。
- 系統僅在少量訪問窗口中允許活躍執行。
在 Android 9（API 28）及以上版本，應用待機進一步引入 “App Standby Buckets” 機制，根據應用使用頻率將其分類，以限制資源訪問。([Android Developers][5])
恢復條件
應用重新被用户啓動、進入前台或設備開始充電時，系統即解除待機限制。
與 Doze 模式的區別
|
對比項
|
Doze Mode
|
App Standby
|
|
優化對象
|
整個設備
|
單個應用
|
|
觸發來源
|
屏幕關閉、未充電、靜止
|
應用無用户交互
|
|
限制力度
|
較強
|
中等
|
|
恢復方式
|
用户交互、充電、移動設備
|
應用被使用、充電
|
3. 後台回收機制與 MDM 應用風險
除了 Doze 與 App Standby 外，Android 系統還會根據進程運行優先級、內存狀況和後台活躍度執行 後台回收。當應用處於以下狀態時，風險顯著增高：
- 長期沒有前台界面或用户交互。
- 未保持前台服務。
- 屏幕長期關閉且設備閒置。
在這種情況下：
- 應用可能被系統強制殺死。
- 後台服務可能無法自恢復。
- 心跳、網絡連接、任務調度可能徹底中斷。
對於 MDM 應用而言，這種行為可能直接導致設備脱離管理、策略失效。
4. MDM 應用保活建議
為保證 MDM 應用在長期黑屏狀態下仍具備穩定後台運行能力，應參考官方機制並進行以下適配：
- 使用 前台服務（Foreground Service）保持應用進程優先級。
- 引導用户啓用“忽略電池優化”權限，使應用免受部分 Doze 限制。
- 將關鍵任務整合進 JobScheduler、WorkManager 等系統調度機制，以配合系統維護窗口執行。([Android Developers Blog][6])
- 針對應用使用頻率低的情況（如無前台交互）做好 App Standby Buckets 機制響應。([Android Developers][5])
- 在設備出廠或配置階段，確保後台運行權限、自啓動權限、守護服務配置均正確。
- 優化任務邏輯，避免頻繁喚醒、過度輪詢，以減少被系統識別為“耗電高、不活躍”應用的風險。
儘管採用上述策略，仍要認識到：系統電池優化機制優先級高於應用保活需求。 MDM 應用存在仍被系統終止的風險。