一、简介
Volley请求网络 是基于请求队列的，只要把请求放入请求队列就可以了。
Voller底层封装的是HttpUrlConnection，支持图片加载，网络请求排序，优先级处理，缓存，与Activity生命周期联动。扩展性好，支持httpclient，HttpUrlConnection，OkHttp，在频繁请求和加载数据量少的时候优势，不适合大数据加载.
使用、源码详解：见郭霖博客：https://blog.csdn.net/guolin_blog/article/details/17482095/
二、适合场景
适合场景：数据量小、频率高的请求。但是为什么呢？（Read the fucking source code！）
首先，数据量小：
1. Volley的网络请求线程池默认大小为4。意味着可以并发进行4个请求，大于4个，会排在队列中。
2. Request.getBody() 方法返回byte[]类型，作为 Http.POST 和 Http.PUT body 中的数据。这就意味着需要把用 http 传输的数据一股脑读取到内存中。如果文件过大，内存会爆！
Response也是使用byte数组存储数据，大数据=大数组，消耗内存
考虑这样一个场景:
你同时上传4个文件，这四个文件都很大，这时候：a.你的内存占用就很高，很容易oom。b.这时候，你再发网络请求，所有的网络线程都被上传文件的任务占满了，你的网络请求只有在文件上传完毕后才能得到执行。体验就是，很慢！
所以Volley适合数据量小的请求。
然后，频率高：
ByteArrayPool产生背景
根据类名，知道这是一个字节数组缓存池。没错，就是用来缓存 网络请求获得的数据。 当网络请求得到返回数据以后，我们需要在内存开辟出一块区域来存放我们得到的网络数据，不论是json还是图片，都会存在于内存的某一块区域，然后拿到UI显示，然而客户端请求是相当频繁的操作，想一下我们平时使用知乎等一些客户端，几乎每一个操作都要进行网络请求（虽然知乎大部分是WebView）。那么问题来了：这么频繁的数据请求，获得数据以后我们先要在堆内存开辟存储空间，然后显示，等到时机成熟，GC回收这块区域，如此往复，那么GC的负担就相当的重，然而Android客户端处理能力有限，频繁GC对客户端的性能有直接影响。我们能不能减少GC和内存的分配呢？我想这个问题就是这个类的产生背景。
ByteArrayPool利用getBuf和returnBuf以及mBuffersByLastUse和mBuffersBySize完成字节数组的缓存。当需要使内存区域的时候，先从已经分配的区域中获得以减少内存分配次数。当空间用完以后，在将数据返回给此缓冲区。这样，就会减少内存区域堆内存的波动和减少GC的回收，让CPU把更多的性能留给页面的渲染，提高性能。