WHOOP が過度の部分的な wake lock セッションを 90% 以上削減した方法

ウェアラブル向けの Android アプリを構築する場合、実際の作業は画面がオフになったときに始まります。WHOOP は、トレーニング、リカバリー、睡眠、ストレスに対する体の反応を把握するのに役立ちます。Android を使用している多くの WHOOP メンバーにとって、信頼性の高いバックグラウンドでの同期と接続が、こうした分析を可能にしています。

今年初め、Google Play はAndroid Vitals に新しい指標「過度の部分的な wake lock」をリリースしました。この指標は、24 時間以内に累積で 2 時間を超える、免除されていない wake lock の使用があったユーザー セッションの割合を測定します。この指標の目的は、バッテリー消耗の原因を特定して対処するのに役立つことです。これは、優れたユーザー エクスペリエンスを提供するために不可欠です。

2026 年 3 月 1 日以降、品質のしきい値を満たしていないアプリは、Google Play の検出面から除外される可能性があります。また、Google Play ストアの掲載情報に警告が表示され、アプリが想定よりも多くのバッテリーを使用する可能性があることが示される場合があります。

WHOOP のシニア Android エンジニアである Mayank Saini 氏によると、Android Vitals がアプリの過度の部分的な wake lock の割合を 15%（推奨される 5% のしきい値を超過）と報告したことで、「チームは Android の効率性を高める機会を得ました」。

チームは、Android Vitals の指標を、バックグラウンド処理によって CPU が必要以上に長く起動していることを示す明確なシグナルと捉えました。この問題を解決することで、優れたユーザー エクスペリエンスを提供し続けるとともに、バックグラウンドでの無駄な時間を減らし、信頼性の高いタイムリーな Bluetooth 接続と同期を維持できるようになります。

問題の特定

チームは、まず Android Vitals を使用して、どの wake lock が指標に影響しているかについての分析情報を取得しました。Android Vitals の過度の部分的な wake lock ダッシュボードを確認したところ、過度の部分的な wake lock の最大の原因は、WorkManager ワーカーの 1 つ（ダッシュボードでは androidx.work.impl.background.systemjob.SystemJobService として識別）であることがわかりました。WHOOP の「常時オン エクスペリエンス」をサポートするため、アプリは WorkManager を使用して、定期的な同期やウェアラブルへの定期的な更新の配信などのバックグラウンド タスクを実行しています。

チームは、WorkManager がバックグラウンドでタスクを実行する際に wake lock を取得することを認識していましたが、Android Vitals に過度の部分的な wake lock の指標が導入されるまで、WorkManager 以外のすべてのバックグラウンド処理がどのように分散されているかを把握できませんでした。

ダッシュボードで WorkManager が主な原因であることが特定されたため、チームはどのワーカーが最も影響しているかを特定し、問題の解決に取り組むことができました。

内部の指標とデータを使用して原因を絞り込む

WHOOP は、WorkManager の指標をモニタリングするための内部インフラストラクチャをすでに設定していました。定期的にモニタリングしている項目は次のとおりです。

1. 平均実行時間: ワーカーの実行時間。
2. タイムアウト: ワーカーが完了せずにタイムアウトする頻度。
3. 再試行: 処理がタイムアウトまたは失敗した場合に、ワーカーが再試行する頻度。
4. キャンセル: 処理がキャンセルされた頻度。

ワーカーの成功と失敗だけでなく、さまざまな項目をトラッキングすることで、チームは処理の効率性を把握できます。

内部の指標では、一部のワーカーで平均実行時間が長い ことが示されたため、調査範囲をさらに絞り込むことができました。

内部の指標に加えて、チームはAndroid Studio のBackground Task Inspector を使用して、対象のワーカーを検査してデバッグしました。Android Vitals で報告された指標に合わせて、関連する wake lock に特に重点を置きました。

調査: ワーカーのバリエーションの区別

WHOOP では、一部のワーカーに 1 回限り のスケジューリングと 定期的な スケジューリングの両方を使用しています。これにより、アプリは同じ成功基準を持つ同一のタスクに同じワーカー ロジックを再利用できます。タイミングのみが異なります。

内部の指標を使用することで、検索範囲を特定のワーカーに絞り込むことができましたが、バグが 1 回限り、定期的、またはその両方のワーカーで発生しているかどうかはわかりませんでした。そこで、WorkManager の setTraceTag メソッド を使用して、同じワーカーの 1 回限りと定期的なバリエーションを区別するアップデートをリリースしました。

この追加情報により、過度の部分的な wake lock が発生しているセッションに最も影響しているワーカーのバリエーション（定期的または 1 回限り）を明確に特定できるようになりました。しかし、データから、どちらのバリエーションも他方よりも影響が大きいとは言えないことが判明し、チームは驚きました。

WHOOP の Android エンジニア II である Manmeet Tuteja 氏は、「この分割により、問題が両方のバリエーションで発生していることを確認できました。これにより、スケジューリング構成ではなく、ワーカー実装内の共有ビジネス ロジックの問題に焦点を当てることができました」と述べています。

ワーカーの動作を詳しく調べ、根本原因を修正する

ワーカー内のロジックを確認する必要があることがわかったため、チームは調査中にフラグが設定されたワーカーの動作を再確認しました。具体的には、処理が停止して完了していないインスタンスを探しました。

その結果、過度の wake lock の根本原因が判明しました。

処理を進める前に WHOOP センサーへの接続を待機するように設計された CoroutineWorker。 

センサーが接続されていない状態で処理が開始された場合、センサーが接続されているかどうかを示す whoopSensorFlow は null でした。SensorWorker はこれを早期終了条件として扱わず、実行を続け、接続を無期限に待機していました。その結果、WorkManager は処理がタイムアウトするまで部分的な wake lock を保持し、バックグラウンドでの wake lock の使用量が増加し、SensorWorker の不要な再スケジューリングが頻繁に発生していました。

この問題を解決するため、WHOOP チームは、コアビジネス ロジックの実行を試みる前に接続ステータスを確認するようにワーカー ロジックを更新しました。

センサーが使用できない場合、ワーカーは終了し、タイムアウト シナリオを回避して 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 はワーカーに変更を実装してから 30 日後に、過度の部分的な wake lock の割合が 15% から 1%未満に減少 しました。 

変更の結果、処理が完了せずにタイムアウトするインスタンスが減少し、平均実行時間が短縮されました。

バックグラウンド処理の効率性を向上させたい他のデベロッパーへの WHOOP チームからのアドバイスは次のとおりです。

使ってみる

アプリの過度の部分的な wake lock を減らしたり、ワーカーの効率性を向上させたりする場合は、Android Vitals でアプリの過度の部分的な wake lock の指標を確認し、wake lock のドキュメントでベスト プラクティスとデバッグ戦略をご確認ください。