使用 Android Vitals Wake Lock 指標，最佳化應用程式電池用量

電池續航力是使用者體驗的重要一環，而 Wake Lock 扮演著重要角色。是否過度使用？在這篇網誌文章中，我們將探討 Wake Lock 的定義、使用 Wake Lock 的最佳做法，以及如何透過 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 小時內，Wake Lock 至少保留兩小時。
• 28 天平均下來，影響超過 5% 的應用程式工作階段。

由音訊、位置和 JobScheduler 使用者啟動 API 建立的 Wake Lock 不會計入 Wake Lock 計算。

瞭解 Wake Lock

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

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

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

• 應用程式會使用 PowerManager API，針對特定用途手動取得及釋放 Wake Lock，通常會與前景服務搭配使用。前景服務是平台生命週期 API，用於使用者可感知的作業。
• 或者，Wake Lock 是由其他 API 取得，並因使用 API 而歸因於應用程式，詳情請參閱「最佳做法」一節。

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

Wake Lock 使用最佳做法

在說明如何偵錯 Wake Lock 使用過度的問題之前，請先確認您遵循 Wake Lock 最佳做法。

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

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

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

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

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

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

手動取得 Wake Lock 時，正確命名對於偵錯非常重要：

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

3. 取得的 Wake Lock 是否一律會釋出？

如果您手動取得 Wake Lock，請確保 Wake Lock 釋放作業一律會執行。如果未釋放 Wake Lock，可能會導致電池電量大幅消耗。

舉例來說，如果在 processingWork() 期間擲回未偵測到的例外狀況，可能就不會發生 release() 呼叫。建議改用 try-finally 區塊，確保即使發生例外狀況，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 的標記。

對 worker/工作保留過多 Wake Lock 的問題進行偵錯

您可以使用下列 Wake Lock 名稱，找出 worker 持有的 Wake Lock：

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

如需 worker 持有的 Wake Lock 名稱完整變化版本清單，請參閱說明文件。如要對這些 Wake Lock 進行偵錯，您可以使用背景工作檢查器在本機偵錯，或利用 getStopReason 對實際環境中的問題進行偵錯。

Android Studio 背景工作檢查器

背景工作檢查器的螢幕擷取畫面，其中已識別出經常重試且失敗的工作站「WeatherSyncWorker」。

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

舉例來說，如果 worker 因達到系統限制而經常失敗或重試，這項指標就會顯示相關資訊。

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

WorkManager getStopReason

如要對 Wake Lock 過多的 worker 進行現場偵錯，請在 WorkManager 2.9.0 以上版本使用 WorkInfo.getStopReason()，或在 SDK 31 以上版本使用 JobScheduler 的 JobParameters.getStopReason()。

這個 API 可協助記錄 worker 停止的原因 (例如 STOP_REASON_TIMEOUT、STOP_REASON_QUOTA)，找出執行階段耗盡導致經常逾時等問題。

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

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

對其他類型的 Wake Lock 使用過度問題進行偵錯

如果涉及手動保留 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 中開啟及檢查系統追蹤記錄。開啟追蹤記錄後，您會在時間軸上看到各種程序的視覺化呈現。本指南將著重在「裝置狀態」下的測試群。

固定「Device State」下方的「Top app」、「Screen state」、「Long Wake locks」和「Jobs」等追蹤記錄，以視覺化方式找出長時間執行的 Wake Lock 切片。

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

如要對多個追蹤記錄進行可擴充分析，可以使用 Perfetto 的 SQL 分析。SQL 查詢可找出所有 Wake Lock，並依持續時間排序，協助找出過度使用的主要原因。

以下查詢範例會加總系統追蹤記錄中出現的所有 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，就能大幅提升應用程式的電池效能。如要確保應用程式在 Google Play 取得成功，關鍵在於採用替代 API、遵循 Wake Lock 最佳做法，以及使用背景工作檢查器、系統追蹤和 ProfilingManager 等強大的偵錯工具。