ここでボレーの視点を見ると、要件にいくつかの利点があります。
一方、Volleyは、個別の小さなHTTPリクエストの処理に完全に集中しています。したがって、HTTPリクエストの処理に問題がある場合、Volleyはおそらくフックを持っています。一方、画像処理に癖がある場合、唯一の実際のフックはImageCacheです。「それは何でもない、しかし多くではない！」。しかし、リクエストを定義すると、並列AsyncTasksとは異なり、フラグメントまたはアクティビティ内からそれらを使用するのは簡単です。
ボレーの長所と短所：
では、ボレーの何がいいのでしょうか？
ネットワーキングの部分は、画像だけのものではありません。Volleyは、バックエンドの不可欠な部分になることを目的としています。単純なRESTサービスに基づく新しいプロジェクトの場合、これは大きな利益になる可能性があります。
NetworkImageViewは、ピカソよりもリクエストのクリーンアップに積極的で、GCの使用パターンはより保守的です。NetworkImageViewは強力なメモリ参照のみに依存しており、ImageViewに対して新しいリクエストが行われるとすぐに、またはそのImageViewが画面外に移動するとすぐに、すべてのリクエストデータをクリーンアップします。
パフォーマンス。この投稿ではこの主張を評価しませんが、メモリ使用パターンに慎重になるように注意を払っています。Volleyはまた、メインスレッドへのコールバックをバッチ処理して、コンテキストの切り替えを減らす努力もしています。
ボレーにも先物があるらしい。興味がある場合は、RequestFutureをチェックしてください。
高解像度の圧縮画像を処理している場合、Volleyはここで機能する唯一のソリューションです。
VolleyはOkhttpで使用できます（Okhttpの新バージョンはパフォーマンス向上のためにNIOをサポートしています）
Volleyは、Activityライフサイクルを適切に処理します。
Volleyの問題：
Volleyは新しいため、まだサポートされていないものもありますが、修正されています。
マルチパートリクエスト（ソリューション：https : //github.com/vinaysshenoy/enhanced-volley）
ステータスコード201はエラーとして扱われ、ステータスコード200から207は正常に応答するようになりました（修正：https : //github.com/Vinayrraj/CustomVolley）
更新： Googleボレーの最新リリースで、2XXステータスコードのバグが修正されました！フィカスカークパトリックに感謝します！
あまりドキュメント化されていませんが、多くの人がgithubでボレーをサポートしています。Javaのようなドキュメントはここにあります。Android開発者のWebサイトに、Volleyを使用したネットワークデータの送信に関するガイドがあります。そしてボレーのソースコードはGoogle Gitで見つけることができます
Volley Frameworkのリダイレクトポリシーを解決または変更するには、VolleyをOkHTTPで使用 します（上記のCommonsWare）
また、ピカソとのこの比較ボレーの画像の読み込みを読むことができます
後付け：
Squareからリリースされました。これは非常に使いやすいREST APIを提供します（更新：NIOサポート付きのVoila！）
後付けの長所：
更新：
-Retrofit 2.0.0-beta2には多くの非常に優れた変更があります。
- OkHttp 2.0とレトロフィットのバージョン1.6は今に依存しているOkioサポートするために、java.ioとjava.nioの、アクセスがはるかに容易になりますストアと使用してデータを処理バイト文字列をし、バッファ CPUとメモリを節約するためにいくつかの巧妙な事をします。（FYI：これはのことを思い出すKoushのOINの！NIOをサポートしているライブラリ）
私たちは、使用することができますRxJavaと一緒にレトロフィットを組み合わせて、チェーンRESTは、使用して呼び出すrxObservablesを醜いコールバックチェーンを避けるために（回避コールバック地獄に!!） 。
バージョン1.6のレトロフィットの短所：
（上記の短所はすべてRetrofit 2.0ベータの新バージョンで解決されています）
================================================== ======================
更新：
Android Async vs Volley vs Retrofitパフォーマンスベンチマーク（ミリ秒、値が小さいほど優れています）：
（OKFの新しいバージョンはNIO Okioライブラリに依存しているため、レトロフィットベンチマーク情報を超えるFYIはjava NIOサポートで改善されます）
さまざまな繰り返し（1〜25回）の3つのテストすべてで、ボレーは50％から75％高速でした。レトロフィットは、AsyncTasksよりも50％から90％も速く、同じエンドポイントに同じ回数ヒットしました。ダッシュボードのテストスイートでは、これによりデータの読み込み/解析が数秒速くなりました。これは、実際の大きな違いです。テストを公平にするために、Retrofitが自動的に行うように、AsyncTasks / Volleyの時間にはJSON解析が含まれていました。
RetroFitがベンチマークテストで勝利！
最終的に、私たちはアプリケーションにレトロフィットを採用することにしました。途方もなく高速であるだけでなく、既存のアーキテクチャと非常によく一致します。APIをほとんど、またはまったく操作せずに、エラー処理、キャッシュ、ページ付けを自動的に実行する親のCallback Interfaceを作成できました。Retrofitでマージするには、変数の名前を変更してモデルをGSON準拠にし、いくつかのシンプルなインターフェースを記述し、古いAPIから関数を削除し、AsyncTasksを使用しないようにフラグメントを変更する必要がありました。いくつかのフラグメントが完全に変換されたので、かなり簡単です。私たちが克服しなければならないいくつかの成長する苦痛と問題がありましたが、全体的にそれはスムーズに行きました。初めにいくつかの技術的な問題やバグに遭遇しましたが、Squareには素晴らしいGoogle+コミュニティがあり、それを介して私たちを助けることができました。
いつボレーを使うの？！
画像の読み込みやREST APIの利用が必要な場合はVolleyを使用できます！多くのn / wリクエストに同時にネットワークコールキューイングシステムが必要です！また、VolleyはRetrofitよりもメモリ関連のエラー処理が優れています。
OkHttpはVolleyで使用でき、RetrofitはデフォルトでOkHttpを使用します！それは持ってSPDYサポート、接続プーリング、ディスクキャッシュ、透明な圧縮を！最近、それが持つJava NIOのいくつかのサポートを持っているOkioのライブラリ。
出典、クレジット：Josh Ruesch氏によるvolley-vs-retrofit
注：ストリーミングについては、RTSP / RTCPのように、どのタイプのストリーミングが必要かによって異なります。