ウェイクロックのユースケースを特定して最適化する

このドキュメントでは、アプリでの wake lock のユースケースを特定して最適化する方法と、このユースケースに関連付けられた他のライブラリまたはシステム API によって取得された wake lock があるかどうかを説明します。 これらの wake lock はアプリに起因するため、問題のある wake lock の原因を特定するのは難しい場合があります。 wake lock を明示的に取得していない場合でも、API の誤った使用により、アプリに wake lock の過剰な使用のフラグが設定されることがあります。

このドキュメントでは、 wake lock デバッグツールを使用しているときや、バイタルズのレポートで表示される可能性のある一般的な wake lock 名をいくつか示します。これらの名前は、ライブラリまたはシステム API に由来する場合もあれば、難読化されている場合もあります。デバッグツールを使用して誤動作している wake lock を特定し、このドキュメントで wake lock 名を検索することで、問題の原因となっている可能性がある API を特定し、その使用を最適化する方法に関する推奨事項を確認できます。

このドキュメントでは、wake lock を取得する一般的なユースケースについて説明し、さまざまな API やライブラリで使用される wake lock 名を詳しく解説します。また、wake lock の使用を最適化して削減するための推奨事項とベスト プラクティスも紹介します。

AlarmManager

AlarmManager は wake lock を取得し、呼び出し元の アプリに帰属させます。AlarmManager は、アラームが鳴ったときに wake lock を取得し、アラーム ブロードキャストの onReceive() メソッドの実行が完了するとロックを解除します。

wake lock 名

AlarmManager は、*alarm* という名前の wake lock を作成します。（アスタリスクは wake lock 名の一部であり、ワイルドカードを表すものではありません）。

推奨事項

アラームの動作を最適化するには、次の方法をおすすめします。

音声とメディア

メディア API は、音声の録音または再生時に wake lock を取得できます。 wake lock は、呼び出し元のアプリに帰属します。

wake lock 名

メディア API は、Audio で始まるさまざまな名前の wake lock を取得します。

  • AudioBitPerfect: ロスレス USB オーディオの再生に使用されます。
  • AudioDirectOut: テレビや特殊なデバイスでのロスレス オーディオの再生に使用されます。
  • AudioDup: Bluetooth または USB で接続中に通知を再生するために使用されます。
  • AudioIn: マイクが有効になっているときに、カムコーダー モードで音声のキャプチャに使用されます。
  • AudioMix: 一般的なデバイスへの音声再生に使用されます。
  • AudioOffload: このモードをサポートするアプリで、音楽のみを長時間再生するために使用されます。
  • AudioSpatial: 空間オーディオをサポートするデバイスで、マルチチャンネルの映画や音楽の音声を再生するために使用されます。
  • AudioUnknown: 他の状況に当てはまらない場合に使用されます。
  • MmapCapture: 低レイテンシの音声キャプチャに使用されます。
  • MmapPlayback: ゲームやプロフェッショナル オーディオ アプリケーションなど、低レイテンシの再生に使用されます。

推奨事項

次の方法をおすすめします。

  • Audio で始まる wake lock 名を宣言しないでください。
  • メディア API を使用している場合は、wake lock を直接取得する必要はありません。API が必要な wake lock を取得します。
  • メディア API を使用する場合は、メディア セッションと関連するフォアグラウンド サービスが不要になったら終了します。

Bluetooth

プラットフォームの Bluetooth API は、Bluetooth アクションの発生中に主にカーネル wake lock を保持します。これはアプリケーションに帰属しません。

推奨事項

  • Bluetooth デバイスをペア設定するには、コンパニオン デバイスのペア設定を使用して、 Bluetooth のペア設定中に手動で wake lock を取得しないようにします。
  • バックグラウンドでの Bluetooth 通信を行う方法については、バックグラウンドで通信するのガイダンスを ご覧ください。
  • 通信の遅延がユーザーに影響しない場合は、WorkManager で十分なことがよくあります。手動の wake lock が必要と判断された場合は、Bluetooth アクティビティの期間またはアクティビティ データの処理期間のみ wake lock を保持します。

デバイスのセンサー

歩数、加速度計、ジャイロスコープ データなどのデバイス センサーデータをトラッキングする方法はいくつかあります。

Wear OS では、Wear Health Services を使用して、高度、心拍数、移動距離などのデバイスデータ を取得します。

他のアプリによってデータが収集される場合は、 ヘルスコネクトと WorkManager を組み合わせて使用して、データを定期的に取得できます。

