Battery Historian を使用して消費電力を分析する

Battery Historian ツールは、デバイスのバッテリー消費量の推移に関する情報を提供します。このツールは、システムレベルでは、システムログから取得した消費電力関連イベントを HTML 表現で可視化します。各アプリレベルでは、バッテリーを消費するアプリ動作を識別するための各種データを提供します。

このドキュメントでは、Battery Historian を使用してバッテリー消費パターンを調べる方法について説明します。まず、Battery Historian がレポートするシステムレベル データの読み方について説明します。次に、Battery Historian を使用して、バッテリー消費に関連するアプリレベルの動作を診断し、トラブルシューティングを行う方法について説明します。最後に、Battery Historian が特に役に立つ状況におけるヒントをいくつか紹介します。

システムレベル ビューを使用する

Battery Historian ツールは、さまざまなアプリやシステムの動作をシステムレベルで可視化し、バッテリー消費の推移との相関関係を示します。このシステムレベル ビューは、アプリの電力消費に関する問題を診断、発見するのに役立ちます。図 1 をご覧ください。

図 1: バッテリー消費に影響するシステムレベル イベントを表示する Battery Historian ビュー

この図で特に注目すべきなのは、Y 軸(水平方向)に沿って下向きに推移している黒色の線です。これは、バッテリー残量を示しています。たとえば、このバッテリー残量グラフの初期段階である午前 6 時 50 分頃、バッテリー残量が比較的急激に低下しています。

画面の該当部分を拡大した図を図 2 に示します。

図 2: 午前 6 時 50 分から午前 7 時 20 分までの Battery Historian タイムラインの拡大図

この表示により、バッテリー残量グラフの初期段階でバッテリーが急激に減っているのは、CPU の実行、アプリのウェイクロック獲得、画面のオンという 3 つの要因があることがわかります。このように、Battery Historian を使用すると、バッテリー消費が多いときのイベントについて把握することができます。そして、アプリ内でその動作をターゲティングし、適切な最適化方法がないか調査することができます。

システムレベルの可視化は、ほかにも手掛かりを提供します。たとえば、頻繁にモバイルデータ通信のオン / オフが切り替わっていることが判明した場合は、JobScheduler や Firebase Job Dispatcher といったインテリジェント スケジューリング API を使用することで、この動作を最適化することができます。

次のセクションでは、アプリレベルの動作やイベントを調査する方法について説明します。

アプリレベルのデータを表示する

システムレベル ビューで提供されるマクロレベルのデータに加えて、Battery Historian は、デバイス上で稼働しているアプリごとにテーブルを表示し、データを可視化することができます。主なテーブルデータは次のとおりです。

  • アプリのデバイス上の推定消費電力
  • ネットワーク情報
  • ウェイクロック
  • サービス
  • プロセス情報

このテーブルでは、アプリに関するデータが 2 つの側面から示されます。まず、アプリの電力消費量ランキングを調べることができます。そのためには、[Tables] の下にある [Device Power Estimates] テーブルをクリックします。「Pug Power」という架空のアプリを調査する例を以下に示します。

図 3: 最も消費電力の多いアプリの調査

図 3 のテーブルに示すように、Pug Power は、このデバイス上で電力消費量が第 9 位のアプリであり、OS に含まれないアプリとしては第 3 位に位置しています。このデータにより、このアプリを詳細に調査する価値があることが示されます。

個々のアプリのデータを調査するには、可視化テーブルの左側にある [App Selection] で、2 つあるプルダウン メニューの下側の方にパッケージ名を入力します。

図 4: データを表示するアプリを入力する

個々のアプリを選択すると、以下のデータ可視化カテゴリの表示がシステムレベルのデータからアプリレベルのデータに変わります。

  • SyncManager
  • Foreground process
  • Userspace Wakelock
  • Top app
  • JobScheduler
  • Activity Manager Proc
アプリが必要以上に頻繁に同期やジョブを実行していた場合、SyncManager と JobScheduler の可視化によってすぐに判明します。この情報を基にアプリの動作を最適化することで、バッテリー消費を改善することができます。

また、[Userspace Wakelock] でも、アプリレベルの可視化データを取得することができます。この情報をバグレポートに含めるには、ターミナル ウィンドウで次のコマンドを入力します。

    $ adb shell dumpsys batterystats --enable full-wake-history
    

注: Android 6.0(API レベル 23)以降の Android プラットフォームには Doze 機能が組み込まれており、アプリに対して各種の最適化が自動的に適用されるようになりました。たとえば、JobScheduler のスケジュール設定に関係なく、一時的メンテナンス期間中は、Doze によってジョブが一括処理されます。

Pug Power のデータを図 5 と図 6 に示します。図 5 はアプリレベル データの可視化を示し、図 6 はそれに対応するテーブルデータを示しています。

図 5: 架空のアプリ「Pug Power」のデータの可視化

図 6: 架空のアプリ「Pug Power」のテーブルデータ

この可視化データを見ても、すぐに判明する情報はありません。[JobScheduler] 行を見ると、ジョブのスケジュールが設定されていないことがわかります。[SyncManager] 行を見ると、アプリが同期を実行していないことがわかります。

しかし、テーブルデータの [Wakelocks] セグメントを調べると、Pug Power が合計 1 時間以上ウェイクロックを取得していることがわかります。この異常で高コストな動作によって、このアプリの電力消費が多くなっている可能性があります。この情報により、最適化が役に立つ可能性のある領域をターゲティングできるようになります。この場合、アプリが長時間にわたってウェイクロックを取得している理由を探り、その情報を基に動作を改善していきます。

Battery Historian が役に立つ他のケース

バッテリー消費を改善するチャンスを診断するうえで Battery Historian が役に立つケースは、ほかにも多数あります。たとえば、Battery Historian によって以下のようなアプリを検出できます。

  • ウェイクアップ アラームを過度に頻繁にトリガーしているアプリ(10 秒以内に 1 回)
  • GPS ロックを継続的に保持しているアプリ
  • 30 秒以内の間隔でジョブをスケジュール設定しているアプリ
  • 30 秒以内の間隔で同期をスケジュール設定しているアプリ
  • 想定よりも頻繁にモバイルデータ通信を使用しているアプリ