電池續航力是使用者體驗的關鍵，而喚醒鎖扮演重要角色。你是否過度使用這些功能？在這篇網誌文章中，我們將探討喚醒鎖定是什麼、使用喚醒鎖定的最佳做法，以及如何運用 Play 管理中心指標，進一步瞭解自家應用程式的行為。

Android Vitals 中部分 Wake Lock 使用過度

Play 管理中心現在會監控電池耗電情形，並以「過度使用部分 Wake Lock」做為主要成效指標。

這項功能會將電池效率的重要性提升至與現有核心指標穩定性指標相同的地位，也就是使用者感知的當機和 ANR 發生率過高。我們已定義 Wake Lock 使用過度的不良行為門檻。自 2026 年 3 月 1 日起，如果你的影視內容不符合這項品質門檻，我們可能會將其排除在推薦等顯眼探索介面之外。在某些情況下，我們可能會在商店資訊中顯示警告訊息，向使用者指出應用程式可能會耗用過多電量。

Android Vitals 總覽中的 Wake Lock 過多警告。

在行動裝置上，Android Vitals 指標適用於螢幕關閉時取得的非豁免 Wake Lock，且應用程式處於背景或執行前景服務。如果發生下列情況，Android Vitals 會將部分 Wake Lock 使用量視為過高：

• 在 24 小時內，喚醒鎖定至少會保留兩小時。
• 在過去 28 天內，平均有超過 5% 的應用程式工作階段受到影響。

由音訊、位置資訊和 JobScheduler 使用者啟動的 API 建立的喚醒鎖定，不會納入喚醒鎖定計算。

瞭解 Wake Lock

Wake Lock 是一種機制，可讓應用程式在使用者未主動與裝置互動時，仍保持裝置 CPU 運作。

部分 Wake Lock 可讓 CPU 在螢幕關閉時繼續運作，避免 CPU 進入低耗電的「暫停」狀態。完整 Wake Lock 可讓螢幕和 CPU 保持運作。

取得部分 Wake Lock 的方法有 2 種：

• 應用程式會針對特定用途，使用 PowerManager API 手動取得及釋放 Wake Lock，通常會與 Foreground Service (適用於使用者可察覺作業的平台生命週期 API) 一併取得。
• 或者，Wake Lock 是由其他 API 取得，並因使用該 API 而歸因於應用程式，詳情請參閱最佳做法一節。

雖然完成使用者啟動的大型檔案下載等工作時，必須使用喚醒鎖定，但過度或不當使用可能會導致電池電量大幅消耗。我們發現有些應用程式會持有喚醒鎖定數小時，或無法正確釋放喚醒鎖定，導致使用者即使未與應用程式互動，仍會抱怨電池電量大幅耗盡。

使用喚醒鎖定的最佳做法

說明如何偵錯過度使用喚醒鎖定的問題前，請先確認您遵循喚醒鎖定的最佳做法。

請思考以下四個重要問題。

1. 您是否考慮過其他 Wake Lock 選項？

考慮取得手動部分 Wake Lock 前，請先按照下列決策流程圖操作：

流程圖：決定何時手動取得 Wake Lock

1. 螢幕需要保持開啟嗎？
   • 是：請改為參閱「保持螢幕開啟」說明文件
2. 應用程式是否正在執行前景服務？
   • 否：您不需要手動取得喚醒鎖定。
3. 裝置暫停是否會損害使用者體驗？
   • 否：舉例來說，在裝置喚醒後更新通知不需要 Wake Lock。
   • 是：如果必須防止裝置暫停運作 (例如與外部裝置持續通訊)，請繼續操作。
4. 是否有 API 代表您讓裝置保持喚醒狀態？
   • 您可以參考「識別其他 API 建立的喚醒鎖定」文件，找出其他 API (例如 LocationManager) 建立喚醒鎖定的情況。
   • 如果沒有任何 API，請繼續回答最後一個問題。
5. 如果您已回答所有這些問題，並確定沒有替代方案，則應繼續手動取得 Wake Lock。

2. 您是否正確命名 Wake Lock？

手動取得喚醒鎖定時，適當的命名對於偵錯非常重要：

