找出並改善喚醒鎖定應用實例

本文說明如何找出及最佳化應用程式中的 Wake Lock 用途，並指出與此用途相關的其他程式庫或系統 API 是否取得 Wake Lock。由於這些 Wake Lock 是應用程式所致，因此很難找出有問題的 Wake Lock 來源。即使您未明確取得喚醒鎖定，不正確的 API 用法仍可能導致應用程式因過度使用喚醒鎖定而遭到標記。

本文列出一些常見的喚醒鎖定名稱，您在使用Wake Lock 偵錯工具時，或在生命徵象的報表中可能會看到這些名稱。這些名稱可能來自程式庫或系統 API，也可能經過混淆處理。使用偵錯工具找出異常的 Wake Lock，然後在本文件中搜尋 Wake Lock 名稱，即可判斷是哪個 API 造成問題，並取得最佳化使用方式的建議。

本文將說明取得喚醒鎖的常見用途，詳細列出各種 API 和程式庫使用的喚醒鎖名稱，並提供相關建議和最佳做法，協助您最佳化及減少喚醒鎖用量。

• AlarmManager
• 音訊和媒體
• 藍牙
• 裝置感應器
• Firebase 雲端通訊 (FCM)
• JobScheduler
• 位置
• 遠端傳訊
• WorkManager
• _UNKNOWN：如果 Wake Lock 名稱似乎使用個人識別資訊 (PII)，偵錯工具就會顯示這項資訊。

AlarmManager

AlarmManager 會取得 Wake Lock，並將其歸因於呼叫應用程式。鬧鐘響起時，AlarmManager 會取得 Wake Lock，並在鬧鐘廣播的 onReceive() 方法執行完畢時釋放鎖定。

Wake Lock 名稱

AlarmManager 會建立名為 *alarm* 的喚醒鎖定。(星號是 Wake Lock 名稱的一部分，不代表萬用字元)。

建議

建議您採取下列做法，將警報行為調整至最佳狀態：

• 請參閱「選擇鬧鐘類型」，決定要使用不精確或精確的鬧鐘。如果鬧鐘不需要精確，請使用不精確的鬧鐘，讓系統在排程方面有更多彈性，進而提升電池續航力。
• 請注意系統設定的鬧鐘配額，並設計應用程式來遵守這些配額。
• 避免在 onReceive() 方法中執行長時間工作，並在鬧鐘響起後需要額外處理時排定工作人員。

音訊和媒體

媒體 API 可以在錄製或播放音訊時取得喚醒鎖定。 喚醒鎖定會歸因於通話應用程式。

Wake Lock 名稱

媒體 API 會取得各種名稱開頭為 Audio 的喚醒鎖定：

• AudioBitPerfect：用於無損 USB 音訊播放。
• AudioDirectOut：用於在電視或特殊裝置上播放無損音訊。
• AudioDup：透過藍牙或 USB 連線時，用於播放通知。
• AudioIn：在攝影機模式下，麥克風處於啟用狀態時，用於擷取音訊。
• AudioMix：用於在一般裝置上播放音訊。
• AudioOffload：用於長期播放純音樂，適用於支援此模式的應用程式。
• AudioSpatial：用於在支援環場音效的裝置上播放多聲道電影或音樂音訊。
• AudioUnknown：適用於其他情況。
• MmapCapture：用於低延遲音訊擷取。
• MmapPlayback：用於低延遲播放，例如遊戲或專業音訊應用程式。

建議

建議您採取下列做法：

• 請勿宣告開頭為 Audio 的 Wake Lock 名稱。
• 如果您使用媒體 API，應該不需要直接取得喚醒鎖定，可以依賴 API 為您取得必要的喚醒鎖定。
• 使用 Media API 時，如果不再需要媒體工作階段和相關聯的前景服務，請結束這些項目。

藍牙

平台藍牙 API 主要會在發生藍牙動作時保留核心喚醒鎖定，這不屬於應用程式。

建議

• 使用「隨附裝置配對」配對藍牙裝置，避免在藍牙配對期間取得手動 Wake Lock。
• 請參閱在背景中通訊指南，瞭解如何進行背景藍牙通訊。
• 如果延遲通訊不會對使用者造成影響，通常使用 WorkManager 就足夠。如果認為必須手動取得 Wake Lock，請只在藍牙活動期間或處理活動記錄時保留 Wake Lock。

裝置感應器

您可以透過多種方法追蹤裝置感應器資料，例如步數、加速計或陀螺儀資料。

在 Wear OS 上，使用 Wear 健康照護服務擷取裝置資料，例如海拔高度、心率和移動距離。

如果資料是由其他應用程式收集，您可以結合使用 健康資料同步和 WorkManager，定期擷取資料。