歩数や移動距離の差分をトラッキングするなどのシナリオでは、 モバイルの Recording API と WorkManager を組み合わせて使用して、データを定期的に取得できます。過去の歩数データ （1 日の合計歩数や過去 6 時間の歩数など）にアクセスする場合、ヘルスコネクト は デバイス内歩数トラッキングもサポートしています（ Android 14 以降を搭載したデバイスの場合）。

状況によっては、カスタム デバイス センサー トラッキングが必要になることがあります。 SensorManagerSensorManager は、センサーがウェイクアップ センサーでない限り、アプリの代わりに wake lock を取得しません。 ウェイクアップ センサーは isWakeUpSensor API を使用して識別できます。

推奨事項

センサーを使用して高いサンプリング レートで記録すると、バッテリーの消耗が大幅に増える可能性があります。バッテリーの消耗と wake lock の使用を減らすための推奨事項は次のとおりです。

  • 歩数や移動距離をトラッキングする場合は、 Recording API を使用して、バッテリー効率の良い方法でデータを記録します。 Android 14 以降を搭載したデバイスの場合は、 ヘルスコネクトを使用して、過去のデバイスと 集計された歩数にアクセスすることを検討してください。
  • Wear OS でパッシブ センサー トラッキングを行う場合は、Wear Health Services を使用してバッテリー使用量を最適化します。
  • SensorManager にセンサーを登録する場合は、センサーのバッチ処理ロジックを使用して、アプリが受信する割り込みの数を減らすために、30 秒を超える maxReportLatencyUs を定義します。その後、ユーザー インタラクション、位置情報の取得、スケジュールされたジョブなどの別のトリガーによってデバイスが起動すると、キャッシュに保存されたセンサーデータがすぐにディスパッチされます。
  • アプリで位置情報とセンサーデータの両方が必要な場合は、イベントの取得と処理を同期します。センサーの読み取り値を、位置情報の更新のためにシステムが保持する短い wake lock に統合することで、CPU を起動状態に保つために wake lock を使用する必要がなくなります。この結合されたデータのアップロードと処理には、ワーカーまたは短時間の wake lock を使用します。

Firebase Cloud Message（FCM）

Firebase Cloud Message（FCM）ブロードキャストをアプリに配信する際に、wake lock が取得されます。FCM ブロードキャストの onMessageReceived() メソッドの実行が完了すると、wake lock は解放されます。

wake lock 名

デバイスで FCM メッセージを受信すると、GOOGLE_C2DM という名前の短い wake lock が保持されます。Android 16 以降では、wake lock 名は GCM_MESSAGE です。

推奨事項

FCM の動作を最適化するには、次の方法をおすすめします。

  • FCM の配信頻度を最適化します。
  • メッセージをすぐに配信する必要がある場合を除き、優先度の高い FCM は使用しないでください。
  • onMessageReceived() メソッドをできるだけ早く完了するか、追加の処理が必要な場合はタスクを続行するワーカーをスケジュールします。詳細については、Firebase のガイダンスをご覧ください。

JobScheduler

JobScheduler ジョブは、バックグラウンドでタスクを実行する際に wake lock を取得します。wake lock は、ワーカーを作成したアプリに帰属します。

wake lock 名

JobScheduler によって取得される wake lock 名は、実行されている Android システムのバージョンとジョブの目的によって異なります。

山かっこで囲まれた項目は変数です。たとえば、 「"<package_name>"」はアプリのパッケージ名であり、 リテラル テキスト <package name>ではありません。ただし、*job* はアスタリスクを含む文字シーケンス *job* であり、アスタリスクはワイルドカードとして使用されていません。

Android 15 以前

ユーザーが開始したジョブは、次のパターンに従って名前が付けられた wake lock を作成します。

*job*u/@<name_space>@/<package_name>/<classname>

他のジョブでは、次のパターンを使用します。

*job*/@<name_space>@/<package_name>/<classname>
Android 16 QPR2 以降

ユーザーが開始したジョブは、次のパターンに従って名前が付けられた wake lock を作成します。

*job*u/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

優先ジョブでは、次のパターンを使用します。

*job*e/@<name_space>@/#<trace_tag>#/<package_name>/<classname>

通常のジョブでは、次のパターンを使用します。

*job*r/@<name_space>@/#<trace_tag>#/<package_name>/<classname>
例

Namespace が backup で、トレースタグが started の優先ジョブがあるとします。パッケージ名は com.example.app で、ジョブを作成したクラスは com.backup.BackupFileService です。

Android 15 以前を搭載したデバイスでは、wake lock の名前は次のようになります。

*job*/@backup@/com.example.app/com.backup.BackupFileService

