Androidネットワークライブラリの比較：OkHTTP、Retrofit、およびVolley
Androidを学んでいるiOS開発者からの2部構成の質問で、JSONからオーディオやビデオのストリーミングダウンロードまでのさまざまなリクエストを行うAndroidプロジェクトに取り組んでいます。
IOSでは、 AFNetworking プロジェクトを広く使用しています。 Android用の同等のライブラリはありますか？
私は OkHTTP と Retrofit Squareで Volley を読んだが、まだそれらを使った開発経験はない。私は誰かがそれぞれのための最良のユースケースのいくつかの具体的な例を提供できることを願っています。私が読んだものから、OkHTTPが3つの中で最も堅牢であり、そしてこのプロジェクトの要件を処理することができるように思えます（上で述べた）。
私は誰かがそれぞれのための最良のユースケースのいくつかの具体的な例を提供することができると思います。
Webサービスと通信している場合はRetrofitを使用してください。あなたが画像をダウンロードしているならピアライブラリーPicassoを使ってください。 Retrofit/Picasso以外の場所でHTTP操作を行う必要がある場合は、OkHTTPを使用してください。
VolleyはRetrofit + Picassoと大体競合しています。プラスの面では、それは一つの図書館です。マイナス側は、 文書化されていない サポートされていない、「壁にコードを投げかけて、その上でI | Oプレゼンテーションをする」ライブラリ。
編集 - Volleyは現在Googleによって公式にサポートされています。親切に参照してください Google開発者ガイド
私が読んだものから、OkHTTPが3つの中で最も堅牢であるように思えます
利用可能であれば、Retrofitは自動的にOkHTTPを使用します。 Jake Whartonからの要旨 はVolleyをOkHTTPに接続します。
そして（上記の）このプロジェクトの要件を処理することができます。
おそらく、「ストリーミング」の従来の定義では、「オーディオとビデオのストリーミングダウンロード」にこれらのどれも使用しないでしょう。代わりに、AndroidのメディアフレームワークがこれらのHTTPリクエストを処理します。
そうは言っても、もしあなたがあなた自身のHTTPベースのストリーミングをやろうとするなら、OkHTTPはそのシナリオを扱うべきです。私は、バレーがそのシナリオをどの程度うまく処理できるかを思い出しません。 RetrofitもPicassoもそのために設計されていません。
ここでボレーの視点を見ると、要件にいくつかの利点があります。
Volleyは、一方で、個々の小さなHTTPリクエストの処理に完全に焦点を当てています。したがって、HTTPリクエストの処理にいくつかの癖がある場合、Volleyにはおそらくフックがあります。一方、画像処理に癖がある場合、唯一の本当のフックはImageCacheです。 「それは何もありませんが、多くはありません！」しかし、リクエストを一度定義すると、フラグメントやアクティビティ内からリクエストを使用するのは、並列AsyncTasksとは違って痛みがありません
ボレーの長所と短所：
ボレーのいいところは何ですか？
ネットワークの部分は画像だけではありません。ボレーは、バックエンドの不可欠な部分であることを意図しています。単純なRESTサービスに基づく新しいプロジェクトの場合、これは大きな勝利になる可能性があります。
NetworkImageViewは、ピカソよりもリクエストのクリーンアップに積極的であり、GCの使用パターンがより保守的です。 NetworkImageViewは、強力なメモリ参照のみに依存しており、ImageViewに対して新しいリクエストが作成されるか、ImageViewが画面外に移動するとすぐに、すべてのリクエストデータをクリーンアップします。
パフォーマンス。この投稿ではこの主張を評価しませんが、彼らは明らかにメモリ使用パターンに慎重に注意を払っています。 Volleyは、コンテキスト切り替えを減らすために、メインスレッドへのコールバックをバッチ処理する努力もしています。
ボレーにも先物があるようです。興味のある方はRequestFutureをご覧ください。
高解像度の圧縮画像を扱う場合、ここでうまく機能するのはボレーだけです。
VolleyはOkhttpで使用できます（Okhttpの新しいバージョンは、パフォーマンスを向上させるためにNIOをサポートします）
ボレーはアクティビティライフサイクルでニースを演じます。
ボレーの問題：
Volleyは新しいため、まだサポートされていないものはほとんどありませんが、修正されています。
マルチパートリクエスト（解決策： https://github.com/vinaysshenoy/enhanced-volley ）
ステータスコード201はエラーと見なされ、ステータスコード200から207は正常な応答になりました（修正： https://github.com/Vinayrraj/CustomVolley ）
更新：Googleボレーの最新リリースでは、2XXステータスコードのバグは修正済みnow！Ficus Kirkpatrickに感謝します！
あまり文書化されていませんが、多くの人々がgithubでボレーをサポートしています。Javaのような文書があります here 。 Android開発者Webサイトで、 Volleyを使用したネットワークデータの送信 のガイドを見つけることができます。ボレーのソースコードは Google Git にあります。
解決/変更するには Volleyのリダイレクトポリシー フレームワークを使用 Volk with OkHTTP （前述のCommonsWare）
また、これを読むことができます ピカソとボレーの画像読み込みを比較
レトロフィット：
Square によってリリースされ、これは非常に使いやすいREST APIを提供します（更新：Voila！NIOサポート付き）
レトロフィットの長所：
Volleyと比較して、RetrofitのREST APIコードは簡潔で、優れたAPIドキュメントを提供し、コミュニティで優れたサポートを提供しています。プロジェクトへの追加は非常に簡単です。
エラー処理を備えた任意のシリアル化ライブラリで使用できます。
更新：-Retrofit 2.0.0-beta2には非常に良い変更点がたくさんあります
- okHttp 2.0を備えたRetrofitのバージョン1.6は、Okioに依存してJava.ioおよびJava.nioこれにより、ByteStringおよびBufferは、CPUとメモリを節約するための賢いことをします。 （FYI：これは KoushのOIN NIOをサポートするライブラリを思い出させます！）RxJava と組み合わせて、rxObservablesを使用してREST呼び出しを結合およびチェーン化して、いコールバックチェーン（コールバック地獄を避けるために!!）。
バージョン1.6のレトロフィットの短所：
メモリ関連のエラー処理機能は（Retrofit/OkHttpの古いバージョンでは）良くありません。Java NIOサポートを備えたOkioで改善されるかどうかはわかりません。
これを不適切な方法で使用すると、最小限のスレッド支援でコールバックが発生する可能性があります。
（上記の短所はすべて、Retrofit 2.0ベータの新しいバージョンで解決されています）
================================================== =======================
更新：
Android非同期対ボレー対レトロフィットパフォーマンスベンチマーク（ミリ秒、値が小さいほど良い）：
（Retrofit Benchmarks情報の上のFYIは、新しいバージョンのOKhttpがNIO Okioライブラリに依存しているため、Java NIOサポートで改善されます）
さまざまな繰り返し（1〜25回）を使用した3つのテストすべてで、Volleyは50％〜75％速くなりました。レトロフィットは、AsyncTasksよりも50％〜90％速い速度で動作し、同じエンドポイントに同じ回数ヒットします。ダッシュボードテストスイートでは、これはデータのロード/解析に数秒速くなりました。それは実世界での大きな違いです。テストを公平にするために、AsyncTasks/Volleyの時間には、Retrofitが自動的に行うJSON解析が含まれていました。
RetroFitがベンチマークテストで勝利！
最後に、アプリケーションにRetrofitを使用することにしました。それは途方もなく高速であるだけでなく、既存のアーキテクチャと非常によく一致します。 APIをほとんど、またはまったく労力なしでエラー処理、キャッシュ、およびページネーションを自動的に実行する親コールバックインターフェイスを作成することができました。 Retrofitにマージするには、変数を名前変更してモデルをGSON準拠にし、いくつかの簡単なインターフェイスを作成し、古いAPIから関数を削除し、AsyncTasksを使用しないようにフラグメントを変更する必要がありました。いくつかのフラグメントが完全に変換されたので、非常に簡単です。私たちが克服しなければならないいくつかの成長する痛みと問題がありましたが、全体的には順調に進みました。当初、いくつかの技術的な問題/バグに遭遇しましたが、Squareには素晴らしいGoogle+コミュニティがあり、私たちを助けてくれました。
いつVolleyを使用しますか？！
画像をロードする必要があるときにVolleyを使用できます。また、REST APIを使用する必要があります。ネットワークコールキューイングシステムは、同時に多くのn/w要求に必要です。 また、VolleyはRetrofitよりもメモリ関連のエラー処理が優れています！
OkHttpはVolleyで使用でき、RetrofitはデフォルトでOkHttpを使用します！ SPDYサポート、接続プーリング、ディスクキャッシュ、透過的な圧縮があります！最近、Okioライブラリを使用したJava NIOのサポートが追加されました。
出典、クレジット： volley-vs-retrofit by Josh Ruesch
注：ストリーミングについては、RTSP/RTCPのようにどのタイプのストリーミングが必要かによって異なります。
RoboSpice Vsボレー
からhttps://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ
- RoboSpice（RS）はサービスベースであり、VolleyよりもAndroidの哲学を尊重しています。バレーはスレッドベースであり、これはバックグラウンド処理がAndroid上で行われるべき方法ではありません。究極的には、両方のライブラリを掘り下げて、それらが非常に似ていることを見つけることができますが、バックグラウンド処理を行う私たちの方法はよりAndroid指向です。ボレーにとっては難しい（実際にはまったくありません）。
- RoboSpiceとvolleyはどちらも、優先順位付け、ポリシーの再試行、リクエストのキャンセルなどの優れた機能を提供します。しかし、RSはもっと優れたものを提供します：キャッシュ管理、リクエストの集約、保留中のリクエストへの拒否、サーバーのヘッダーに頼らずにキャッシュの有効期限を処理するなど、より高度なキャッシングです。
- RoboSpiceはUIスレッドの外でより多くのことをします：volleyはメインスレッド上であなたのPOJOをデシリアライズします。 RSを使用すると、アプリの応答性が向上します。
- スピードの面では、我々は間違いなくメトリックが必要です。今やRSは超高速になっていますが、それでもここに入れる数字はありません。 Volleyは理論的には少し速いはずですが、RSは現在非常に並列です...誰が知っているのですか？
- RoboSpiceは拡張機能との幅広い互換性を提供します。あなたはokhttp、後付け、ormlite（ベータ版）、jackson、jackson2、gson、xmlシリアライザ、google httpクライアント、春のAndroidでそれを使うことができます...かなりたくさん。 Volleyはok httpで使用でき、gsonを使用しています。それでおしまい。
- VolleyはRSよりもUIの砂糖を提供しています。 VolleyはNetworkImageViewを提供し、RSはスパイリストアダプタを提供します。機能に関してはそれほど遠くありませんが、私はVolleyがこのトピックに関してより進んでいると思います。
- RoboSpiceでは、最初のリリース以降、200を超えるバグが解決されています。かなり堅牢で、プロダクションで多用されています。 Volleyはそれほど成熟していませんが、そのユーザー基盤は急速に成長しているはずです（Googleの効果）。
- RoboSpiceはMaven Centralで入手できます。バレーボールは見つけにくいです;）
Android用AFNetworking：
Fast Android Networking Libraryは、GET、POST、DELETE、HEAD、PUT、PATCHなど、あらゆるタイプのHTTP/HTTPS要求をサポートします。
Fast Android Networking Libraryは、あらゆる種類のファイルのダウンロードをサポートしています
Fast Android Networking Libraryは、あらゆる種類のファイルのアップロードをサポートします（マルチパートアップロードをサポート）。
Fast Android Networking Libraryはリクエストのキャンセルをサポートしています
Fast Android Networking Libraryは、すべてのリクエストに対する優先順位の設定をサポートしています（LOW、MEDIUM、HIGH、IMMEDIATE）。
高速AndroidネットワーキングライブラリはRxJavaをサポート
OkHttpをネットワーク層として使用しているので、次のものをサポートします。
Fast Android Networking LibraryはHTTP/2をサポートしているため、同じホストへのすべてのリクエストでソケットを共有できます。
Fast Android Networking Libraryは接続遅延を使用してリクエストの待ち時間を短縮します（HTTP/2が利用できない場合）。
透明なGZIPはダウンロードサイズを縮小します
Fast Android Networking Libraryは、繰り返しのリクエストに対してネットワークを完全に回避するレスポンスキャッシングをサポートします。
ありがとうございます。ライブラリは私が作成しました
非同期HTTPクライアントloopjとVolley
私のプロジェクトの詳細は、1〜5分ごとの小さなHTTP RESTリクエストです。
非同期HTTPクライアント（1.4.1）を長い間使用しています。パフォーマンスは、Vanilla Apache httpClientまたはHTTP URL接続を使用するよりも優れています。とにかく、ライブラリの新しいバージョンは私のために働いていません：コールバックのライブラリインター例外カットチェーン。
すべての答えを読むことは私に何か新しいことをやる気にさせました。私はVolley HTTPライブラリを選びました。
テストしなくてもしばらく使用した後、応答時間が1.5倍、2倍のVolleyに低下していることがわかります。
たぶんRetrofitは非同期HTTPクライアントよりも優れていますか？試してみる必要があります。しかし、私はバレーボールが私のためではないと確信しています。
私のVolleyでの経験からの議論に少し追加するだけです。
Volleyはストリーミングのアップロードやダウンロードをいかなる意味でも処理しません。つまり、リクエストボディ全体をメモリ内に配置する必要があり、基本的な
OutputStreamのように、リクエストボディを基になるソケットに書き込むためにInputStreamを使用することも、レスポンスボディを読み取るためにHttpURLConnectionを使用することもできません。そのため、Volleyは大きなファイルをアップロードまたはダウンロードするには適していません。あなたの要求と応答は小さいはずです。これは私が個人的に遭遇したバレーボールの最大の制限の1つです。その価値のために、OkHttpはストリームを操作するためのインターフェースを持っています。公式ドキュメントがないのは厄介ですが、私はソースコードを読むことでそれを回避することができました。私が言うことができる限り、Volleyには正式なリリースバージョンもMavenやGradleのアーティファクトもないので、依存関係として管理することは、たとえばSquareがリリースしたライブラリよりも頭痛の種になることです。 。レポジトリを複製してjarファイルを作成するだけです。バグ修正をお探しですか？取得し、それがあることを願っています。あなたは他のものも手に入れるかもしれません。それは文書化されません。私の意見では、これは事実上、コードベースがかなりアクティブであっても、Volleyがサポートされていないサードパーティライブラリであることを意味します。買い手責任負担。
言い換えれば、Content-Typeをクラス/要求タイプ（JsonObjectRequest、ImageRequestなど）に結び付けることは一種の厄介であり、あなたがVolleyの既存のRequestタイプ階層に縛られているので、呼び出しコードの柔軟性を少し低下させます。私は他のものと同じように単にContent-Typeをヘッダーとして設定することの単純さが好きです（ところで、これをVolleyでやらないでください;あなたは2つのContent-Typeヘッダーで終わるでしょう！）それは私の個人的な意見ですが、回避することができます。
それはVolleyがいくつかの便利な機能を持っていないということではありません。確かにそうです。簡単にカスタマイズ可能な再試行ポリシー、透過的なキャッシング、キャンセルAPI、そしてリクエストスケジューリングと同時接続のサポートは素晴らしい機能です。それがすべてのHTTPユースケースを対象としているわけではないこと（上記の項目1を参照）、そしてあなたのアプリでVolleyを本番用に使用することに関わる頭痛があることを知ってください（項目2）。
私は最近 ion と呼ばれるライブラリを見つけました。
ionはImageView、JSON（GSONの助けを借りて）、ファイルおよび非常に便利なUIスレッドサポートと統合された画像ダウンロードのための組み込みサポートを持っています。
私は新しいプロジェクトでそれを使っています、そしてこれまでのところ結果は良いものでした。その使用はバレーボールや改装よりもはるかに簡単です。
受け入れられた答えとLOG_TAGが言ったことに加えて...バックグラウンドスレッドであなたのデータをパースするためにあなたはメインスレッドでonResponseメソッドが呼び出されるのでRequest<YourClassName>をサブクラス化しなければなりません。あなたの反応は大きいです。その方法については ここ を読んでください。
レトロフィット1.9.0 vs. RoboSpice
私は自分のアプリで両方を使用しています。
Robospiceは、入れ子になったJSONクラスを解析するたびにRetrofitよりも速く動作します。 Spice Mangerがあなたのために全力を尽くすからです。 Retrofitでは、GsonConverterを作成してそれを逆シリアル化する必要があります。
同じアクティビティで2つのフラグメントを作成し、2つの同じ種類のURLで同じ時間に呼び出しました。
09-23 20:12:32.830 16002-16002/com.urbanpro.seeker E/RETROFIT﹕ RestAdapter Init
09-23 20:12:32.833 16002-16002/com.urbanpro.seeker E/RETROFIT﹕ calling the method
09-23 20:12:32.837 16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ initialzig spice manager
09-23 20:12:32.860 16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ Executing the method
09-23 20:12:33.537 16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ on SUcceess
09-23 20:12:33.553 16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ gettting the all contents
09-23 20:12:33.601 16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation starts
09-23 20:12:33.603 16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation ends
そしてさらに別の選択肢： https://github.com/apptik/jus
- それはVolleyのようなモジュール式ですが、より拡張されたドキュメントは改良され、箱から出してさまざまなHTTPスタックとコンバータをサポート
- RetrofitのようなサーバーAPIインターフェースマッピングを生成するモジュールがあります。
- JavaRxもサポートしています
そして、マーカー、変圧器などのような他の多くの便利な機能.