ウェアラブル向けの 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 回限りのスケジュールと定期的なスケジュールの両方を使用しています。これにより、アプリは同じ成功基準を持つ同一のタスクに同じ Worker ロジックを再利用できます。タイミングのみが異なります。

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

この追加情報により、過度の部分的な wake lock を使用するセッションに最も貢献している Worker のバリエーション（定期的なものか 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 は Worker の変更を実装してから 30 日後に、過度の部分的な wake lock の割合が 15% から 1%未満に減少 しました。 

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

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

使ってみる

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