バッテリーとバッテリーを節約する

Wear OS では電力効率が特に重要です。Wear OS の設計原則では、デバイスの電力使用量に重点を置いています。スマートウォッチは小さなフォーム ファクタであり、短時間の操作を対象としているためです。

Wear OS デバイスは大型のモバイル デバイスに比べてバッテリーが小さいため、バッテリーの消耗が顕著になります。また、Wear OS デバイスを充電する場合、モバイル デバイスに比べてユーザーの手間がかかります。ユーザーは 1 日を通してさまざまな間隔でモバイル デバイスを充電できますが、デバイスを充電する前に Wear OS デバイスを身体から取り外す必要があります。

アプリの電力効率を向上させるには、次の設計上のベスト プラクティスに従ってください。

  • アプリのデザインでは Wear OS のフォーム ファクタを最大限に活用する必要があります。モバイルアプリを直接コピーしないでください。
  • 既存のモバイルアプリを特定のユースケースに使用できます。たとえば、スマートウォッチでのインターネットと同期にはコストがかかります。モバイル デバイスが手間のかかる処理を実行でき、Wear OS デバイスがデータの変更を受信できるかどうかを検討してください。
  • やり取りが短いユースケースを設計します。
  • どの Wear OS イベントを使用するか、そのイベントが発生する頻度を検討してください。

  • 可能な限り、スマートウォッチが充電中になるまでアプリの処理を先送りします。これは、データの同期やデータベースの整理など、大量のデータを使用するタスクに特に当てはまります。

    デバイスが充電中で、Wi-Fi 接続がある場合は、ユーザーがアプリで見たいデータ、画像、更新をプリフェッチするジョブをスケジュールします。

この電源ガイドでは、システムがアプリを実行するタイミングと方法、アプリの実行時間とバッテリーの消耗を制限する方法について説明します。アプリの読み込みやリストのスクロールなど、特定のアクションの実行方法について詳しくは、パフォーマンスに関連するガイダンス（Wear OS 版 Compose のパフォーマンス ガイドなど）をご覧ください。

バッテリー使用量の推移をモニタリングする

アプリを実行する Wear OS デバイスのバッテリー統計情報を分析するには、開発マシンのターミナル ウィンドウで次のコマンドを入力します。

adb shell dumpsys batterystats

GitHub のライブラリにはバッテリー統計情報パーサーが用意されており、このコマンドと一緒に実行すると便利です。

バッテリー駆動時間に影響するイベント

特にアプリについて検討する前に、Wear OS デバイスの電力を消費するイベントについて、より一般的な視点で考える価値があります。

次の表は、Wear OS アプリの一般的なイベント間でのバッテリー駆動時間への相対的な影響を示しています。正確な消費電力はデバイスによって異なります。

イベント バッテリー駆動時間への影響 軽減する方法
ネットワーク（LTE や Wi-Fi など）へのアクセス 非常に高い デバイスの充電が完了するまで、必須ではないネットワーク アクセスを延期する。
画面をオンにしてインタラクティブ モードを開始する 高 必要以上に長く画面を表示するようにユーザーに促してはなりません。常時オンモード（常に画面表示モードとも呼ばれます）を使用するエクスペリエンスを提供します。
GPS センサーへのアクセス 高 可能であれば、お客様が GPS アクセスをリクエストするまで待ちます。
CPU 使用率を高く保つ 高 Jetpack Compose を使用してフローを使用する。
心拍数センサーへのアクセス Medium Wear OS のヘルスサービスを使用する場合など、センサー API からコールバックを受信するときに、プロセッサの起動時間を使用します。
Bluetooth 経由で別のデバイスにアクセスする Medium セッションを短くする。
ウェイクロックを保持する Medium ウェイクロックの手動作成を減らし、 WorkManager を使用します。

画面オン時間を最小限に抑える

