Android開発者向けの実用的なネットワーク(パート1)

2020年11月7日)

すべてのアプリケーションの簡単なデータレイヤー

このシリーズのブログのリストは次のとおりです:

  • パート1—HTTPおよびネットワーク層
  • (パート2 — TLS、証明書、およびピン留め)
  • (パート3 —オーセンティケーターとインターセプター)
  • (パート4 —パフォーマンス、冗長性、および同時実行性)
  • (パート5 —テストと統合)
Android開発者向けの実用的なネットワーク

これはこのシリアルの最初の部分です「Android開発者向けの実用的なネットワーク」通常はアドレスされる、異なるビジョンを持つネットワークデータレイヤーについて話すときd、Androidでのネットワーキングは機能しにくいため、複数のキャリア、さまざまなリッチコンテンツ、ストリーミングがあり、これらすべてが1つの詳細を見逃すことなくユーザーに届くはずです

HTTPとネットワークレイヤー

Httpはネットワークプロトコルです。使用しているインターネットに接続している場合、定義のきれいなバージョンはHttpが次のとおりです。

「An アプリケーションレイヤー 分散型、協調型、 hypermedia 情報システム」

これは、基本的に、ウェブサイトを構築している場合、たくさんのことを意味します、スマートフォンアプリ、IoT、ファイルのダウンロードのみでも、このプロトコルを使用しています。シンプルなHTMLのウェブページからウェブアプリケーション、モバイルアプリに成長し、一般的に使用されるAPIレイヤーに進化しました。

HTTP要求ユーザーがモバイルアプリを操作すると、ユーザーによってtsが生成されます。アプリ内にHTTPリクエストを入力するたびに、クリック、スクロール、削除など、サーバーからの情報のリクエストを開始します。たとえば、Gmailを想像してみてください。電子メールが更新されるように作成されます。電子メールを削除、応答、または開くと、Http要求が生成され、これらのHttp要求はオリジンサーバーまたはプロキシキャッシングサーバーのいずれかに送信され、そのサーバーはHttp応答を生成します。通常、リクエスト/レスポンスのセットには次のものがあります。

  • リクエスト— HTTPリクエストを作成しますURLへ
  • 応答— リクエストは、エラーまたは成功の可能性がある応答を返します。
  • 解析可能なデータ— モバイルでは、オブジェクト、データへの応答を解析する必要がありますMoshi、Json、Gson *などのサードパーティを使用してアプリ内で使用できるクラスまたはStructは、独自に作成することもできますが、電話に到達すると、単純な文字列になります。

通常、すべてのHttpリクエスト/レスポンスには次の2つのことがあります:

  • URLユニフォームロケーター: URLは特定の場所、アドレスです特定の種類のメソッドを使用したインターネット上のどこか
  • ヘッドers:クライアントに を提供し、サーバーはHTTPを使用して追加情報を渡しますリクエストまたはレスポンス。 HTTPヘッダーは、大文字と小文字を区別しない名前、コロン(:)、値で構成されます。
  • Body:実際の応答、つまり本文のコンテンツを公開する単純な文字列は、たとえばユニットであっても、一部のメソッドでは何の意味もありません。

リクエストが届くたびに、成功しなかった場合でも、それを知るためのステータスコードがあります。

  • 1xx —すべてがクールです。少し待ってください
  • 2xx —すべて問題ありません。これは完全に連続した応答です
  • 3xx —応答は別の場所にあり、失われます
  • 4xx—クライアントからの要求は十分に実行されていないため、これはモバイル側からのエラーです
  • 5xx —サーバーが正しいリクエストを実行できなかったため、これはバックエンド側からのエラーです

HTTPメソッド

複数のHTTPメソッドがあります

  • @GET:リソースに関する情報の読み取りまたは取得に使用されます。 GETリクエストはデータの読み取りにのみ使用され、データを変更することはありません。安全であると見なされます
  • @POST:新しいリソースの作成に使用されます。特に、従属リソースを作成するために使用されます。安全でもべき等でもありません。したがって、べき等でないリソース要求にはお勧めします。2つの同一のPOSTリクエストを行うと、同じ情報を含む2つのリソースが生成される可能性があります。
  • @PUT:更新機能に使用され、既知のリソースURIにPUTします。元のリソースの新しく更新された表現を含むリクエスト本文を使用します。 PUTは、サーバーの状態を変更(または作成)するという点で安全な操作ではありませんが、べき等です。つまり、PUTを使用してリソースを作成または更新してから、同じ呼び出しを再度行うと、リソースは引き続き存在し、最初の呼び出しの場合と同じ状態になります。
  • @DELETE: URLで識別されるリソースを削除するために使用されます。
  • @PATCH:機能を変更するために使用されます。 PATCHリクエストには、リソース全体ではなく、リソースへの変更のみを含める必要があります。 PATCHは安全でも、完全でもありません。

