モバイルのバッテリー消費とプロファイリング

バッテリー消費は「平均」ではなく「状態遷移」で決まる

モバイル端末の電力設計で最初につまずくのは、消費電力を平均値で捉えてしまうことです。実際のバッテリー消費は、CPU・GPU・無線それぞれが持つ複数の電力状態と、その間を行き来する遷移コストの積み重ねで決まります。同じ処理量でも、状態遷移を減らせば消費電力は大きく下がります。これは組込み機器の低消費電力設計と原理的に地続きの話で、根底にあるハードウェア側の電力管理は /embedded/ の話題とも重なります。

CPU/GPU：DVFSとrace-to-idle

CPUとGPUは動的電圧周波数スケーリング（DVFS）によって、負荷に応じて動作周波数と供給電圧を変化させます。消費電力はおおむね電圧の2乗に周波数を掛けた値に比例するため、電圧を1段階落とせるだけで効果は大きくなります。ここで重要なのが「同じ仕事量をどう電力に変換するか」という設計判断です。

GPUも同様で、フレームレートを維持できる最低限のクロックに張り付かせる設計と、フレームごとに全力で描画してすぐ休む設計とでは、後者が有利になる場面が少なくありません。ただし遷移そのものにも電力がかかるため、処理を極端に細かく分割すると逆効果になる点は両者に共通します。

無線の電力特性：送受信よりテイルが支配的

無線通信の電力特性はCPU/GPUとは性質が異なります。セルラー通信もWi-Fiも、データを実際に送受信している時間そのものより、通信のために電波を掴み続ける待機時間（テイル、tail time）の方が総消費電力を支配することが多いのです。

この「テイル」の影響は、位置情報や通信を一定間隔で行う、いわばレーダーのように周期的に外界へ電波を出すアプリの挙動を考えるとわかりやすくなります。5秒ごとに小さなデータを送るポーリングを行うと、無線チップは毎回スリープから起きてテイルタイマー分の高電力状態を経て再びスリープするという遷移を繰り返します。実際に転送するデータ量がわずかでも、この遷移1回あたりのコストが積み上がり、総消費電力は送信間隔をまとめて長くした場合より大幅に増えます。

計測ツール：Xcode Energy LogとBattery Historian

電力設計の勘所を押さえても、実機でどの区間が実際に電力を消費しているかを可視化しなければ最適化は進みません。iOSとAndroidにはそれぞれ専用の計測基盤があります。

Xcode の Energy Log（Instruments の Energy Log テンプレート、旧称 Energy Diagnostics）は、CPU・GPU・ネットワーク・位置情報・ディスプレイ輝度それぞれの寄与を時系列グラフで重ねて表示し、OSが算出する「エネルギーインパクト」スコアの内訳を確認できます。無線については、実際に送受信している区間だけでなく、モデムが高電力状態を維持しているテイル区間も別レーンで表示されるため、どの通信がテイルを誘発しているかを視覚的に特定できます。

Android の Battery Historian は、dumpsys batterystats が収集したログを解析し、ウェイクロック（アプリがCPUや画面のスリープ移行を一時的に止められる、参照カウント式の抑止機構）の保持区間、モバイル無線の状態遷移、GPS取得区間、画面点灯区間などをタイムライン上に並べます。特定のウェイクロックがいつ誰に取得され、どれだけの時間保持され続けたかを追えるため、「バックグラウンドで解放し忘れたウェイクロックがバッテリーを削っている」といった原因の特定に向いています。

両者に共通するのは、消費電力を単一の数値ではなく状態遷移の時系列として見る点です。ピーク電力そのものより、高電力状態がどれだけの時間続いたか、そしてその状態にどれだけの頻度で入ったかを見ることで、改善すべき区間が特定できます。

まとめ

モバイルのバッテリー消費は、CPU/GPUのDVFSと休止状態の使い方、そして無線の間欠通信が生むテイルという、性質の異なる複数の電力メカニズムの合成で決まります。処理をまとめて速く終わらせるrace-to-idle、通信要求をまとめて無線の起床回数を減らすバッチング、そしてXcode Energy LogやBattery Historianで状態遷移そのものを時系列で可視化する計測習慣。この3つを組み合わせることで、体感の重さではなく数値に基づいた電力効率設計が可能になります。