Wear OS アプリでは、画面の使用に関する以下の原則を遵守してください。

  • 画面オンのロック: 可能な限り避けてください。テストするには、システム設定で [常に表示状態のディスプレイ] をオフにし、タイムアウト時間内に画面がオフになるかどうかを確認します。
  • アニメーション: 緻密なアニメーションを最小限に抑え、代わりに短い切り替えに重点を置いて、プロフェッショナルな印象を与えます。特に、長時間実行されるアニメーションやループは避けてください。ループが必要な場合は、少なくともアニメーション自体の長さと同じ長さの一時停止をループ間に追加します。

  • 常に画面表示モードでの覚醒時間: フィットネスのユースケースなど、必要に応じて常時オンをサポートします。アプリで常時オンが必要な場合は、デバイスが常に画面表示モードになっているときにアプリが次の動作を行うことを確認します。

    • デバイスの画面が明るくする割合を小さくします。
    • アニメーションを表示しない。
    • onAmbientUpdate() コールバックを除き、画面のコンテンツを更新しません。

CPU 使用率を最小限に抑える

Wear OS アプリでは、次の CPU 使用率の原則に従います。

  • 使用時間を短くします。
  • 関連オペレーションをバッチ処理して、アプリのプロセスがアイドル状態である時間を最大化します。

ウェイクロックを最小限に抑える

ほとんどの場合、ウェイクロックなど、アプリのスリープを妨げる操作は行わないでください。たとえば、健康&フィットネス アプリでは、長時間実行されるワークアウトにウェイクロックは必要ありません。Wear OS のヘルスサービスを使用する場合など、センサー API からコールバックを受信するときにプロセッサの起動時間を使用します。

アプリが次のいずれかを行う場合など、ウェイクロックを取得しても問題ない場合があります。

  • メディアをバックグラウンドで再生します。
  • WorkManager または JobScheduler を使用します。（バックグラウンドでジョブを実行しているときに、システムがウェイクロックを保持します）。

Battery Historian を使用すると、長いウェイクロックの個々の発生状況と、保持されているウェイクロックの合計数と時間の概要を確認できます。アプリが保持している wake lock の数と期間を確認し、その情報をアプリのインタラクティブな使用パターンと比較します。

  • 予期しないウェイクロックがないか確認します。
  • 所要時間が想定よりも長い場合は、ネットワークの可用性などの依存関係によって作業がブロックされていないか確認します。

アプリがどのように非アクティブになるかを調べる

次のような主要なデバイス イベントが発生したときに、アクティブなアプリが何をしているかを検討します。

  • 画面がオフになり、デバイスが常に画面表示モードになります。

  • アプリがスワイプして閉じた。

アプリのアクティビティを分析するには、以下のセクションに示すツールを使用します。

Energy Profiler

Energy Profiler にアクセスするには、Android Studio のメニューで [View] > [Tool Windows] > [Profiler] を選択します。

  1. 画面がオフになり、デバイスが常に画面表示モードに切り替わったときに、システム トレースを調べます。
  2. 継続中の処理と、デバイスの CPU 使用率を確認します。

perfetto

Perfetto を使用すると、トレースを記録してアプリを検査し、画面がオフになったとき、デバイスが常に画面表示モードになったとき、またはユーザーがアプリのアクティビティを閉じたときに、なんらかの処理を行っているスレッドがあるかどうかを確認できます。

カスタム イベントを定義して、ドメイン固有のイベントなど、アプリの重要なイベントをマークします。メディアアプリの場合、プレイリストのフェッチ、特定のメディア アイテムのダウンロード、再生の開始、再生の停止などのタスクが含まれます。これらのイベントを定義することで Perfetto でイベントを表示し、それらのタイミングをアプリの CPU および電力使用量と比較できます。

アプリのスケジュールされたジョブを分析する

WorkManager を使用して、スケジュールされたジョブを使用すると、アプリでバックグラウンド処理を実行できます。一部のバックグラウンド処理は定期的に行う必要がありますが、ジョブを頻繁に実行したり長時間実行したりしないでください。デバイスのバッテリーが消耗する可能性があります。

Battery Historian を使用して、スケジュールされたジョブの実行を全体（[システム統計情報] > [ジョブスケジューラの統計情報]）とアプリ別（[アプリの統計情報] > [スケジュールされたジョブ]）の両方で検査します。合計数と合計時間を確認します。

  • ジョブが非常に頻繁に実行される場合は、この頻度を減らすことを検討してください。
  • 合計実行時間が予想どおりであり、それほど長くないことを確認します。

