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

電力効率は 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 センサー API からコールバックを受信する場合（Wear OS のヘルスサービスを使用している場合など）は、プロセッサの復帰時間を使用します。
Bluetooth 経由で別のデバイスにアクセスする Medium セッションは短くする。
ウェイクロックの保持 Medium ウェイクロックの手動作成を減らし、 WorkManager を使用します。

画面表示時間を最小限に抑える

Wear OS アプリでは、次の画面使用の原則に従ってください。

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

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

    • デバイスの画面が点灯する割合を減らします。
    • アニメーションは表示されません。
    • onAmbientUpdate() コールバック中を除き、画面のコンテンツを更新しません。

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

Wear OS アプリでは、次の CPU 使用の原則に従ってください。

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

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

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

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

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

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

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

アプリが非アクティブになる経緯を検査する

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

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

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

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

Energy Profiler

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

  1. 画面がオフになり、デバイスがアンビエント モードになったときに、システム トレースを検査します。
  2. 継続している処理と、デバイスの CPU 使用率を確認します。

perfetto

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

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

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

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

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

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

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

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

センサー

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 桁まで「走行キロメートル」しか表示されない場合は、ユーザーが次のメーターを前に移動するたびに Wear OS に状態変更を送信しないでください。

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

adb shell dumpsys activity service WearableService

このコマンドの結果には、次のものがあります。

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

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

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

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

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

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