Androidのネットワーク：トラフィック、セキュリティ、バッテリー

現在、Google Playには80万以上のアプリケーションがあります。 それらの多くは、クライアント/サーバー通信に基づいて実装されています。 このようなアプリケーションを開発する場合、この記事で説明する3つの主要なポイントを考慮する必要があります。



アプリケーションのネットワーク部分を実装する際に覚えておくべきこと



最初は交通です。 無料のWi-Fi接続で作業できるとは限りません。また、モバイルインターネットは依然として高価です。トラフィックはユーザーのお金であるため、これは覚えておく必要があります。



2番目はバッテリーの制限です。 モバイルデバイスは、一部の日常的な活動、会議、散歩、ビジネスのためにユーザーに必要であり、バッテリーが最も不適切な瞬間になくなると、ユーザーはinします。

3番目はセキュリティです。 私たちがモバイルクライアントについて話しているのと同じで、データがクライアントからサーバーへ、またはその逆にネットワーク上を移動しているので、それらを保護する必要があります。



ネットワーキングアプローチ



まず、クライアント/サーバー通信を実装する方法が存在し、今日一般的に使用されていることを思い出してください。

最初のアプローチはソケットに基づいています（ここではSocket APIを直接操作することを意味します）。 多くの場合、メッセージ配信の速度が重要であり、メッセージ配信の順序が重要であり、サーバーへの安定した接続を維持する必要があるアプリケーションで使用されます。 このメソッドは、多くの場合、インスタントメッセンジャーおよびゲームで実装されます。







2番目のアプローチは頻繁なポーリングです。クライアントはリクエストをサーバーに送信し、それを次のように伝えます。 サーバーはクライアントのリクエストに応答し、この時点までに蓄積したすべてを提供します。







このアプローチの欠点は、クライアントがサーバーに新しいデータが現れたかどうかを知らないことです。 主にサーバーへの頻繁な接続が原因で、ネットワーク上でトラフィックが再び追跡されています。



3番目のアプローチ-長いポーリング-は、クライアントがサーバーに「保留」要求を送信することです。 サーバーは、クライアントの最新データがあるかどうかを確認し、ない場合は、このデータが表示されるまでクライアントとの接続を維持します。 データが表示されるとすぐに、彼はそれらをクライアントに「プッシュ」します。 サーバーからデータを受信したクライアントは、すぐに次の「保留中」要求などを送信します。







このアプローチの実装は、主にモバイル接続の不安定性のため、モバイルクライアントではかなり複雑です。 しかし、このアプローチでは、通常のポーリングよりも少ないトラフィックが消費されます。 サーバー接続設定の数が削減されます。

長いポーリングのメカニズム、またはプッシュ通知は、Androidプラットフォーム自体に実装されています。 そして、おそらく、ほとんどのタスクでは、自分で実装するのではなく、使用する方が良いでしょう。 アプリケーションは、プッシュ通知を受信するためにGoogle Cloud Messaging（GCM）サービスにサブスクライブします。







これは、サーバーがGCMサービスと連携し、常にこのサービスに新しいデータを送信するため、サーバーとクライアント間の接続を直接切断し、このデータをアプリケーションに配信するためのすべてのロジックを実装します。 このアプローチの利点は、データが確実に出現したことを確実に知っているため、サーバーに頻繁に接続する必要がなくなり、GCMサービスがこれについて通知することです。

これら4つのアプローチのうち、プッシュ通知と頻繁なポーリングは、ビジネスアプリケーションを開発する際に最も一般的です。 これらのアプローチを実装する場合、何らかの方法でサーバーへの接続を確立し、データを転送する必要があります。 次に、開発者がHTTP / HTTPSプロトコルを操作するために使用できるツールに焦点を当てます。



HttpUrlConnectionおよびHttpClient



Android開発者の武器には、これらのプロトコルを操作するための2つのクラスがあります。 最初はjava.net.HttpURLConnection、2番目はorg.apache.http.client.HttpClientです。 これらのライブラリは両方ともAndroid SDKに含まれています。 次に、これらの各ライブラリを操作するときにトラフィック、バッテリー、セキュリティに影響する主なポイントについて詳しく説明します。



HttpURLConnectionを使用すると、すべてが簡単になります。 1つのクラスとすべて。 これは、親クラスURLConnectionがHTTPプロトコルだけでなく、ファイル、mailto、ftpなどでも機能するように設計されているためです。