如要追蹤步數或移動距離的變化，可以使用行動裝置上的 Recording API，並搭配 WorkManager 定期擷取資料。如要存取歷來步數資料 (例如每日步數總計或過去 6 小時的步數)，「健康資料同步」也支援在搭載 Android 14 以上版本的裝置上裝置端步數追蹤。

在某些情況下，可能需要使用 SensorManager 追蹤自訂裝置感應器。除非感應器是喚醒感應器 (可使用 isWakeUpSensor API 識別)，否則 SensorManager 不會代表應用程式取得喚醒鎖定。

建議

使用感應器以高取樣率記錄資料可能會大幅耗用電池電量，以下是減少電池耗電和 Wake Lock 用量的建議：

• 如要追蹤步數或移動距離，請使用 Recording API 以省電的方式記錄資料。如果裝置搭載 Android 14 以上版本，建議使用「健康資料同步」存取裝置的歷史記錄和匯總步數。
• 如要在 Wear OS 上被動追蹤感應器，請使用 Wear 健康照護服務，盡量節省電量。
• 向 SensorManager 註冊感應器時，請定義超過 30 秒的 maxReportLatencyUs，以便使用感應器批次處理邏輯，並減少應用程式收到的中斷次數。當裝置隨後因其他觸發條件 (例如使用者互動、位置資訊擷取或已排定的工作) 而喚醒時，系統會立即傳送快取感應器資料。
• 如果應用程式需要位置和感應器資料，請同步處理事件擷取和處理作業。將感應器讀數合併到系統為位置資訊更新保留的簡短 Wake Lock 中，即可避免需要 Wake Lock 來保持 CPU 喚醒狀態。使用 worker 或短時間 Wake Lock，處理合併資料的上傳和處理作業。

Firebase 雲端通訊 (FCM)

將 Firebase 雲端訊息 (FCM) 廣播傳送至應用程式時，系統會取得 Wake Lock。FCM 廣播的 onMessageReceived() 方法執行完畢後，系統就會釋出 Wake Lock。

Wake Lock 名稱

裝置收到 FCM 訊息時，系統會短暫保留 Wake Lock，名稱為 GOOGLE_C2DM，在 Android 16 以上版本中，Wake Lock 名稱為 GCM_MESSAGE。

建議

建議您採取下列做法，盡量發揮 FCM 的效用：

• 調整 FCM 傳送頻率。
• 除非訊息確實需要立即傳送，否則請勿使用高優先順序 FCM。
• 盡快完成 onMessageReceived() 方法，或排定工作站繼續執行工作 (如需額外處理)。詳情請參閱 Firebase 指南。

JobScheduler

JobScheduler 工作會在背景執行工作時取得 Wake Lock。喚醒鎖定會歸因於建立工作者的應用程式。

Wake Lock 名稱

JobScheduler 取得的喚醒鎖定名稱取決於執行的 Android 系統版本和工作用途。

尖括號括住的項目是變數。舉例來說，「<package_name>」是應用程式套件的名稱，而非實際文字 <package name>。不過，*job* 是 *job* 字元序列，其中包含星號，星號並非做為萬用字元使用。

Android 15 以下版本

使用者啟動的作業會建立 Wake Lock，名稱模式如下：

*job*u/@<name_space>@/<package_name>/<classname>

其他工作會使用這個模式：

*job*/@<name_space>@/<package_name>/<classname>

Android 16 QPR2 以上版本

使用者啟動的作業會建立 Wake Lock，名稱模式如下：

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

加急作業會使用以下模式：

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

一般工作會使用以下模式：

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

範例

假設有名為 backup 的命名空間，以及名為 started 的追蹤標記，且有項加急作業。套件名稱為 com.example.app，而建立工作的類別為 com.backup.BackupFileService。

在搭載 Android 15 以下版本的裝置上，Wake Lock 會命名為：

*job*/@backup@/com.example.app/com.backup.BackupFileService

在搭載 Android 16 QPR2 以上版本的裝置上，Wake Lock 會命名為：

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

建議

• 請勿為使用者啟動的下載/ 上傳用途取得手動 Wake Lock。請改用 User-Initiated Data Transfer (UIDT) API。這是使用者啟動的長時間執行資料移轉工作的指定路徑。
• 如果發現 JobScheduler 建立的 Wake Lock 會大量使用 Wake Lock，可能是因為您設定的工作在特定情況下無法完成。建議您分析工作停止原因，特別是如果 STOP_REASON_TIMEOUT 發生頻率很高。
• 稽核 JobScheduler 工作的使用情形。請特別注意，請按照我們的指南最佳化工作排程 API 的電池用量。

位置

LocationManager 和 FusedLocationProviderClient 會使用喚醒鎖定功能取得及傳送裝置位置資訊。喚醒鎖定會歸因於呼叫這些 API 的應用程式。

