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