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

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

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

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

• AlarmManager
• オーディオとメディア
• Bluetooth
• デバイス センサー
• Firebase Cloud Message（FCM）
• JobScheduler
• ロケーション
• リモート メッセージ
• WorkManager
• _UNKNOWN: wake lock 名に個人を特定できる情報（PII）が使用されていると思われる場合に、デバッグツールによって表示されます。

AlarmManager

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

wake lock の名前

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

推奨事項

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

• 不正確なアラームと正確なアラームのどちらを使用するかを決定するには、アラームタイプを選択するをご覧ください。アラームを正確にする必要がない場合は、不正確なアラームを使用して、システムがより柔軟にスケジュールを設定できるようにします。これにより、バッテリー駆動時間を改善できます。
• システムによって課されるアラームの割り当てを認識し、それを遵守するようにアプリを設計します。
• onReceive() メソッドで時間のかかる処理を行わないようにし、アラームの後に追加の処理が必要な場合はワーカーをスケジュールします。

オーディオとメディア

メディア 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 ヘルスサービスを使用して、標高、心拍数、移動距離などのデバイスデータを取得します。

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

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

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

推奨事項

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

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

Firebase Cloud Messaging（FCM）

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

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>

例

名前空間が 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

推奨事項

• ユーザーが開始したダウンロード/ アップロードのユースケースでは、手動で wake lock を取得しないでください。代わりに、ユーザーが開始したデータ転送（UIDT） API を使用します。これは、ユーザーが開始する長時間実行データ転送タスク用に指定されたパスです。
• JobScheduler によって作成された wake lock の使用率が高い場合は、特定のシナリオでジョブが完了しないようにジョブが誤って構成されている可能性があります。特に STOP_REASON_TIMEOUT の発生頻度が高い場合は、ジョブの停止理由を分析することを検討してください。
• JobScheduler タスクの使用状況を監査します。特に、タスク スケジューリング API のバッテリー使用量を最適化するためのガイダンスに沿って対応してください。

ロケーション

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

wake lock の名前

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

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

推奨事項

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

リモート メッセージ

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

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

これらのリモート メッセージング シナリオでのほとんどの wake は、カーネル 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

推奨事項

• WorkManager のバージョンを最新の安定版にアップグレードして、Android 16 QPR2 以降で wake lock タグをより詳細に表示できるようにします。
• WorkManager ワーカーの使用状況を監査します。特に、タスク スケジューリング API のバッテリー使用量の最適化に関するガイダンスに沿っていることを確認します。Android 16 QPR2 以降で wake lock タグをより詳細にするには、ワーカーで setTraceTag メソッドを使用して、ワーカーをスケジュールしたクラスなどのデバッグ情報を追加します。
• WorkManager によって作成された wake lock の使用率が高い場合は、特定のシナリオでワーカーが完了しないように誤って構成されている可能性があります。特に STOP_REASON_TIMEOUT の発生頻度が高い場合は、ワーカーの停止理由を分析することを検討してください。
• ワーカーの停止理由のロギングに加えて、ワーカーのデバッグに関するドキュメントをご覧ください。また、システム トレースを収集して分析し、wake lock が取得および解放されるタイミングを把握することも検討してください。

_UNKNOWN

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

推奨事項

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