モバイルアプリケーションのこれらのメソッド内での変更は、非常に危険である可能性があります。応答で変数をdoubleとして受け取るアプリケーションを想像してみましょう。 、これがどういうわけかブール値に変更されると、データの解析が壊れます。これは、バックエンドエンジニアが本番環境で参照されているエンドポイントを変更するたびに考慮しなければならない大きな落とし穴です。

HttpClient

現在、ほとんどのAndroidアプリケーションはAPIに基づいて構築されています。 APIは通常RESTfulWebサービスであり(多くの場合がありますが、これは単なる例です)、HTTP経由でアクセスでき、ユーザーがアプリケーションと対話できるようにするリソースを公開します。ほとんどの場合、アクセスするにはHttpClientが必要です。インターネットに接続して、ユーザーのデータの取得を開始します。

Androidの内部には、 OkHttpClientと呼ばれるHttpClientを数秒で作成する素晴らしいライブラリがあります。 、これにより、readTimeOutとConnectionTimeOutを使用してクライアントが作成されます。このタイムラプスでサーバーが応答を提供しない場合、接続が失敗します。
の非常に重要な部分があります。このクライアントでは、キャッシュ用のビルダーを配置することもできます(およびこのシリアルで後で説明する他の多くのこと)

キャッシュ

ネットワークを介したリソースの取得は遅く、高価な主な理由は、モバイルで複数のものに依存していることです。たとえば、ユーザーがいるネットワークでは、5Gから3G、光ファイバーを使用したWIFIから通信ケーブルまで

キャッシュが設計されています誰にとっても、ユーザーにとっても、ネットワークコールをより良くするために、不必要なネットワーク要求なしに終了するからです。インスタンスごとに、キャッチによってDNSへの元の呼び出しが置き換えられることはありません。キャッシュは、ソースからデータをフェッチする代わりにはなりません。

データベースのキャッシュ
実際にはネットワーク層に関するものではありません。情報についてAPIに問い合わせ、SharedPreferences、DataStore、またはリレーショナルまたは非リレーショナルのデータベース内に保存します。データベースが提供する速度とスループットの両方のパフォーマンスは、アプリケーションの全体的なパフォーマンスの最も影響力のある要因になる可能性があります。

コンテンツ配信ネットワーク
サーバートラフィックが世界中にある場合、インフラストラクチャ全体を世界中に複製することは必ずしも簡単でコスト面での方法ではありません。そのために、次の機能を提供するCDNがあります。エッジロケーションのグローバルネットワークを利用して、画像、ストリーミング、ビデオなどのAPIコンテンツのキャッシュコピーを配信します

ドメインネームシステム
インターネット上で行われるすべてのドメインリクエストは、基本的に、ドメイン名に関連付けられたIPアドレスを解決するためにDNSキャッシュサーバーにクエリを実行します。 DNSキャッシュは、OS、ISP、DNSサーバーなど、さまざまなレベルで発生する可能性があります。

特にネットワークの場合、HttpClientにキャッシュ(上記のコードを確認)と非キャッシュを処理させることができます。一部のアプリケーションでは、更新するためのプルがあり、キャッシュをスキップしてサーバーから直接データをフェッチする必要がある場合があります。完全な更新を強制するには、OkHttpClientのキャッシュビルダーにno-cacheを直接追加します。このタイプの呼び出しを行うかどうかの決定は、技術的な観点よりも特に製品的な観点から行われます。

これで投稿のこの部分はすべてです。次のパートでは、証明書、ピン留め、TSLについて説明します!

サポートが必要な場合:

いつでもサポートさせていただきます。こちらで私を見つけることができます:

Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar

ハッピーコーディング! 👩🏻‍💻