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

Wear OS では電力効率が特に重要です。Wear OS のデザイン Google の原則では、デバイスの電力使用量に重点を置いています。これは、スマートウォッチは 短い操作向けの小型フォーム ファクタです。

Wear OS デバイスは大型のモバイル デバイスに比べてバッテリーが小さいため、 バッテリーの消耗が顕著になりますそのうえ ユーザーの手間がかかります Wear OS デバイスを、モバイル デバイスと比較した場合の充電速度。ユーザーは充電しながら 1 日を通してさまざまな間隔でモバイル デバイスを操作しているので、 Wear OS デバイスを充電する前に体から取り外してください。

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

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

  • 可能な限り、スマートウォッチが充電中になるまでアプリの処理を先送りします。 特に、データの同期や、データ使用量の多いタスク、 整理に役立ちます。

    デバイスが充電中で、Wi-Fi 接続がある場合は、 ユーザーが期待するデータ、画像、更新を 。

この電源ガイドでは、システムがいつ、どのようにアプリを実行するかについて説明します。 アプリの実行時間とバッテリーの消耗を抑える方法をご紹介します。P-MAX の たとえば、アプリの読み込みや （Wear OS の Compose など）のパフォーマンスに関するガイダンスをご覧ください。 パフォーマンス ガイドをご覧ください。

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

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

adb shell dumpsys batterystats

GitHub のライブラリにバッテリー統計情報パーサーがあります。 このコマンドと一緒に実行すると便利です。

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

自分のアプリについて具体的に考える前に、 Wear OS デバイスで電力を消費するイベントに関する情報。

以下の表は、複数のデバイスにおけるバッテリー寿命への相対的な影響を示しています。 一般的なイベントをモニタリングできます正確な消費電力はデバイスによって異なります。

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

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

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

  • 画面オンのロック: 可能な限り避けてください。テストするには、[常時オン ディスプレイを開いて、画面がオフになるかどうかを 設定します。
  • アニメーション: 緻密なアニメーションを最小限に抑え、代わりに簡潔なアニメーションに焦点を当てます。 プロフェッショナルな見た目になります特に、長時間実行オペレーションを 処理できますループが必要な場合は、ループ間に一時停止を追加します。 少なくともアニメーションの長さと同じくらいの長さです。

  • 常に画面表示モードでの覚醒時間: 必要に応じて常時オンをサポートします。 ユースケース。アプリで常時オンが必要な場合は、アプリがその要件を満たしていることを確認してください。 デバイスが常に画面表示モードになっている場合は、次のようになります。

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

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

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

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

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

ほとんどの場合、アプリのスリープを妨げる操作は行わないでください。 wakelocks です。たとえば、フィットネス アプリ、長時間のワークアウト wake lock は必要ありません。コールバックを受信する際にプロセッサの起動時間を使用する センサー API から呼び出す必要があります（Wear OS のヘルスサービスを使用する場合など）。

ウェイクロックの取得が問題のない場合もあります。たとえば、 アプリは次のいずれかを実行します。

  • メディアをバックグラウンドで再生します。
  • WorkManager または JobScheduler を使用します。（システムには ウェイクロックをユーザーに代わって使用する必要があります）。

Battery Historian を使用すると、 ウェイクロック、ウェイクロックの合計数と継続時間のサマリー あります。アプリの wake lock の数と期間を調べる この情報を、組織のユーザーのインタラクティブな利用パターンと比較し、 app:

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

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

次のような主要なデバイス イベントが発生したときのアクティブなアプリの動作を考えてみましょう。 次のとおりです。

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

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

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

Energy Profiler

Energy Profiler にアクセスするには、Android Studio のメニューで 表示 >ツール ウィンドウ >Profiler:

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

perfetto

Perfetto では、トレースを記録し、アプリに 画面がオフになったとき、デバイスがオフになったとき、 常に画面表示モードに入ったとき、またはユーザーがアプリのアクティビティを閉じたとき。

カスタム イベントを定義して、次のようなアプリの重要なイベントにマークを付けることができます。 ドメイン固有のイベントを収集できます。メディアアプリの場合、 特定のメディア アイテムのダウンロード、再生の開始、停止 おすすめします。これらのイベントを定義すると、Perfetto でイベントを表示して比較できます。 アプリの CPU や電力使用量に合わせて調整できます。

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

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

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

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

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

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

センサー

Wear OS デバイスには、GPS などのさまざまなセンサーが搭載されています。ほとんどの場合、 Wear OS のヘルスサービス（直接やり取りする代わりに使用） SensorManager。多くの場合、ヘルスサービスはインテリジェントにデータをバッチ処理して、 バッテリー性能を改善します。

アプリでのセンサーの使用状況を分析するには、ターミナルで次のコマンドを実行します。 次のように指定します。

adb shell dumpsys sensorservice

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

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

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

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

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

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

データ レイヤー

Data Layer API を使用する場合、送信ごとにある程度の電力が消費されます。イン 特に、この API を使用してデータを送信する場合、 できます。こうした理由から、この API の使用は慎重に行ってください。

また、Data Layer API の使用に関するベスト プラクティスとして、 次のとおりです。

  • アプリがアクティブになるまで待ってから、 WearableListenerService。

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

    UI を更新する状態変更のみを送信します。たとえば、 アクティビティ画面に「kms ran」しか表示されない小数点以下 1 桁なので、 ユーザーが別のメーターを移動するたびに、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）を使用するか、適切にスケジュールを設定する jobsを使用して更新データを送信します。急速な更新や、 システムが反復処理のスケジュールをスケジュールするよりも ユーザーまたはプラットフォームはその作業の実行に必要なデータにアクセスできます。
  • ユーザーが予約していないときは、タイルまたはウォッチフェイスの追加機能の作業のスケジュールを設定しない やり取りできます
  • オフラインファーストのアプローチを使用します。
  • メインアプリ、タイル、ウォッチフェイスの追加機能全体で単一のデータベースを共有できます。この UI サーフェス間でもデータの一貫性が保たれます。