HttpClientは、よりオブジェクト指向になるように設計されています。 抽象化が明確に分離されています。 最も単純なケースでは、5つの異なるインターフェイス、HttpRequest、HttpResponse、HttpEntity、およびHttpContextを使用します。 したがって、ApachevクライアントはHttpUrlConnectionよりもかなり重いです。







通常、アプリケーションごとにHttpClientクラスのインスタンスは1つだけです。 これは、その重さによるものです。 リクエストごとに個別のインスタンスを使用するのは無駄です。 たとえば、HTTPクラスのインスタンスをApplicationクラスの後継に格納できます。







HttpUrlConnectionの場合、リクエストごとに新しいクライアントインスタンスを作成する必要があります。







トラフィックは何で構成されていますか？



アプリケーションの実行中、画像は次のようになります。







要求の数と頻度は、UI-アプリケーションインターフェイスの機能と飽和度に依存します。 このような各要求は、サーバーへのTCP接続を確立します。 この場合、消費されるトラフィックは、接続設定の合計と送信データの合計に等しくなります。 この場合、長生きする接続（キープアライブ）を使用することにより、トラフィック消費を削減できます。







キープアライブの基本的な考え方は、同じTCP接続を使用してHTTP要求を送受信することです。 主な利点は、トラフィックの削減とクエリの実行時間です。 簡単なテストを行いました。これは、同じホストに対して10個のリクエストが順番に実行されるという事実から成りました。 以下の表にデータを示します。 キープアライブをオフにすると、平均クエリ実行時間が約2秒であることがわかります。 キープアライブを有効にした場合、この時間は1.7秒に短縮され、16％速くなりました。 これは主に、サーバーへの接続を頻繁に確立する必要がなくなるためです。 安全なHTTPS接続を使用する場合、違いはより顕著になります。 SSLハンドシェイクは、TCPハンドシェイクよりもはるかに困難です。







キープアライブ接続の重要なパラメーターは、キープアライブ期間です。 時間間隔を意味します。 この間隔内に複数のHTTP要求が到着すると、すでに確立されているTCP接続が再利用されます。







図から、4番目と3番目の要求の間の時間がキープアライブ期間を超えているため、サーバーへの新しいTCP接続が作成されていることがわかります。

上記のパラメーターを設定する方法を見てみましょう。 HttpClientの場合、すべて問題ありません。ConnectionKeepAliveStrategyインターフェイスを自由に使用できます。 getKeepAliveDurationメソッドをオーバーライドすることにより、キープアライブ期間パラメーターの目的の値を返すことができます。

