从我与Volley合作的经验来看，我想补充一点:

Volley does not handle streaming uploads or downloads in any sense. That is, the entire request body has to be in memory and you cannot use an OutputStream to write the request body to the underlying socket, nor can you use an InputStream to read the response body, as basic HttpURLConnection does. So, Volley is a poor choice for uploading or downloading large files. Your requests and responses should be small. This is one of the biggest limitations of Volley that I have personally encountered. For what it's worth, OkHttp does have interfaces for working with streams. The lack of official documentation is annoying, although I have been able to work around that by reading the source code, which is pretty easy to follow. What is more bothersome is that, as far as I can tell, Volley has no official release versions and no Maven or Gradle artifact, and therefore managing it as a dependency becomes more of a headache than, say, any of the libraries Square has released. You just clone a repo, build a jar, and you're on your own. Looking for a bug fix? Fetch and hope it's there. You might get some other stuff, too; it won't be documented. In my opinion, this effectively means that Volley is an unsupported 3rd party library, even though the code base is reasonably active. Caveat emptor. As a nit, having the Content-Type tied to the class/request type (JsonObjectRequest, ImageRequest, etc.) is kind of awkward and reduces the flexibility of the calling code a bit, as you are tied to Volley's existing Request type hierarchy. I like the straightforwardness of just setting Content-Type as a header like any other (don't do this with Volley, by the way; you'll end up with two Content-Type headers!). That's just my personal opinion, though, and it can be worked around.

这并不是说Volley没有一些有用的功能。的确如此。易于定制的重试策略、透明缓存、取消API以及对请求调度和并发连接的支持都是很棒的特性。但是要知道它并不适用于所有的HTTP用例(参见上面的第1项)，而且在应用程序中将Volley投入生产使用(第2项)会有一些令人头疼的问题。

异步HTTP客户端loopj vs. Volley

我的项目的细节是小的HTTP REST请求，每1-5分钟一次。

我使用异步HTTP客户端(1.4.1)很长一段时间。性能优于使用普通的Apache httpClient或HTTP URL连接。无论如何，新版本的库不适合我:库内部异常切断回调链。

阅读所有的答案激励我尝试一些新的东西。我选择了Volley HTTP库。

使用一段时间后，即使没有测试，我清楚地看到，响应时间下降到1.5倍，2倍的排射。

也许Retrofit比异步HTTP客户端更好?我得试试。 但我确定Volley不适合我。

从我与Volley合作的经验来看，我想补充一点:

Volley does not handle streaming uploads or downloads in any sense. That is, the entire request body has to be in memory and you cannot use an OutputStream to write the request body to the underlying socket, nor can you use an InputStream to read the response body, as basic HttpURLConnection does. So, Volley is a poor choice for uploading or downloading large files. Your requests and responses should be small. This is one of the biggest limitations of Volley that I have personally encountered. For what it's worth, OkHttp does have interfaces for working with streams. The lack of official documentation is annoying, although I have been able to work around that by reading the source code, which is pretty easy to follow. What is more bothersome is that, as far as I can tell, Volley has no official release versions and no Maven or Gradle artifact, and therefore managing it as a dependency becomes more of a headache than, say, any of the libraries Square has released. You just clone a repo, build a jar, and you're on your own. Looking for a bug fix? Fetch and hope it's there. You might get some other stuff, too; it won't be documented. In my opinion, this effectively means that Volley is an unsupported 3rd party library, even though the code base is reasonably active. Caveat emptor. As a nit, having the Content-Type tied to the class/request type (JsonObjectRequest, ImageRequest, etc.) is kind of awkward and reduces the flexibility of the calling code a bit, as you are tied to Volley's existing Request type hierarchy. I like the straightforwardness of just setting Content-Type as a header like any other (don't do this with Volley, by the way; you'll end up with two Content-Type headers!). That's just my personal opinion, though, and it can be worked around.

这并不是说Volley没有一些有用的功能。的确如此。易于定制的重试策略、透明缓存、取消API以及对请求调度和并发连接的支持都是很棒的特性。但是要知道它并不适用于所有的HTTP用例(参见上面的第1项)，而且在应用程序中将Volley投入生产使用(第2项)会有一些令人头疼的问题。

