ネットワーク最適化の理由
Web 最適化を実行することは、次の理由からモバイル アプリケーションにとって重要です。
ユーザー体験：
ネットワーク接続は、モバイル アプリケーションの中核機能の 1 つです。ネットワークの最適化により、アプリケーションの読み込み速度や応答速度が向上し、ユーザーの待ち時間が短縮され、よりスムーズで効率的なユーザーエクスペリエンスを提供できます。高速で安定したネットワーク接続により、ユーザーの満足度が向上し、アプリケーションの競争力が向上します。
トラフィックコストを節約します:
モバイル デバイスでモバイル データ接続を使用する場合、ネットワーク トラフィックが制限され、ユーザーにデータ使用料が請求される場合があります。ネットワークの最適化により、バックグラウンドまたはフォアグラウンドでアプリケーションが消費するネットワーク トラフィックを削減できるため、ユーザーがアプリケーションを使用する際のデータ料金が削減され、より経済的なネットワーク エクスペリエンスが提供されます。
バッテリー消費を節約します:
ネットワーク接続は、モバイル デバイスの主な電力消費の 1 つです。ネットワークの最適化により、アプリケーションによるネットワーク接続の頻繁な使用を減らし、継続的にネットワーク接続された状態にあるデバイスのバッテリー消費を削減できます。これにより、デバイスのバッテリー寿命が延長され、ユーザーはデバイスをより長時間使用できるようになります。
不安定なネットワーク環境に適応するには:
モバイル デバイスは、ネットワーク遅延やパケット損失など、ネットワークの不安定性に直面することがよくあります。ネットワークの最適化を通じて、再試行メカニズム、リクエストの結合、データ圧縮など、不安定なネットワーク環境に対処するためのいくつかの戦略を採用し、さまざまなネットワーク条件下でアプリケーションが安定した信頼性の高いサービスを提供できるようにすることができます。
仕様と制限事項を遵守してください。
Android や iOS などのモバイル デバイス プラットフォームには、通常、ネットワーク使用に関するいくつかの基準と制限があります。たとえば、アプリはバックグラウンド ネットワークの制限、リクエストの最大数、データ使用ポリシーなどに従う必要がある場合があります。ネットワークの最適化を実行すると、アプリケーションが対応するプラットフォームの仕様に確実に準拠し、制限やペナルティを回避できます。
ネットワークの最適化
通常のネットワーク リクエストが通過する必要があるプロセスは次のとおりです。
1. DNS 解決、DNS サーバーの要求、ドメイン名に対応する IP アドレスの取得、
2. TCP スリーウェイ ハンドシェイク、セキュリティ プロトコル同期プロセスを含むサーバーとの接続の確立、
3. 接続の確立が完了、データの送受信、データをデコードします。
ここには 3 つの明らかな最適化ポイントがあります:
1. IP アドレスを直接使用し、DNS 解決ステップを削除します;
2. リクエストごとに接続を再確立せず、接続を再利用するか、常に同じ接続を使用します (長い接続)
。 . データを圧縮して、送信されるデータのサイズを削減します。
DNSの最適化
DNS (Domain Name System) の役割は、根据域名查出IP地址HTTP プロトコルの前提となるもので、ドメイン名が IP アドレスに正しく解決されて初めて、その後の HTTP プロセスを続行できるようになります。
完全な DNS 解決プロセスは非常に時間がかかります。最初にローカル システム キャッシュから取得されます。そうでない場合は、最も近い DNS サーバーから取得されます。そうでない場合は、メイン ドメイン ネーム サーバーから取得されます。各層には、キャッシュ: キャッシュの各層には有効期限があります。
従来の DNS 解決メカニズムにはいくつかの欠点があります。
1. 缓存时间设置得长，域名更新不及时，设置得短，大量 DNS 解析请求影响请求速度；
2.域名劫持，容易被中间人攻击，或被运营商劫持統計によると、ドメイン名をサードパーティの IP アドレスに解決するハイジャック率は 7% に達します。
3. DNS 解析过程不受控制，无法保证解析到最快的IP；
4 一次请求只能解析一个域名.。
これらの問題を解決するには、 1 つあります HTTPDNS。原理は非常に単純です。ドメイン名解決作業を自分で行い、HTTP リクエストのバックグラウンドを通じてドメイン名に対応する IP アドレスを取得して、直接解決します。上記のすべての問題。
HTTPDNS (HTTP ベースのドメイン ネーム システム) の詳細な原理は次のとおりです。
客户端发起请求：
クライアントはドメイン名を解決する必要がある場合、ドメイン名をHTTP请求HTTPDNS サーバーに送信します。リクエストにURLは解析する必要があるものが含まれており域名信息、通常は GET または POST メソッドを使用し、リクエスト ヘッダーで関連するパラメータを指定します。
DNS解析请求：
HTTPDNS服务器クライアントのリクエストを受けて動作します域名解析。まず、检查本地的缓存ドメイン名の解決結果があるかどうかを確認します。存在し、キャッシュの有効期限が切れていない場合 (TTL 値に従って判断)、IP アドレスがキャッシュから直接取得され、クライアントに返されます。
缓存更新：
HTTPDNS サーバーのキャッシュ内にある場合は没有该域名的解析结果，或者缓存已过期、実際のリクエストが開始されますDNS解析。この要求は、権威ある DNS サーバーまたは他の信頼できる DNS 解決サービス プロバイダーに対して開始できます。サーバーはそれを解決した後域名对应的IP地址、结果缓存適切な TTL 値を設定します。
HTTP响应返回：
HTTPDNS サーバーは、解決されたデータをIP地址HTTP 応答の形式で返回クライアントに送信します。通常、応答には解析結果、TTL 値、その他の関連情報が含まれます。クライアントは、後続のネットワーク通信のために HTTP 応答コンテンツを解析することによって IP アドレスを抽出します。
客户端更新解析结果：
クライアントは HTTP 応答を受信すると、それを抽出し解析得到的IP地址、サーバーとの通信などの対応する処理を実行します。クライアントは必要に応じて分析結果をキャッシュし、キャッシュされたデータを次のリクエストで使用することで、HTTPDNS サーバーへの依存を軽減することもできます。
HTTPDNS の利点の概要は次のとおりです。
1.ローカルDNSハイジャック：HttpDnsが渡されるため IP 直接请求 HTTP 获取服务器 A 记录地址、基本的にローカル事業者にドメイン解決を依頼するプロセスがありません避免了劫持问题。
2.DNS 解析由自己控制ユーザーの位置に応じて最も近い IP アドレスが返されるか、クライアントの速度テストの結果に応じて最速の IP が使用されるようにします。
3. リクエストは 1 つだけでOKです解析多个域名。
…
接続の最適化
ここでの主な最適化の考え方は、リクエストが行われるたびに接続を再確立するのではなく、接続を多重化することであり、いかに効率的に接続を多重化するかが、ネットワークリクエスト速度の最適化において最も重要なポイントであると言えます。
【keep-alive】HTTP1.1默认开启: HTTP プロトコルには、ある程度のキープアライブがあります缓解了每次请求都要进行TCP三次握手建立连接的耗时。原則として、请求完成后不立即释放连接，而是放入连接池中この時点で別のリクエストを送信する場合、リクエストのドメイン名とポートは同じであり、接続プール内の接続がデータの送受信に直接使用されるため、時間のかかる接続が削減されます。確率。実際、クライアントとブラウザの両方でキープアライブがデフォルトで有効になっており、同じドメイン名については、リクエストが送信されるたびに接続が確立されることはなくなり、純粋な短い接続は存在しなくなります。
ただし有 keep-alive 的连接一次只能发送接收一个请求、前のリクエストが処理されるまで、新しいリクエストは受け付けられません。複数のリクエストが同時に開始された場合、次の 2 つの状況が発生します。
1.串行リクエストを送信する場合は可能です一直复用一个连接が、速度很慢各リクエストは送信する前に前のリクエストが完了するまで待つ必要があります。
2.并行リクエストを送信する場合は、 のみ每个请求都要进行tcp三次握手建立新的连接。
並列リクエストの問題に対しては、それを解決するための新世代プロトコルがHTTP2提案されています多路复用。HTTP2 の多重化メカニズムは同じです复用连接が、HTTP2 が多重化する接続により支持同时处理多条请求、所有请求都可以并发在这条连接上进行前述した同時リクエストに対して複数の接続を確立する必要があるために生じる問題も解決されます。
多重化はコネクション内に传输的数据1つずつカプセル化されてstreamいる ストリームごとに識別子がある ストリームの送受信が可能乱序順序に依存しないためブロッキングの問題がない 受信側は識別子を利用できるストリームのどのリクエストに属するかを識別し、数据拼接最終的なデータの取得に進みます。
Android のオープンソース ネットワーク ライブラリでありOKhttp默认就会开启 keep-alive、Okhttp3 より上のバージョンでは HTTP2 もサポートしています。
データ圧縮
リクエスト速度に対するデータの影響は 2 つの側面に分けられます。1 つは 、压缩率もう 1 つは です解压序列化反序列化的速度。現在、最も一般的なデータ形式はjsonと の protobuf2 つで、json は文字列、protobuf はバイナリです。さまざまな圧縮アルゴリズムで圧縮した後でも、protobuf は json よりも小さくなります。protobuf はデータ量の点で利点があり、protobuf はバイナリです。シリアル化速度の点でもいくつかの利点があります。
リンク: protobuf
さまざまなシリアル化方法 (データ形式) を選択することに加えて、HTTP はコンテンツ (つまり本文部分) をエンコードでき、gzipそのようなエンコードを使用して圧縮の目的を達成できます。
で自動的OKhttpにBridgeInterceptor行われます开启gzip解压的支持。
他の
1. 使用するwebp代替png/jpg
2.不同网络的不同图片下发など (元の画像が 300x300 の画像の場合):
2/3G は低解像度の画像を使用します。100X100 の画像を使用します。
4G の信号強度が強いと判断された場合は 300x300 の画像を使用し、信号強度が中程度であると判断された場合は 200x200 の画像を使用し、信号強度が弱いと判断された場合は 100x100 の画像を使用します。
WiFiネットワーク: 300X300の写真を直接送信
3、http开启缓存 / 首页数据加入缓存