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

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

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

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

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

AlarmManager

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

Wake Lock 名稱

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

建議

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

• 請參閱「選擇鬧鐘類型」，決定要使用不精確或精確的鬧鐘。如果鬧鐘不需要精確，請使用不精確的鬧鐘，讓系統在排程方面有更多彈性，進而延長電池續航力。
• 請注意系統設定的鬧鐘配額，並設計應用程式來遵守配額。
• 避免在 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 主要會在發生藍牙動作時保留核心喚醒鎖定，這不屬於應用程式。

建議

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

裝置感應器

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

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

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

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

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

建議

使用感應器以高取樣率記錄資料可能會大幅耗電，建議採取下列措施，減少耗電量和喚醒鎖定用量：

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

Firebase 雲端通訊 (FCM)

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

Wake Lock 名稱

裝置收到 FCM 訊息時，系統會保留名為 GOOGLE_C2DM 的短暫 Wake Lock，在 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 以下版本

使用者啟動的作業會建立喚醒鎖定，名稱遵循下列模式：

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

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

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

Android 16.1 以上版本

使用者啟動的作業會建立喚醒鎖定，名稱模式如下：

*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 以下版本的裝置上，喚醒鎖定會命名為：

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

在搭載 Android 16.1 以上版本的裝置上，喚醒鎖定會命名為：

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

建議

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

位置

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

Wake Lock 名稱

定位服務使用下列名稱：

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

建議

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

遠端通訊

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

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

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

建議

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

WorkManager

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

Wake Lock 名稱

WorkManager 取得的喚醒鎖定名稱取決於執行的 Android 系統版本。

Android 15 以下版本

WorkManager 工作會建立喚醒鎖定，名稱遵循下列模式：

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

Android 16.1 以上版本

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

*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 以下版本的裝置上，喚醒鎖定會命名為：

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

在搭載 Android 16 以上版本且使用 WorkManager 2.10.0+ 的裝置上，喚醒鎖定會命名為：

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

建議

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

_UNKNOWN

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

建議

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