看看Volley透视图，这里有一些适合您需求的优点:

一方面，Volley完全专注于处理单个的小HTTP请求。因此，如果您的HTTP请求处理有一些怪癖，Volley可能为您提供了一个钩子。另一方面，如果您在图像处理方面有一个怪癖，那么您拥有的唯一真正的钩子就是ImageCache。“不是没有，但也不多!””。但它有更多的其他优点，比如一旦你定义了你的请求，从一个片段或活动中使用它们是轻松的，不像并行AsyncTasks

Volley的优点和缺点:

那么Volley的优点是什么呢?

The networking part isn’t just for images. Volley is intended to be an integral part of your back end. For a fresh project based off of a simple REST service, this could be a big win. NetworkImageView is more aggressive about request cleanup than Picasso, and more conservative in its GC usage patterns. NetworkImageView relies exclusively on strong memory references, and cleans up all request data as soon as a new request is made for an ImageView, or as soon as that ImageView moves offscreen. Performance. This post won’t evaluate this claim, but they’ve clearly taken some care to be judicious in their memory usage patterns. Volley also makes an effort to batch callbacks to the main thread to reduce context switching. Volley apparently has futures, too. Check out RequestFuture if you’re interested. If you’re dealing with high-resolution compressed images, Volley is the only solution here that works well. Volley can be used with Okhttp (New version of Okhttp supports NIO for better performance ) Volley plays nice with the Activity life cycle.

截击的问题: 由于Volley是新的，一些东西还不支持，但它是固定的。