Android 16 QPR2 以降を搭載したデバイスでは、wake lock の名前は次のようになります。

*job*e/@backup@/#started#/com.example.app/com.backup.BackupFileService

推奨事項

ロケーション

LocationManager と FusedLocationProviderClient は wake lock を使用してデバイスの位置情報を取得して配信します。wake lock は、これらの API を呼び出したアプリに帰属します。

wake lock 名

位置情報サービスでは、次の名前が使用されます。

  • CollectionLib-SigCollector
  • NetworkLocationLocator
  • NetworkLocationScanner
  • NlpCollectorWakeLock
  • NlpWakeLock
  • *location*

推奨事項

  • 位置情報の使用を最適化するのガイダンスをご覧ください。タイムアウトの実装、位置情報リクエストのバッチ処理の活用、パッシブな位置情報の更新の利用を検討してください。
  • 位置情報データをキャッシュに保存するために、個別の連続した wake lock を取得しないでください。これは冗長であるため削除する必要があります。 位置情報の更新をリクエストすると、 FusedLocationProvider または LocationManager API を使用して、位置情報イベントのコールバック中にデバイスの起動が自動的に トリガーされます。 代わりに、位置情報イベントをメモリまたはストレージに保存し、WorkManager を使用して位置情報イベントを定期的に処理します。

リモート メッセージ

このセクションでは、アプリが接続を維持したり、他のデバイスからのイベントに応答したりする必要があるリモート メッセージングのシナリオについて説明します。これにより、wake lock の使用に影響する可能性があります。一般的なユースケースには次のものがあります。

  • ローカル ネットワーク経由で接続された外部デバイスで発生するイベントをモニタリングする必要がある、動画または音声モニタリング コンパニオン アプリ。
  • デスクトップ バージョンとのネットワーク ソケット接続を維持するメッセージング アプリ。

これらのリモート メッセージング シナリオでの起動のほとんどは、カーネル wake lock です。カーネル wake lock はアプリに帰属しないため、ここには関連する wake lock 名は記載されていません。

推奨事項

  • ネットワーク イベントをサーバー側で処理できる場合は、FCM を使用してクライアントで情報を受信します。FCM データの追加処理が必要な場合は、 優先ワーカーをスケジュールできます。
  • ソケット接続を使用してクライアント側でイベントを処理する必要がある場合、イベント割り込みをリッスンするために wake lock は必要ありません。 データパケットが Wi-Fi またはモバイル無線に到着すると、無線ハードウェアはカーネル wake lock の形式で割り込みをトリガーします。その後、ワーカーをスケジュールするか、wake lock を取得してデータを処理できます。
  • たとえば、ktor-network を使用してネットワーク ソケットで データパケットをリッスンする場合は、パケットがクライアントに配信されたときにのみ wake lock を取得する必要があります。

WorkManager

WorkManager ワーカーは、バックグラウンドでタスクを実行する際に wake lock を取得します。wake lock は、ワーカーを作成したアプリに帰属します。

wake lock 名

WorkManager によって取得される wake lock 名は、実行されている Android システムのバージョンによって異なります。

Android 15 以前

WorkManager タスクは、次のパターンに従って名前が付けられた wake lock を作成します。

*job*/<package_name>/androidx.work.impl.background.systemjob.SystemJobService
Android 16 QPR2 以降

優先タスクは、次のパターンに従って名前が付けられた wake lock を作成します。

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

通常のタスクは、次のパターンに従います。

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

デフォルトでは、<trace_tag> はワーカー名です。

例

BackupFileWorker という名前の優先ワーカーがあるとします。パッケージ名は com.example.app です。

Android 15 以前を搭載したデバイスでは、wake lock の名前は次のようになります。

*job*/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

Android 16 QPR2 以降を搭載し、WorkManager 2.10.0+ を使用しているデバイスでは、wake lock の名前は次のようになります。

*job*e/#BackupFileWorker#/com.example.app/androidx.work.impl.background.systemjob.SystemJobService

推奨事項

_UNKNOWN

デバッグツールが wake lock 名に個人を特定できる情報（PII）が含まれていると判断した場合、実際の wake lock 名は表示されません。代わりに、wake lock に _UNKNOWN というラベルが付けられます。たとえば、wake lock 名にメールアドレスが含まれている場合、ツールはこれを行います。

推奨事項

wake lock の命名に関するベスト プラクティスに沿って、wake lock 名に PII を使用しないようにします。アプリに帰属する _UNKNOWN という名前の wake lock が見つかった場合は、どの wake lock かを特定して、別の名前を付けます。