為穿戴式裝置建構 Android 應用程式時，螢幕關閉後才是真正的工作開始。WHOOP 可協助會員瞭解身體對訓練、恢復、睡眠和壓力的反應，而對於許多使用 Android 的 WHOOP 會員來說，可靠的背景同步和連線能力是提供這些深入分析資訊的關鍵。

今年稍早，Google Play 在 Android Vitals 中推出一項新指標：部分 Wake Lock 使用過度。這項指標會測量使用者工作階段的百分比，其中累積的非豁免 Wake Lock 用量在 24 小時內超過 2 小時。這項指標的目的是協助您找出並解決可能導致電池耗電的原因，這對提供優質使用者體驗至關重要。

自 2026 年 3 月 1 日起，如果應用程式仍未達到品質門檻，可能會從 Google Play 探索介面中排除。Google Play 商店資訊也可能會顯示警告，指出應用程式的耗電量可能超出預期。

WHOOP 的資深 Android 工程師 Mayank Saini 表示，Android Vitals 標記出應用程式的部分 Wake Lock 比例過高 (15%)，超過建議的 5% 門檻，這「讓團隊有機會提高 Android 效率」。

團隊將 Android Vitals 指標視為明確信號，指出背景工作讓 CPU 保持喚醒狀態的時間過長。解決這個問題後，他們就能繼續提供絕佳的使用者體驗，同時減少浪費的背景時間，並維持可靠及時的藍牙連線和同步。

找出問題

為瞭解從何著手，團隊首先查看 Android Vitals，深入瞭解哪些喚醒鎖定會影響指標。他們參考 Android Vitals 資訊主頁的「部分 Wake Lock 停滯次數過多」部分，發現其中一個 WorkManager 工作項目 (在資訊主頁中標示為 androidx.work.impl.background.systemjob.SystemJobService) 是造成部分 Wake Lock 停滯次數過多的主要原因。為了支援 WHOOP 的「永遠開啟體驗」，應用程式會使用 WorkManager 執行背景工作，例如定期同步處理資料，以及將週期性更新傳送至穿戴式裝置。

雖然團隊知道 WorkManager 會在背景執行工作時取得 Wake Lock，但直到 Android Vitals 推出「部分 Wake Lock 停滯次數過多」指標，他們才瞭解所有背景工作 (不只是 WorkManager) 的分配情形。

資訊主頁指出 WorkManager 是主要原因後，團隊就能專心找出哪個工作者貢獻最多，並致力於解決問題。

運用內部指標和資料，進一步縮小原因範圍

WHOOP 內部已設有基礎架構，可監控 WorkManager 指標。他們會定期監控下列項目：

1. 平均執行時間：工作站執行時間有多長？
2. 逾時：工作站逾時的頻率有多高 (而非完成工作)？
3. 重試次數：如果工作逾時或失敗，worker 會重試幾次？
4. 取消次數：工作取消的頻率為何？

除了追蹤工作人員的成功和失敗次數，團隊也能掌握工作效率。

內部指標為少數工作人員標示高平均執行時間，讓他們進一步縮小調查範圍。

除了內部指標外，團隊也使用 Android Studio 的背景工作檢查器檢查並偵錯感興趣的 worker，特別是相關聯的喚醒鎖定，以符合 Android Vitals 中標記的指標。

調查：區分工作人員變體

WHOOP 會為部分工作者使用一次性和週期性排程。這樣一來，應用程式就能針對成功條件相同但時間不同的相同工作，重複使用相同的 Worker 邏輯。

他們可以根據內部指標將搜尋範圍縮小至特定工作人員，但無法判斷錯誤是發生在工作人員一次性工作時、定期工作時，還是兩者皆是。因此，他們推出更新，使用 WorkManager 的 setTraceTag 方法，區分相同 Worker 的一次性和週期性變體。

有了這項額外詳細資料，他們就能明確判斷哪個 Worker 變體 (定期或一次性) 最常導致工作階段出現過多的部分喚醒鎖定。不過，資料顯示這兩種變數的貢獻度似乎不相上下，這讓團隊感到意外。

WHOOP 的 Android 工程師 II Manmeet Tuteja 表示：「我們也透過這個分割作業確認問題發生在兩個變體中，這表示問題與排程設定無關，而是工作人員實作中的共用商業邏輯問題。」

深入瞭解工作人員行為並修正根本原因

得知需要查看工作站內的邏輯後，團隊重新檢查調查期間標記的工作站行為。具體來說，他們要找出工作可能停滯不前且無法完成的案例。

最後，我們找出了 Wake Lock 使用過度的根本原因：

CoroutineWorker，用於等待連線至 WHOOP 感應器，然後再繼續作業。 

如果工作開始時未連線感應器，whoopSensorFlow (表示感應器是否已連線) 會顯示為 null。SensorWorker並未將此視為提早結束條件，而是持續執行，因此會無限期等待連線。因此，WorkManager 會持有部分 Wake Lock，直到工作逾時為止，導致背景 Wake Lock 使用率偏高，且 SensorWorker 經常遭到不必要的重新排程。

為解決這個問題，WHOOP 團隊更新了 worker 邏輯，在嘗試執行核心商業邏輯前，先檢查連線狀態。

如果感應器無法使用，worker 就會結束，避免發生逾時情況並釋放 Wake Lock。解決方案如下列程式碼片段所示：

  class SensorWorker(appContext: Context, params: WorkerParameters): CoroutineWorker(appContext, params) {
   override suspend fun doWork(): Result {
      ...
      // Check the sensor state and perform work or return failure
       return whoopSensorFlow.replayCache
            .firstOrNull()
            ?.let { cachedData ->
                processSensorData(cachedData)
                Result.success()
            } ?: run {
                Result.failure()
            }
}

將部分 Wake Lock 使用過度的工作階段減少 90%

推出修正程式後，團隊持續監控 Android Vitals 資訊主頁，確認變更的影響。

最終，WHOOP 在實作 Worker 變更後，過多的部分 Wake Lock 百分比在短短 30 天內，就從 15% 降至不到 1%。

變更後，團隊發現工作逾時但未完成的情況減少，平均執行時間也因此縮短。

WHOOP 團隊為其他想提升背景工作效率的開發人員提供以下建議：

立即開始

如要減少應用程式過多的部分 Wake Lock，或提高工作人員效率，請在 Android Vitals 中查看應用程式過多的部分 Wake Lock 指標，並參閱 Wake Lock 說明文件，瞭解更多最佳做法和偵錯策略。