ネットワーク環境の変化への対応

こんにちは Internet Technologies チームのEricです 本日はアプリが ネットワーク環境の変化に どのように対応できるかについて説明します さっそく様々なタイプのネットワークと その固有の特性を 見ていきましょう Appleプラットフォームで 利用できるAPIを通じて ネットワーク接続に必要な情報を システムに記述する方法を説明します うまく動作しない場合に アプリが再接続を行うタイミングを どのように判断するかを 確認していきます 最後に アプリを使用する すべてのユーザーに ベストな体験を提供できるよう 様々なネットワーク環境下で行う テストについて詳しくお話しします まず ネットワークについて説明します Appleデバイスは多くの場合 携帯電話ネットワークやWi-Fiのように 複数の方法でネットワークに 接続できます 携帯電話通信しか使えないデバイスでも インターネットトラフィックで そのインターフェイスを使用できます デバイスがWi-Fiネットワークに 接続されると インターネットトラフィックに そのネットワークの インターフェイスだけが使用されると 考えがちです しかし現在は デバイスで2種類以上の インターフェイスを 使用できます プロトコルやアプリによっては どちらか一方を使用する場合や 両方のインターフェイスを 同時に使用できる場合もあります 既存の接続に より適した経路が通知され 後続の接続に 新しい接続を使用することを 検討するよう 示されることもあります 例えば アプリでMultipath TCPや QUICなどの マルチパステクノロジーを使用すれば 接続が失われた場合に 携帯電話通信とWi-Fi通信間を シームレスに移動できる 接続を作成できます アプリでは 操作性が向上する場合 Wi-Fiの代わりに 5Gネットワークを 使用することもできます ネットワークには 多様な特性があり それに応じて適する用途も異なります 例えば 一部の携帯電話ネットワークは 従量制のデータプランで 高コストになる場合がありますが 無制限のプランもあります 一部のWi-Fiネットワークも同様に インターネット共有に接続する場合などは 大量のデータを処理するのに 適していません 接続の設定が 省データモードの場合は ユーザーがデータ使用量の制限を 望んでいるということです システムでVPNなどの 別のインターフェイスが起動されて初めて 利用できるようになる ネットワークリソースもあります iPhoneやiPadでは アプリ利用のための Ethernet接続も考えられます ここで紹介したのは デバイスで利用できる可能性のある 様々な接続方法のほんの一例です 幸いなことに すべての組み合わせに 対応しなくてもアプリで 最良のユーザー体験を実現できます Appleプラットフォームでは アプリの接続に最適なインターフェイスが インテリジェントに選択されます この機能を最大限に活用するには アプリのネットワーク接続に必要な情報を システムに記述するだけです その方法を見ていきましょう これらすべてのネットワークタイプに 対応する最善の方法は ネットワークタイプではなく ネットワーク特性を定義することです これにより システムによって 各種の組み合わせの中から アプリの接続に最適な インターフェイスが選択されます ネットワーク接続に必要な情報を 宣言するには 2つのネットワーク特性を使用できます このわずか2つの特性を使用すれば ユーザーの環境設定に従って 利用可能なネットワークを アプリに採用させることができます ユーザーが省データモードを有効にして アプリで使用するデータ量を低減するよう リクエストした場合に 制約付きネットワークは発生し インターネット共有では 自動的に有効になります URLSessionConfigurationでは allowsConstrainedNetworkAccessを使い Networkフレームワーク使用時は prohibitsConstrainedPathsを使用して 制約付きネットワークで 接続を続けるべきかを判断します 一般に アプリの転送量は 小さいペイロードに制限し 制約付きネットワークでは ユーザーの明示的なアクションを 可能にするタスクのみを実行します 制約付きネットワークでは バルク転送や バックグラウンドフェッチは 実行しません ネットワークの使用は 高コストとなる場合もあります この場合も同様のロジックが当てはまります こうしたネットワークは ユーザーから 開始される操作にのみ使用します URLSessionとNetworkフレームワークの 同様のAPIを使用することで これらのネットワークの使用を 許可したり禁止したりできます 制約付きネットワークと 高コストなネットワークの両方で同様の ロジックを使用することを検討しましょう 特性に基づいて接続で使用する ネットワークの種類を記述したら すぐに接続を試みましょう 接続する前にデバイスがWi-Fiに 接続しているのか VPNにアクセスできるかのを 確認したいと考えられるかも知れませんが それは避けてください ネットワーク環境は 頻繁に変化しますし そうした変化はアプリのリクエストが 引き金になる場合もあります そのため プリフライト接続チェックは 不正確である場合が多く アプリの意図しない動作の 原因となることもあります 実際 SCNetworkReachabilityを使用した プリフライト接続チェックは iOS 17.4では推奨されていません 代わりに 実際に接続してみましょう 現在のネットワーク環境が原因で システムですぐにリクエストを 処理できない場合 URLSessionConfigurationで waitsForConnectivityを使用するか NWConnectionの waitingステートを使用することで タスクが待機中であることが通知され 状況が変わった時点で システムで自動的にリクエストが 再試行されます システムで接続を 自動的に待機できるため リクエストを再試行するタイミングを 非常に簡単に判断できます このような状況での対処方法を 見ていきましょう waitsForConnectivityの使用時に システムですぐに ネットワークリクエストを 開始できない場合 リクエストが待機状態になり urlSessionのタスクデリゲートによって タスクが接続を待機していることが アプリに通知されます この場合 接続状態が変わっても リクエストを再試行する 必要はありません システムで自動で行われます タスクが接続を 待機している場合には その理由をユーザーに伝え 必要とされるアクションを理解して 実行できるようにしたり アプリを引き続き 使用する方法を提供したりすることを 検討してください この例では 制約のないネットワークに デバイスが接続すると アプリのデータが 自動的に同期されます ただし「Sync Now」を タップするとこの制約が緩和され 制約付きネットワークで 同期が実行されます ネットワーク環境を伝える場合 アラートは 慎重に使用してください アラートは重要な情報を 伝えるものですが ネットワーク環境は 制御しようがないことが多く 混乱を招く恐れがあります 代わりに操作を続けるための 明確で簡単な方法に従って 情報や選択肢を提供しましょう 最後にテストについて説明します ユーザーはアプリを使用する際に 様々なネットワーク環境に置かれるため 多様な環境で テストを行うことが不可欠です Xcodeの「Devices and Simulators」 ウインドウで 様々なネットワーク環境を シミュレートできます 例えばネットワークリンク環境と LTEプロファイルを選択すると 平均的な環境下での一般的な LTEネットワークを シミュレートできます その後 アプリでワークフローの テストを行い すべてが円滑に処理されることを 確認します iPhoneやiPadで アプリのテストを行うには デベロッパ向け設定にある 「Network Link Conditioner」を使用します ここでもXcodeと同じネットワーク環境を シミュレートできます また「Network Override」を使用して デバイスの ネットワークプロパティの変更を シミュレートすることもできます 省データモードは 各インターフェイスの設定から いつでも有効にできます ここではシステムの 携帯電話とWi-Fiの 各インターフェイスを 高コストとみなすか 低コストとみなすかを設定できます また接続が不安定でセキュアでないWi-Fiより 5Gネットワークを優先するように システムを設定することもできます これにより 従来のネットワーク接続コードでは より適切な接続を 活用できなかった可能性のある 状況も検出できます 先ほど説明した ベストプラクティスに従って アプリを設定しており Networkフレームワークと urlSessionに ネットワークに必要な情報を 記述していれば 余計な手間をかけることなく システムで最適なインターフェイスが インテリジェントに選択されます ぜひこのタイミングで 最新のネットワーク接続手法を採用し デバイスのすべてのネットワーク インターフェイスを活用しましょう そのためには 制約付きネットワークに 適したリクエストなど ネットワーク接続に必要な特性に関する 情報をシステムに記述します Wi-Fiや携帯電話など リクエストを特定のインターフェイスに 限定することは避けます アプリからプリフライトネットワーク 接続チェック確認を削除し 手動での再試行の代わりに waitsForConnectivityを使用すると 条件がアプリのニーズに合ったときに ネットワーク接続が 自動的に再開するように 設定できます アプリでHTTP/3やQUICなどの 最新の高速プロトコルが 使用されていることも 確認してください 詳しくは「HTTP/3とQUICによる ネットワーキングの加速」をご覧ください このアプローチにより アプリのネットワーク接続が ネットワーク環境の変化に 自動的に対応し 最良のユーザー体験を実現できます ご視聴ありがとうございました