为什么使用volley？？？

避开HttpUrlConnection 和HttpClient

在较低的api版本中（多数是在Gingerbread和Froyo中），HttpUrlConnection和HttpClient 远未达到完美。有一些已知的问题  和bugs 一直未被修复，HttpClient 自上次api更新（API 22）之后就已经过时，意味着不再维护，后续可能也会被移除。

这就是需要转到一个更稳定的处理网络请求的方法的主要原因。

避开AsyncTask

自从引入Honeycomb(API 11)以来，系统强制网络操作必须运行在单独的线程中，UI线程之外。这个重大的变化导致AsyncTask<Params, Progress, Result> 的大量使用。

要使用AsyncTask，首先你得在onPreExecute做一些准备工作，比如定义context。然后在doInBackground 方法中执行后台任务，最后在onPostExecute中处理结果。这要比实现service更简单直接，因此有大量的例子和文章出现。

但是AsyncTask的主要问题是调用的顺序。你无法决定哪个请求走在最前面，哪个请求必须等待，所有的请求都是按照先进先出的顺序，FIFO。

在某些情况下，问题就出来了，比如当你需要加载一个item中带有图片的列表。当用户向下滚动想获得新的数据时，你无法告诉Activity先加载下一页的json数据，只有慢慢等待上一页的图片加载完。对于像facebook和Twiitter这种item数据的重要性远大于相关图片的应用来说，这会导致严重的用户体验问题。

Volley用其强大的cancellation api解决了这个问题。当调用的时候，你不再需要在onPostExecute中检查Activity是否被销毁。这帮助我们避免了不想要的NullPointerException。

它速度更快

前些时候，Google+团队针对每种可以使用的网络请求方式做了一些列的性能测试。当应用在RESTful 风格的应用中时，Volley的得分比其他候选方法高近10倍。

它可以缓存所有东西

Volley可以自动缓存请求，这点确实是关乎生死的问题。让我们暂时回到上面所提到的那个例子。你有一个item的列表 -  假设是JSON 数组 -  并且每个item都包括一段描述和一个缩略图。现在设想一下用户旋转屏幕之后会发生的事情：activity销毁，列表重新加载，同样的还有图片。长话短说就是：严重的资源浪费以及糟糕的用户体验。

事实证明，Volley在克服这种困难中是相当有用的。它可以记住前一个调用同时处理Activity的销毁与重建。它缓存所有的东西，这点你也不用担心。

Small Metadata Operations

Volley在轻量级的调用中堪称完美，比如请求JSON对象，或者列表的一部分，或者被选中item的详情等等。它是为RESTful应用设计的，在这种特定场景下可以发挥自己最好的优势。

但是当把它应用在数据流或者大文件下载中，就不是那么好了。