ワイヤレス通信を使用したデータの転送は、アプリにとってバッテリーの消耗が特に多い原因の一つです。ネットワーク アクティビティに関連するバッテリーの消耗を最小限に抑えるには、接続モデルが基盤となる無線ハードウェアにどのように影響するかを理解することが重要です。
このセクションでは、無線通信のステートマシンを紹介し、アプリの接続モデルが無線ステートマシンとどのように連携するかについて説明します。次に、アプリのデータ消費がバッテリーに与える影響を最小限に抑える方法をいくつか紹介します。
無線通信のステートマシン
ユーザーのデバイスのワイヤレス通信には、バッテリーの消費を最小限に抑える省電力機能が組み込まれています。完全にアクティブな場合、無線通信はかなりの電力を消費しますが、非アクティブまたはスタンバイ状態のときは、無線通信の電力消費はほとんどありません。
覚えておくべき重要な点の 1 つは、無線通信がスタンバイから完全にアクティブにすぐに移行できないということです。無線通信の「電源投入」に関連するレイテンシ期間があります。そのため、バッテリーは、使用されていないときに電力を節約するために高エネルギー状態から低エネルギー状態へのゆっくりと遷移します。また、無線通信の「電源投入」に関連するレイテンシを最小限に抑えようとします。
一般的な 3G ネットワークの無線通信のステートマシンは、以下の 3 つのエネルギー状態で構成されます。
- 全電力: 接続がアクティブなときに使用され、デバイスが可能な限り高い速度でデータを転送できるようにします。
- 低電力: バッテリーの消費を約 50% 削減する中間状態。
- スタンバイ: ネットワーク接続がアクティブでないときの最小限の電力消費状態。
低状態状態とスタンバイ状態ではバッテリーの消耗が大幅に少なくなりますが、ネットワーク リクエストのレイテンシが大幅に増加します。低電力状態から最大電力に戻るには約 1.5 秒かかり、スタンバイ状態から最大電力に戻るには 2 秒以上かかることがあります。
レイテンシを最小限に抑えるために、ステートマシンは遅延を使用して低エネルギー状態への移行を延期します。図 1 では、AT&T が測定した一般的な 3G 無線通信のタイミングを使用しています。
図 1. 一般的な 3G 無線通信ステートマシン
各デバイスの無線ステートマシン（特に関連する移行の遅延（「テールタイム」）と起動レイテンシ）は、使用されるワイヤレス無線技術（3G、LTE、5G など）によって異なり、デバイスが動作している携帯通信会社のネットワークによって定義および構成されます。
このページでは、AT&T が提供するデータに基づく、一般的な 3G 無線無線の代表的なステートマシンについて説明します。ただし、一般原則と結果として得られるベスト プラクティスは、すべてのワイヤレス無線実装に適用されます。
この方法は、ユーザーがウェブをブラウジングする際の望ましくないレイテンシを防ぐことができるため、一般的なモバイルウェブ ブラウジングに特に効果的です。また、テールタイムが比較的短いため、ブラウジング セッションが終了すると、無線通信は低エネルギー状態に移行できます。
残念ながら、このアプローチでは、アプリがフォアグラウンド（レイテンシが重要な場合）とバックグラウンド（バッテリー寿命を優先する必要がある場合）の両方で実行される、Android のような最新のスマートフォン オペレーティング システムでは、アプリの効率が低下する可能性があります。
アプリがラジオのステートマシンに与える影響
新しいネットワーク接続を作成するたびに、無線通信はフルパワー状態に移行します。前述の一般的な 3G 無線ステートマシンの場合、転送中、フルパワーのまま（さらに 5 秒のテールタイムが追加され、その後に低エネルギー状態で 12 秒かかります。したがって、一般的な 3G デバイスでは、データ転送セッションごとに少なくとも 18 秒間、無線通信でエネルギーが消費されます。
実際には、1 秒間のデータ転送を 1 分に 3 回行うアプリでは、ワイヤレス無線通信は永続的にアクティブ状態を維持し、スタンバイ モードに入ると高電力に戻ります。
図 2. 1 分間に 3 回実行される 1 秒間の転送における相対的な無線通信の電力使用量。図では、実行間の「パワーアップ」レイテンシは除外されています。
これに対して、同じアプリがデータ転送をバンドルし、1 分ごとに 3 秒間の転送を 1 回実行した場合、無線通信の高電力状態は 1 分あたり合計 20 秒しか持続しません。これにより、無線通信は毎分 40 秒間スタンバイ状態になるため、バッテリー消費量が大幅に削減されます。
図 3. 1 分ごとに 1 回実行される 3 秒間の転送における相対的な無線通信の電力使用量。
最適化手法
ネットワーク アクセスがバッテリー駆動時間に与える影響について理解したところで、次はバッテリーの消耗を抑え、高速で滑らかなユーザー エクスペリエンスを提供するためにできることをいくつか説明します。
データ転送をバンドルする
前のセクションで説明したように、データ転送をバンドルして、より多くのデータをより少ない頻度で転送することは、バッテリー効率を向上させる最善の方法の一つです。
ただし、アプリがユーザーの操作に応じてすぐにデータを送受信する必要がある場合は、この方法を常に使用できるわけではありません。これは、データを予測してプリフェッチすることで軽減できます。ログや分析をサーバーに送信する場合や、アプリから開始されるその他の緊急ではないデータ転送などは、バッチ処理やバンドルに非常に適しています。バックグラウンド ネットワーク転送のスケジュール設定のヒントについては、アプリ開始型タスクの最適化をご覧ください。
データをプリフェッチする
データのプリフェッチも、アプリが実行する独立したデータ転送セッションの回数を減らすための効果的な方法です。プリフェッチを使用すると、ユーザーがアプリ内でアクションを実行すると、アプリは次の一連のユーザー アクションで必要になる可能性が高いデータを予測し、そのデータを 1 回のバーストで 1 回の接続で最大容量で取得します。
転送をフロントローディングすることで、データのダウンロードに必要な無線通信のアクティブ化の回数を減らすことができます。その結果、バッテリーを節約できるだけでなく、レイテンシの改善、必要な帯域幅の削減、ダウンロード時間の短縮につながります。
また、プリフェッチは、アクションの実行やデータの表示の前にダウンロードが完了するのを待つことで生じるアプリ内レイテンシを最小限に抑えることで、ユーザー エクスペリエンスを向上させます。
次は実用的な例です。
ニュース リーダー
多くのニュースアプリは、カテゴリが選択された後にのみ見出しをダウンロードし、ユーザーが読みたいときにのみ記事の全文をダウンロードし、ビューにスクロールしたときにサムネイルをダウンロードすることで帯域幅を削減しようとします。
このアプローチを使用すると、ラジオは、ユーザーが見出しをスクロールし、カテゴリを変更し、記事を読んだときに、大半のユーザーがニュースを読むセッションの間、アクティブな状態を維持せざるを得なくなります。それだけでなく、エネルギー状態を絶えず切り替えると、カテゴリの切り替えや記事の閲覧で大幅なレイテンシが発生します。
より優れたアプローチは、起動時に妥当な量のデータをプリフェッチすることです。最初のニュースの見出しとサムネイルのセットから始めて（レイテンシを低く抑えて起動）、残りの見出し、サムネイル、少なくともメインの見出しリストにある各記事の記事テキストから続けます。
また、すべての見出し、サムネイル、記事のテキストだけでなく、場合によっては記事全体の画像もプリフェッチできます。通常はあらかじめ決められたスケジュールでバックグラウンドで行われます。このアプローチでは、使用されないコンテンツをダウンロードする際に帯域幅とバッテリー駆動時間が多くなるリスクがあるため、慎重に実装する必要があります。
その他の考慮事項
データのプリフェッチには多くのメリットがありますが、プリフェッチが多すぎると、使用されていないデータをダウンロードすることで、バッテリーの消耗と帯域幅の使用量、ダウンロード割り当てが増加するリスクも生じます。また、アプリがプリフェッチの完了を待機している間、プリフェッチによってアプリの起動が遅れないようにすることも重要です。具体的には、データを段階的に処理することや、アプリの起動に必要なデータが最初にダウンロードされて処理されるように優先して連続した転送を開始することを意味します。
データをどれだけ積極的にプリフェッチするかは、ダウンロードされるデータのサイズと使用される可能性によって異なります。大まかなガイドとして、前述のステートマシンに基づくと、現在のユーザー セッション内で使用される可能性が 50% のデータの場合、通常は約 6 秒（約 1 ～ 2 メガバイト）プリフェッチできます。ただし、そもそも、未使用のデータをダウンロードした場合の費用と、そのデータをダウンロードしない場合の費用削減額は一致しません。
一般的には、2 ～ 5 分ごとに（1 ～ 5 MB 程度）ダウンロードを開始するだけで済むように、データをプリフェッチすることをおすすめします。
この原則に従い、動画ファイルなどのサイズの大きなダウンロードは一定間隔（2 ～ 5 分ごと）にチャンク形式でダウンロードし、数分以内に再生される可能性が高い動画データのみを効果的にプリフェッチする必要があります。
1 つの解決策は、Wi-Fi に接続されているとき、場合によってはデバイスが充電中のときにのみ、フル ダウンロードが行われるようにスケジュールすることです。WorkManager API はまさにこのユースケースをサポートしており、デバイスがデベロッパーが指定した条件（充電や Wi-Fi への接続など）を満たすまでバックグラウンド処理を制限できます。
リクエストを行う前に接続を確認する
モバイル デバイスにおいて、セル信号の検索は消費電力を最も消費する処理の一つです。ユーザーが開始したリクエストの場合、接続ステータスと接続測定をモニタリングするに示すように、まず ConnectivityManager を使用して接続を確認することをおすすめします。ネットワークがない場合は、モバイル無線による検索を強制しないことで、バッテリーを節約できます。リクエストは、接続の確立時に他のリクエストとともにスケジュールされ、バッチで実行できます。
プール接続
一括処理とプリフェッチに加えて、アプリのネットワーク接続をプールすることもできます。
一般に、新しいネットワーク接続を開始するよりも既存のネットワーク接続を再利用するほうが効率的です。また、接続を再利用すると、ネットワークは輻輳や関連するネットワーク データの問題にインテリジェントに対応できます。
HttpURLConnection やほとんどの HTTP クライアント（OkHttp など）では、デフォルトで接続プールが有効になり、複数のリクエストに対して同じ接続を再利用します。
まとめと今後の展望
このセクションでは、ワイヤレス通信について多くのことを学びました。また、バッテリーの消耗を抑えながら、高速で応答性の高いユーザー エクスペリエンスを提供するために幅広く適用できる戦略について学習しました。
次のセクションでは、ほとんどのアプリに共通する 3 種類のネットワーク インタラクションについて詳しく説明します。各タイプの推進要因と、それらのインタラクションを効率的に管理するための最新の手法と API について学びます。