Multipart Requests (Solution: https://github.com/vinaysshenoy/enhanced-volley) status code 201 is taken as an error, Status code from 200 to 207 are successful responses now.(Fixed: https://github.com/Vinayrraj/CustomVolley) Update: in latest release of Google volley, the 2XX Status codes bug is fixed now!Thanks to Ficus Kirkpatrick! it's less documented but many of the people are supporting volley in github, java like documentation can be found here. On android developer website, you may find guide for Transmitting Network Data Using Volley. And volley source code can be found at Google Git To solve/change Redirect Policy of Volley Framework use Volley with OkHTTP (CommonsWare mentioned above)

你也可以阅读这比较Volley的图像加载与毕加索

改造:

它是由Square发布的，它提供了非常容易使用的REST API(更新:瞧!蔚来汽车支持)

改造的优点:

与Volley相比，Retrofit的REST API代码更简洁，并提供了 优秀的API文档，在社区中有很好的支持! 它很容易添加到项目中。 我们可以将它用于任何序列化库，并进行错误处理。

更新:

There are plenty of very good changes in Retrofit 2.0.0-beta2 version 1.6 of Retrofit with OkHttp 2.0 is now dependent on Okio to support java.io and java.nio which makes it much easier to access, store and process your data using ByteString and Buffer to do some clever things to save CPU and memory. (FYI: This reminds me of the Koush's OIN library with NIO support!) We can use Retrofit together with RxJava to combine and chain REST calls using rxObservables to avoid ugly callback chains (to avoid callback hell!!).

版本1.6的缺点:

内存相关的错误处理功能不太好(在旧版本的Retrofit/OkHttp中)，不确定它是否在Java NIO支持的Okio中得到了改进。 如果我们使用这个方法，最小的线程帮助可能导致回调地狱 以不恰当的方式

(以上所有缺点都在新版本的Retrofit 2.0 beta中得到解决)

========================================================================

更新:

Android Async vs Volley vs Retrofit性能基准(毫秒，值越低越好):

(供参考，上面的改装基准信息将改善java NIO支持，因为新版本的OKhttp依赖于NIO Okio库)

In all three tests with varying repeats (1 – 25 times), Volley was anywhere from 50% to 75% faster. Retrofit clocked in at an impressive 50% to 90% faster than the AsyncTasks, hitting the same endpoint the same number of times. On the Dashboard test suite, this translated into loading/parsing the data several seconds faster. That is a massive real-world difference. In order to make the tests fair, the times for AsyncTasks/Volley included the JSON parsing as Retrofit does it for you automatically. RetroFit Wins in benchmark test! In the end, we decided to go with Retrofit for our application. Not only is it ridiculously fast, but it meshes quite well with our existing architecture. We were able to make a parent Callback Interface that automatically performs error handling, caching, and pagination with little to no effort for our APIs. In order to merge in Retrofit, we had to rename our variables to make our models GSON compliant, write a few simple interfaces, delete functions from the old API, and modify our fragments to not use AsyncTasks. Now that we have a few fragments completely converted, it’s pretty painless. There were some growing pains and issues that we had to overcome, but overall it went smoothly. In the beginning, we ran into a few technical issues/bugs, but Square has a fantastic Google+ community that was able to help us through it.

什么时候使用凌空?!

当我们需要加载图像以及使用REST api时，我们可以使用Volley !，网络呼叫排队系统需要同时处理多个n/w请求!Volley也有更好的内存相关错误处理比Retrofit!

OkHttp可以使用Volley, Retrofit默认使用OkHttp !它有SPDY支持，连接池，磁盘缓存，透明压缩!最近，它通过Okio库获得了java NIO的一些支持。

来源:Josh Ruesch先生的volley-vs-retrofit

注意:关于流，它取决于你想要什么类型的流，比如RTSP/RTCP。

我希望有人能够为每种方法提供一些最佳用例的具体示例。

如果您正在与Web服务通信，请使用Retrofit。如果您正在下载图像，请使用毕加索对等库。如果需要在Retrofit/Picasso之外执行HTTP操作，请使用OkHTTP。

Volley与Retrofit + Picasso大致竞争。好的方面是，它是一个库。缺点是，它是一个没有文档的、不受支持的、“把代码扔到墙上，然后在上面做一个I|O演示”的库。

编辑-排射现在正式支持谷歌。请参考谷歌开发者指南

据我所知，OkHTTP似乎是这三个中最健壮的

如果可以，Retrofit会自动使用OkHTTP。杰克·沃顿有个要点能把Volley和OkHTTP联系起来。

并能处理这个项目的要求(如上所述)。

根据“流媒体”的传统定义，你可能不会使用它们中的任何一个来“流式下载音频和视频”。相反，Android的媒体框架将为你处理这些HTTP请求。

也就是说，如果您打算尝试自己的基于http的流，OkHTTP应该处理这种情况;我不记得Volley会如何处理这种情况。无论是Retrofit还是Picasso都不是为此而设计的。

RoboSpice Vs. Volley

从https://groups.google.com/forum/ # !主题/ robospice / QwVCfY_glOQ

RoboSpice(RS) is service based and more respectful of Android philosophy than Volley. Volley is thread based and this is not the way background processing should take place on Android. Ultimately, you can dig down both libs and find that they are quite similar, but our way to do background processing is more Android oriented, it allow us, for instance, to tell users that RS is actually doing something in background, which would be hard for volley (actually it doesn't at all). RoboSpice and volley both offer nice features like prioritization, retry policies, request cancellation. But RS offers more : a more advanced caching and that's a big one, with cache management, request aggregation, more features like repluging to a pending request, dealing with cache expiry without relying on server headers, etc. RoboSpice does more outside of UI Thread : volley will deserialize your POJOs on the main thread, which is horrible to my mind. With RS your app will be more responsive. In terms of speed, we definitely need metrics. RS has gotten super fast now, but still we don't have figure to put here. Volley should theoretically be a bit faster, but RS is now massively parallel... who knows ? RoboSpice offers a large compatibility range with extensions. You can use it with okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android... Quite a lot. Volley can be used with ok http and uses gson. that's it. Volley offers more UI sugar that RS. Volley provides NetworkImageView, RS does provide a spicelist adapter. In terms of feature it's not so far, but I believe Volley is more advanced on this topic. More than 200 bugs have been solved in RoboSpice since its initial release. It's pretty robust and used heavily in production. Volley is less mature but its user base should be growing fast (Google effect). RoboSpice is available on maven central. Volley is hard to find ;)