Wake Lock 名稱

定位服務會使用下列名稱：

• CollectionLib-SigCollector
• NetworkLocationLocator
• NetworkLocationScanner
• NlpCollectorWakeLock
• NlpWakeLock
• *location*

建議

• 請參閱我們的指南，瞭解如何提升地點使用效益。建議您實作逾時、善用位置資訊要求批次處理，或使用被動位置資訊更新。
• 避免為快取位置資料取得個別的連續 Wake Lock，因為這是多餘的，應移除。使用 FusedLocationProvider 或 LocationManager API 要求位置更新時，系統會在位置事件回呼期間自動觸發裝置喚醒。請改為將位置資訊事件儲存在記憶體或儲存空間中，並使用 WorkManager 定期處理位置資訊事件。

遠端訊息

本節將討論涉及遠端訊息傳送的案例，其中應用程式可能需要維護連線或對來自其他裝置的事件做出反應，進而影響 Wake Lock 使用情形。常見用途包括：

• 需要監控透過區域網路連線的外部裝置上發生的事件的視訊或聲音監控隨附應用程式。
• 與電腦版維持網路插座連線的訊息應用程式。

在這些遠端訊息傳送情境中，大多數喚醒都是核心喚醒鎖定。由於核心 Wake Lock 不會歸因於應用程式，因此這裡不會列出相關的 Wake Lock 名稱。

建議

• 如果網路事件可在伺服器端處理，請使用 FCM 在用戶端接收資訊。如果需要額外處理 FCM 資料，您可以選擇排定加速工作人員。
• 如果必須使用通訊端連線在用戶端處理事件，就不需要 Wake Lock 來監聽事件中斷。當資料封包抵達 Wi-Fi 或行動無線電時，無線電硬體會以核心 Wake Lock 的形式觸發中斷。然後選擇排程 worker 或取得 Wake Lock，以處理資料。
• 舉例來說，如果您使用 ktor-network 監聽網路通訊端上的資料封包，則只有在封包傳送至用戶端時，才應取得 Wake Lock。

WorkManager

WorkManager worker 會在背景執行工作時取得喚醒鎖定。喚醒鎖定會歸因於建立工作者的應用程式。

Wake Lock 名稱

WorkManager 取得的 Wake Lock 名稱取決於執行的 Android 系統版本。

Android 15 以下版本

WorkManager 工作會建立 Wake Lock，名稱遵循下列模式：

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

Android 16 QPR2 以上版本

急件工作會建立名稱符合下列模式的喚醒鎖定：

*job*e/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

一般工作遵循下列模式：

*job*r/#<trace_tag>#/<package_name>/androidx.work.impl.background.systemjob.SystemJobService

預設情況下，<trace_tag> 是工作站名稱。

範例

假設有名為 BackupFileWorker 的快速工作者。套件名稱為 com.example.app。

在搭載 Android 15 以下版本的裝置上，Wake Lock 會命名為：

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

在搭載 Android 16 QPR2 以上版本且使用 WorkManager 2.10.0+ 的裝置上，Wake Lock 會命名為：

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

建議

• 將 WorkManager 版本升級至最新穩定版，即可在 Android 16 QPR2 以上版本中，取得更詳細的 Wake Lock 標記。
• 稽核 WorkManager worker 的使用情形。特別是確認是否遵循工作排程 API 電池用量最佳化指南。如要在 Android 16 QPR2 以上版本中，讓 Wake Lock 標記更詳細，請在 worker 上使用 setTraceTag 方法，加入更多偵錯資訊，例如排定 worker 的類別。
• 如果發現 WorkManager 建立的 Wake Lock 會大量使用 Wake Lock，可能是因為您設定的 worker 有誤，導致 worker 在特定情況下無法完成作業。建議分析工作人員停止工作的原因，特別是如果STOP_REASON_TIMEOUT發生頻率很高。
• 除了記錄工作人員停止工作的原因，請參閱偵錯工作人員的說明文件。此外，您也可以考慮收集及分析系統追蹤記錄，瞭解取得和釋放喚醒鎖定的時間。

_UNKNOWN

如果偵錯工具認為 Wake Lock 名稱含有個人識別資訊 (PII)，就不會顯示實際的 Wake Lock 名稱。而是將 Wake Lock 標示為 _UNKNOWN。舉例來說，如果喚醒鎖定名稱包含電子郵件地址，工具可能會這麼做。

建議

遵循 Wake Lock 命名最佳做法，並避免在 Wake Lock 名稱中使用 PII。如果發現應用程式有 _UNKNOWN 名稱的 Wake Lock，請嘗試找出該 Wake Lock，並改用其他名稱。