httpClient.setKeepAliveStrategy( new ConnectionKeepAliveStrategy() { @Override public long getKeepAliveDuration( HttpResponse response, HttpContext context) { return KEEP_ALIVE_DURATION_MILLISECONDS; } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HttpUrlConnectionを使用する場合は、Android 2.2プラットフォームのバグを思い出し、 2.2以下のプラットフォームでキープアライブを無効にする必要があります。

 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.FROYO) { System.setProperty("http.keepAlive", "false"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HttpUrlConnectionを操作するときの2番目の不快な（おそらく私だけの）瞬間は、キープアライブ期間パラメーターを構成できないことです（誰かが私に感謝すると言う場合、合法的な方法は見つかりませんでした）。 デフォルトでは、約5秒です。

また、キープアライブ接続で作業する場合、確立された接続（接続）からデータを完全に読み取ろうとする必要があります。 データを読み取らないと、プールでハングアップする接続を取得でき、他の誰かがそれらを読み取ろうとしていると「考える」ことができます。 InputStreamが正常に受信された場合、応答本文全体を読み取ります。 完全な読み取りは 、データから接続をクリアし、この接続は再利用される可能性が高くなります。



クッキー



Cookieは、Webサーバーから送信され、ユーザーのコンピューターに保存される小さなデータです。 この場合、コンピューターはAndroidデバイスです。 実際には、Cookieは通常、ユーザーの認証、ユーザーの個人設定と設定の保存、ユーザーのアクセスセッションのステータスの追跡、およびユーザーに関する統計の保持に使用されます。 サイトのモバイルバージョンが既に作成された後、多数のサービスがモバイルアプリケーションの開発を開始します。 このような状況では、「モバイルアプリケーションで認証Cookieを受け取って、ブラウザー（WebViewで）にインストールすることは可能ですか？」という質問が興味深いです。 この問題を解決するとき、時間を節約するのに役立ついくつかの詳細があります。

1. プラットフォーム> = 4.0.3（APIレベル15） では、ドメインの先頭にドットが必要です
2. CookieSyncManagerのsync（）メソッドを呼び出した後、Cookieはアプリケーション内のWebViewでのみ設定され、ブラウザーでは設定されません 。 この制限は、セキュリティ上の理由からAndroidシステムによって課されています。

セキュア接続（HTTPS）



この記事の最後で、AndroidでHTTPSを有効にする方法について説明します。 私の知る限り、他のモバイルプラットフォームでは、HTTPSスキーム、SSLトランスポートメカニズムを有効にするだけで十分です。 Androidには、考慮して対処すべき問題がいくつかあります。 まず、安全な接続がどのように確立されるかを覚えておいてください。 赤い矢印は問題点を指します-これは証明書認証です。







プラットフォーム<Android 4.0で、HTTPSを介してネットワーク要求を実行しようとすると、SSLHandshakeExceptionがクラッシュします。 信頼できる証明書をインストールする機能は、 KeyChain APIを使用してAndroid 4.0に登場しました。 しかし、4.0以下のプラットフォームについてはどうでしょうか？ これらのプラットフォームでは、2つのオプションがあります。

1. ローカル証明書ストアを作成する
2. 証明書を信頼します。 この場合、トラフィックも暗号化されますが、中間攻撃者の脅威は残ります

ローカル証明書ストアの作成が選択された場合、作成後、次のように接続できます。



-HttpUrlConnectionの場合：

...

 TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); KeyStore keyStore = KeyStore.getInstance("BKS"); InputStream in = context.getResources().openRawResource(mykeystore); keyStore.load(in, "mysecret".toCharArray()); in.close(); tmf.init(keyStore); SSLContext sslc = SSLContext.getInstance("TLS"); sslc.init(null, tmf.getTrustManagers(),new SecureRandom());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...

-HttpClientの場合：

 private SSLSocketFactory createSslSocketFactory() { SSLSocketFactory sf = null; try { KeyStore keyStore = KeyStore.getInstance("BKS"); InputStream in = context.getResources().openRawResource(mykeystore); keyStore.load(in, "mysecret".toCharArray()); in.close(); sf = new SSLSocketFactory(keyStore); sf.setHostnameVerifier(STRICT_HOSTNAME_VERIFIER); } catch (Exception e) { e.printStackTrace(); } return sf; }.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

KeyStore.getInstance（「BKS」）を使用して、Bounce Castle KeyStore形式（暗号アルゴリズムを操作するためのJavaパッケージ）をサポートするKeyStoreオブジェクトを取得します。 mykeystore-証明書が配置されているリソースのID。

mysecret-キーストアからのパスワード。 詳細については、上記のローカル証明書ストアへのリンクを参照してください。



「任意の証明書で信頼する」を選択した場合は、次のように2つのインターフェイスを実装するだけで十分です。

 private class DummyHostnameVerifier implements HostnameVerifier{ @Override public boolean verify(String hostname, SSLSession session) { return true; } } private class DummyTrustManager implements X509TrustManager{ @Override public void checkClientTrusted(...) throws CertificateException { //empty } @Override public void checkServerTrusted(...) throws CertificateException { //empty } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、これらの実装をHttpClientまたはHttpUrlConnectionのいずれかに適用する必要があります。



バッテリーはどうですか？



バッテリー消費は、サーバーとの確立された接続の数に直接依存します。 各インストールは、バッテリー電力を消費する無線をアクティブにします。 Androidでワイヤレスラジオがどのように機能し、バッテリーの消費にどのような影響があるかについては、次の記事を読むことをお勧めします。



記事を読んだ後、使用するツール-HttpClientまたはHttpUrlConnectionを疑問に思うでしょう。 Android開発者は、新しいアプリケーションでHttpUrlConnectionを使用することをお勧めします。 使いやすく、さらに開発され、プラットフォームに適合します。 主にキープアライブ接続の重大なバグのため、Android 2.3より前のプラットフォームではHttpClientを使用する必要があります。



もちろん、モバイルアプリケーションを開発する際には、これら3つの点を考慮します。 そして、まず第一に、あなたはどう思いますか？