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

キーワード: Wear OS、電源、バッテリー、パフォーマンス

消費電力の効率化は 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 アプリの一般的なイベントにおけるバッテリー駆動時間への相対的な影響を示します。具体的な電力消費量はデバイスによって異なります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 画面がオフになり、デバイスがアンビエント モードになります。

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

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

Power Profiler

Power Profiler は、Android Studio メニューで [View] > [Tool Windows] > [Profiler] を選択してアクセスできます。

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

perfetto

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

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

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

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

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

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

また、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 を更新する状態の変更のみを送信します。たとえば、アクティビティ画面に「走行距離（km）」が小数点以下 1 桁でのみ表示される場合は、ユーザーが 1 m 進むたびに Wear OS に状態変化を送信しないでください。

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

adb shell dumpsys activity service WearableService

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

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

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

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

• ExerciseClient の場合は、Battery Historian を使用して、アンビエント モードでの動作が正しいことを確認します。アプリが ExerciseUpdate データを受信するために 1 ～ 2 分間隔より頻繁にウェイクアップしていないことを確認します。
• 終日一般的な健康状態をモニタリングするには、バックグラウンドで健康とフィットネスのデータをモニタリングする方法のガイドで説明されているように、PassiveMonitoringClient を使用します。

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

アプリがタイルまたはウォッチフェイスの追加機能をサポートしている場合は、次のベスト プラクティスに従ってください。

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