また、Battery Historian グラフを調べて、各 JobScheduler エントリを確認します。特定のエントリの上にポインタを置くと、Battery Historian に実行中のジョブのオーナーが表示されます。以下を検討してください。

  • アプリにとっては、実行時間が適切である必要があります。
  • ジョブがアプリの実行中に発生するのか、定期的なバックグラウンド処理であるのかを検討します。

センサー

Wear OS デバイスには、GPS などのさまざまなセンサーが搭載されています。ほとんどの場合、SensorManager を直接操作するのではなく、Wear OS のヘルスサービスを使用します。多くの場合、ヘルスサービスはバッテリーのパフォーマンスを向上させるために、データをインテリジェントにバッチ処理します。

アプリでのセンサーの使用状況を分析するには、開発マシンのターミナル ウィンドウで次のコマンドを実行します。

adb shell dumpsys sensorservice

このコマンドの結果は次のようになります。

  • 現在と以前のセンサー登録。
  • センサー構成（設定されている場合、バッチ処理を含む）。
  • 最近サンプリングされたデータ。

センサーからの登録解除をテストする

アプリがセンサーデータの取得を想定どおりに停止しているかどうかを確認するには、次のシナリオをテストします。

  1. アプリをスワイプで閉じます。
  2. 手のひらで画面をタップします。これにより、画面がオフになるか、画面が常に画面表示モードになります。

前のセクションの ADB コマンドを使用して、センサーが正しく未登録と表示されるかどうかを確認します。

データ レイヤー

Data Layer API を使用する場合、送信ごとにある程度の電力が消費されます。特に、この API を使用してデータを送信する場合、データを受信するためにアプリが復帰する必要があります。こうした理由から、この API の使用は慎重に行ってください。

Data Layer API を使用する場合のその他のおすすめの方法は次のとおりです。

  • アプリがアクティブになるまで待ってから、WearableListenerService を使用してリスナーを設定します。

  • 迅速な更新を構成するのではなく、状態の変更を送信します。こうした状態の変化により、Wear OS デバイスはワークアウト セッションの開始時などのローカルデータ計算を実行できます。

    UI を更新する状態変更のみを送信します。たとえば、アクティビティ画面に「走行距離（キロメートル）」と小数点以下 1 桁しか表示されていない場合は、ユーザーがもう 1 メートル先に進むたびに Wear OS に状態変更を送信しないようにします。

アプリでの Data Layer API の使用状況を分析するには、開発マシンのターミナル ウィンドウで次のコマンドを実行します。

adb shell dumpsys activity service WearableService

このコマンドの結果は次のとおりです。

  • RpcService: MessageClient を使用して、呼び出されている頻度とパスを確認できます。
  • DataService: DataClient を使用してデータ項目が設定された頻度を確認できます。

健康&フィットネス アプリ

健康&フィットネス アプリを管理している場合は、ヘルスサービスを使用して、アプリによるセンサーの使用を最適化します。

タイルとウォッチフェイスの追加機能

アプリがタイルまたはウォッチフェイスの追加機能をサポートする場合は、以下のおすすめの方法に従ってください。

  • 自動更新を無効にするか、更新頻度を 2 時間以上に増やします。
  • Firebase Cloud Messaging（FCM）または適切にスケジュールされたジョブを使用して、データの更新を送信します。更新が速い頻度で行われないように注意してください。頻繁に行われる作業のスケジュールが、ユーザーやプラットフォームが、その作業の実行に必要なデータにアクセスするよりも速い頻度で発生する可能性があります。
  • ユーザーが操作していないときは、タイルまたはウォッチフェイスの追加機能の処理をスケジュールしないでください。
  • オフラインファーストのアプローチを使用します。
  • メインアプリ、タイル、ウォッチフェイスの追加機能全体で単一のデータベースを共有できます。これにより、UI サーフェス間でデータの一貫性を維持することもできます。