• 請勿在名稱裡面填寫個人識別資訊 (PII)，例如電子郵件地址等。如果偵測到 PII，Wake Lock 會記錄為 _UNKNOWN，妨礙偵錯。
• 請勿使用類別或方法名稱，以程式輔助方式命名 Wake Lock，因為這類名稱可能會遭到 Proguard 等工具模糊處理。請改用硬式編碼字串。
• 請勿在 Wake Lock 標記裡加上計數器或專用 ID，每次執行 Wake Lock 時，都應使用相同的標記，讓系統依名稱匯總用量，方便偵測異常行為。

3. 取得的喚醒鎖是否一律會釋出？

如果手動取得 Wake Lock，請務必執行 Wake Lock 發布作業。如果沒有釋放 Wake Lock，可能會大幅消耗電池耗電。

舉例來說，如果在 processingWork() 期間擲回未擷取的例外狀況，可能就永遠不會發生 release() 呼叫。您可以改用 try-finally 區塊，確保即使發生例外狀況，Wake Lock 仍會釋放。

此外，您也可以為 Wake Lock 新增逾時時間，確保 Wake Lock 會在特定時間後釋出，避免無限期保留。

fun processingWork() {
    wakeLock.apply {
        try {
            acquire(60 * 10 * 1000) // timeout after 10 minutes
            doTheWork()
        } finally {
            release()
        }
    }
}

4. 可以降低喚醒頻率嗎？

如果是定期資料要求，減少應用程式喚醒裝置的頻率是電池效能最佳化的關鍵。以下列舉幾種減少喚醒頻率的方法：

• WorkManager：增加 PeriodicWorkRequest 的週期性間隔。
• SensorManager：註冊監聽器時指定 maxReportLatencyMs，即可運用批次處理功能。
• 整合式位置預測提供工具：
  • 使用 getLastLocation 取得最近快取的位置資訊，減少位置資訊的擷取頻率。
  • 使用 setPriority(PRIORITY_PASSIVE) 採用較不耗電的更新方法。
  • 此外，您也可以使用 setMinUpdateIntervalMillis 設定最短更新間隔，善用位置資訊批次處理機制。

詳情請參閱Wake Lock 最佳做法說明文件。

偵錯 Wake Lock 使用過度問題

即使是出於好意，也可能過度使用 Wake Lock。如果應用程式在 Play 管理中心遭到標記，請按照下列步驟進行偵錯：

透過 Play 管理中心進行初步識別

Android Vitals 的「部分 Wake Lock 停滯過久」資訊主頁會列出與應用程式相關聯的非豁免 Wake Lock 名稱，並顯示受影響的會話和時間長度。提醒您使用說明文件，判斷 Wake Lock 名稱是由應用程式持有，還是由其他 API 持有。

Android Vitals 的「部分 Wake Lock 使用過度」資訊主頁向下捲動至「細目」部分，即可查看 Wake Lock 使用過度標記。

偵錯工作人員/工作持有的過多 Wake Lock

您可以使用下列 Wake Lock 名稱，識別工作人員持有的 Wake Lock：

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

如需工作人員持有的 Wake Lock 名稱完整清單，請參閱說明文件。如要對這些喚醒鎖定進行偵錯，您可以使用背景工作檢查器在本機偵錯，或利用 getStopReason 在現場偵錯問題。

Android Studio 背景工作檢查器

背景工作檢查器的螢幕截圖，顯示系統已找出經常重試但失敗的工作者「WeatherSyncWorker」。

如要對 WorkManager 問題進行本機偵錯，請在模擬器或連結裝置 (API 級別 26 以上) 上使用這項工具。這項工具會顯示 worker 清單及其狀態 (已完成、執行中、已加入佇列)，方便您檢查詳細資料及瞭解 worker 鏈結。

舉例來說，如果工作者因達到系統限制而經常失敗或重試，這項指標就會顯示。

詳情請參閱「背景工作檢查器說明文件」。

WorkManager getStopReason

如要針對喚醒鎖過多的工作站進行現場偵錯，請在 WorkManager 2.9.0 以上版本中使用 WorkInfo.getStopReason()，或在 SDK 31 以上版本中使用 JobScheduler 的 JobParameters.getStopReason()。

