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

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 を使用してフローを使用する。
心拍数センサーにアクセスする 中 Wear OS のヘルスサービス を使用する場合など、センサー API からコールバックを受信するときは、プロセッサの起動時間を使用します。
Bluetooth 経由で別のデバイスにアクセスする 中 セッションを短くする。
wakelock を保持する 中 手動での wake lock の作成を減らし、 WorkManager を使用します。

画面点灯時間を最小限に抑える

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

  • 画面オンロック: 可能な限り避けてください。テストするには、システム設定で [常に表示状態のディスプレイ] をオフにして、画面がタイムアウト期間内にオフになるかどうかを確認します。
  • アニメーション: 複雑なアニメーションは最小限に抑え、代わりに短い遷移に重点を置くことで、よりプロフェッショナルな外観を実現します。特に、長時間実行されるアニメーションやループは避けてください。ループが必要な場合は、ループ間にアニメーション自体と同じ長さ以上のポーズを追加します。
  • アンビエント モードでの起動時間: フィットネスのユースケースなど、必要に応じて常時稼働をサポートします。アプリで常時稼働が必要な場合は、常に画面表示モードに関する推奨事項に沿って対応してください。

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

Wear OS アプリでは、次の CPU 使用率の原則に沿って対応してください。

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

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

ほとんどの場合、wakelock など、アプリがスリープ状態になるのを防ぐオペレーションは避けてください。たとえば、健康＆フィットネス アプリでは、長時間にわたるワークアウトに wake lock は必要ありません。Wear OS のヘルスサービス を使用する場合など、センサー API からコールバックを受信するときに、プロセッサの起動時間を使用します。

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

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

ローカルで wake lock をデバッグするには、Android Studio のBackground Task Inspector、システム トレース、または adb shell dumpsys batterystats を使用して、長時間 wake lock の個々の発生状況と、保持されている wake lock の合計数と期間の概要を検査します。アプリが保持するウェイクロックの数と期間を、アプリのインタラクティブな使用パターンと比較します。

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

アプリが非アクティブになる仕組みを調べる

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

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

  • アプリがスワイプで閉じられた。

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

Power Profiler

Power Profiler には、Android Studio メニューで [View] > [ツール ウィンドウ] > [Profiler] を選択してアクセスできます。

  1. 画面がオフになり、デバイスが常に画面表示モードに移行する際のシステム トレースを調べます。
  2. 継続中の作業と、デバイスの CPU 使用率レベルを確認します。

perfetto

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

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

Android CLI を使用して android-profiler スキル（android skills add android-profiler）をインストールすることもできます。これにより、AI エージェントはコマンドラインから Perfetto システム トレースを記録し、電源レール、wake lock、デバイスの一時停止状態を分析できます。

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

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

Android Studio の Background Task Inspector（[View] > [ツール ウィンドウ] > [App Inspection]）を使用するか、adb shell dumpsys jobscheduler と adb shell dumpsys batterystats を実行して、スケジュールされたジョブと Worker の実行を検査します。実行頻度と合計期間を確認します。

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

システム トレースを記録して、ジョブの実行とアプリのアクティビティをタイムライン上で関連付けることもできます。次の点を考慮してください。

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

センサー

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

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

adb shell dumpsys sensorservice

このコマンドの結果には、次の情報が表示されます。

  • 現在および過去のセンサー登録。
  • センサーの構成（設定されている場合はバッチ処理を含む）。
  • 最近サンプリング データ。

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

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

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

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

データレイヤ

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

Data Layer API を使用する際のその他のベスト プラクティスは次のとおりです。

  • WearableListenerService を使用してリスナーを設定する前に、アプリがアクティブになるまで待ちます。
  • Data Layer API を使用してスマートウォッチに定期的に ping を送信し、コンパニオン デバイスまたはアプリが利用可能かどうかを確認しないでください。メッセージを繰り返し送信することで、アプリはラジオとリモートアプリのプロセスを起動し、デバイスのバッテリーを必要以上に消耗させます。代わりに、CapabilityClient を使用してデバイスの可用性と機能を検出するか、状態が変化したときにのみメッセージを送信します。

  • 高速更新を構成するのではなく、状態の変更を送信します。これらの状態変化により、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 サーフェス間でデータの一貫性を保つこともできます。