這個 API 可協助記錄工作者停止的原因 (例如 STOP_REASON_TIMEOUT、STOP_REASON_QUOTA)，找出因執行階段時間用盡而頻繁逾時等問題。

backgroundScope.launch {
    WorkManager.getInstance(context)
        .getWorkInfoByIdFlow(workRequest.id)
        .collect { workInfo ->
            logStopReason(workRequest.id, workInfo?.stopReason)
        }
}

詳情請參閱「針對工作排程 API 最佳化電池用量」。

偵錯其他類型的過度喚醒鎖定

如果情境較複雜，例如手動保留 Wake Lock 或 API 保留 Wake Lock，建議您使用系統追蹤收集功能進行偵錯。

收集系統追蹤記錄

系統追蹤 是功能強大的偵錯工具，可擷取一段時間內的系統活動詳細記錄，深入瞭解 CPU 狀態、執行緒活動、網路活動，以及與電池相關的指標，例如工作持續時間和 Wake Lock 用量。

您可以透過多種方式擷取系統追蹤記錄：

• 使用系統追蹤指令列工具
• 使用 Android Studio CPU 分析器
• 使用 Perfetto UI
• 在裝置上直接透過開發人員選項手動記錄追蹤記錄。

在 Perfetto UI 的「Android apps & svcs」分頁中，啟用「power:PowerManagement」Atrace 類別。 

無論選擇哪種方法，請務必收集 「power:PowerManagement」Atrace 類別，以便查看裝置狀態軌跡。

Perfetto UI 檢查和 SQL 分析

您可以在 Perfetto UI 中開啟及檢查系統追蹤記錄。開啟追蹤記錄後，您會看到時間軸上各種程序的視覺化呈現。本指南將著重於「裝置狀態」下的軌跡。

在「裝置狀態」下方釘選「頂端應用程式」、「螢幕狀態」、「長時間 Wake Lock」和「工作」等軌跡，以便從視覺上找出長時間執行的 Wake Lock 切片。

每個區塊都會列出活動名稱、開始時間和結束時間。在 Perfetto 中，這稱為「切片」。

如要大規模分析多個追蹤記錄，可以使用 Perfetto 的 SQL 分析。SQL 查詢可以找出所有依時間長度排序的喚醒鎖定，協助找出過度耗用資源的主要原因。

以下是查詢範例，會加總系統追蹤記錄中發生的所有 Wake Lock 標記，並依總時間長度排序：

SELECT slice.name as name, track.name as track_name,SUM(dur / 100000) as total_dur_ms
FROM slice
JOIN track ON slice.track_id = track.id
WHERE track.name = 'WakeLocks'GROUP BY slice.name, track.name
ORDER BY total_dur_ms DESC

使用 ProfilingManager 收集現場追蹤記錄

對於難以重現的問題，開發人員可使用 ProfilingManager (SDK 35 新增功能) 這個程式輔助 API，透過開始和結束觸發條件，在現場收集系統追蹤記錄。這項功能可讓您進一步控管設定檔收集作業的開始和結束觸發點，並強制執行系統層級的頻率限制，避免影響裝置效能。

如要進一步瞭解如何實作現場系統追蹤收集作業，包括如何以程式輔助方式擷取追蹤記錄、分析剖析資料，以及使用本機偵錯指令，請參閱 ProfilingManager 說明文件。

使用 ProfilingManager 收集的系統追蹤記錄與手動收集的記錄類似，但系統程序和其他應用程式程序會從追蹤記錄中遮蓋。

結論

Android Vitals 中的「部分 Wake Lock 使用過度」指標，只是我們持續協助開發人員減少電池耗電和提升應用程式品質的一小部分。

瞭解並正確實作 Wake Lock，有助於大幅提升應用程式的電池效能。善用替代 API、遵循 Wake Lock 的最佳做法，以及使用強大的偵錯工具 (例如「背景工作檢查器」、系統追蹤和 ProfilingManager)，是確保應用程式在 Google Play 上獲得成功的關鍵。