Volley是一个应用广泛的网络请求开源框架，由Google于2013年推出，它可扩展性性强，适合于数据量小，请求频繁的网络请求，用来加载网络图片也很方便，GitHub地址：https://github.com/google/volley。
关于Volley的使用介绍和源码解析，网络资料很多，这里就不再写了，可参考：
想看框架原理：Volley 源码解析
更详细的从使用到源码解析：郭霖的《Volley全解析》
本篇文章主要是记录一下我在使用及读Volley源码时的一些问题的思考，包括以下问题：
一、volley的并发请求是怎么实现的
二、线程里的while无限循环不会影响性能吗？
三、Request的优先级是怎么处理的？
四、为什么没有用线程池来处理请求？
五、有些Request会被放到一个等待的Map里(RequestQueue里的mWaitingRequests这个Map)，它的作用是什么？
六、对响应的处理是怎么切换回主线程的？
七、Volley对HTTP的304响应是怎么处理的？
八、为什么Volley不适合数据量大的场景？
九、可缓存的网络请求结果，是以什么为key进行保存的？
一、volley的并发请求是怎么实现的
Volley维护了一个缓存调度线程CacheDispatcher和 n 个网络调度线程NetworkDispatcher，这里 n 默认为 4。
Volley会根据Request是否可缓存，确定该Request是发起网络请求来处理，还是从缓存里直接得到结果（是否可缓存，可以在构造每个Request的时候自行定义）。
缓存调度线程的run()方法是一个while(true)无限循环，不断从缓存请求队列中取出 Request去处理（尝试从缓存中拿结果，如果拿不到结果，或者结果数据已经过期，则把Request放到网络请求队列里）。
网络调度线程的run()方法也是while(true)无限循环，不断从网络请求队列取出Request去处理。这样就实现了并发请求。
二、线程里的while无限循环不会影响性能吗？
这里就要介绍下，Volley使用的缓存请求队列和网络请求队列都是无界有序的阻塞队列（PriorityBlockingQueue），它的特点就是从队列里取元素的时候，如果队列为空，则调用此方法的线程会挂起，直至队列有元素可取，线程才会继续运行。同样放入元素的时候，如果队列满了也会挂起，直至队列有空间可放（但是PriorityBlockingQueue是无最大限制的，所以不会满）。
所以如果队列里的请求都处理完了，线程就都会处于挂起状态，而不会继续循环运行。
另外，PriorityBlockingQueue是线程安全的，所以不必担心n个线程都会从网络请求队列里取Request的同步问题。
三、Request的优先级是怎么处理的？
同样用到了PriorityBlockingQueue。
Request类实现了Comparable接口并实现了这个接口的compareTo(Request other)方法，用以比较各个Request的优先级。
在把每个Request加入PriorityBlockingQueue的时候，就会自动根据这个Request的优先级加入队列合适的位置，这也是PriorityBlockingQueue的特点之一。
而从队列取出Request的时候，都是从队列头部取出的，所以取出的就是优先级最高的。
Volley默认对Request划分了四种优先级。
public enum Priority {
LOW,
NORMAL,
HIGH,
IMMEDIATE
}
Request比较优先级的时候先比较Priority属性，如果相同再比较它的mSequence属性。
默认每个Request的优先级都是Priority.NORMAL，可以自行设定。
四、为什么没有用线程池来处理请求？
一个说法是，Volley默认用到了四个线程来同时处理网络请求，其实就是线程池的作用了。这样的好处是避免了创建线程和回收线程的开销，毕竟网络请求的开销基本上要大于消息队列的处理，这样可以提高性能。
但是我觉得用线程池的好处就是，线程池会根据请求数量，动态增加或者减少线程数，而用Volley的做法，如果短时间来了很多请求的话，也只能处理几个，其他的都得排队等待，短时间无法得到响应。网上有很多人也实现了用线程池的Volley版本，例如下面。
ThreadPoolExecutor threadPoolExecutor = ThreadPoolExecutor)Executors.newFixedThreadPool(mDispatchers.length);
// Create network dispatchers (and corresponding threads) up to the pool size.
for (int i = 0; i < mDispatchers.length; i++) {
NetworkDispatcher networkDispatcher = new NetworkDispatcher(mNetworkQueue, mNetwork,
mCache, mDelivery);
mDispatchers[i] = networkDispatcher;
threadPoolExecutor.submit(networkDispatcher);
//networkDispatcher.start();
}
五、有些Request会被放到一个等待的Map里(RequestQueue里的mWaitingRequests这个Map)，它的作用是什么？
先回答，这个Map的作用是，避免同样的Request重复进行网络请求。
详细来说，如果放入缓存请求队列里的好几个Request都是同样的请求，但是缓存里还拿不到数据，按优先级，先拿出来的那个Request就会先被放到网络请求队列里去执行，因为网络请求的结果可能得一会才能返回并存入缓存，在这期间，缓存请求队列的其他几个相同的Request可能都会被到网络请求队列里去执行了，这就产生了多个不必要的网络请求，浪费了资源。
而用了这个等待Map，如果有重复的网络请求，之前一个正在处理中，后面来的，就会被暂时放入这个Map里。在这个Map里，key就是Request的URL，相同URL的Request都处于同一个队列元素里。（这个Map类型是HashMap<String, Queue<Request<?>>>）。最先的Request被处理完成之后，后面重复的Request会直接从缓存里拿数据。
更详细的源码分析，如下，可以略过。
————————————————
每来一个新的Request，是这样处理的：
先判断是否可缓存。如果不可缓存，就放到网络请求队列里去执行。
如果可缓存，再判断这个Map里是否含有以这个Request的URL为key的键值对。
第一次肯定是没有这个key的，那Map就会添加这个键值对，key就是这个Request的url，对应的value为null。同时把这个Request放到缓存队列里去执行。
这时如果有同样的Request再来时（请求的URL是一样的），这时这个Map里已经有了这个key，那么就会创建新的Queue作为key对应的value，并在Queue里放入这个Request。
再有同样的Request来，直接会放到这个Queue里。
上面的3~5步，看代码更清楚，在RequestQueue的add()方法：
if (mWaitingRequests.containsKey(cacheKey)) {
// There is already a request in flight. Queue up.
Queue<Request<?>> stagedRequests = mWaitingRequests.get(cacheKey);
if (stagedRequests == null) {
// 上面的第4步
stagedRequests = new LinkedList<Request<?>>();
}
// 第4，第5步都会到这里
stagedRequests.add(request);
mWaitingRequests.put(cacheKey, stagedRequests);
} else {
// 上面的第3步
mWaitingRequests.put(cacheKey, null);
mCacheQueue.add(request);
}
那么这个mWaitingRequests什么时候会把添加的元素移除呢？
每个Request完成以后，等待Map会根据判断它是否含有这个Request的url对应的key，如果有的话，就把key对应的value（也就是处于等待状态的请求队列Queue）从Map移除，并添加到缓存请求队列里去处理。此流程见下RequestQueue的finish()方法：
if (request.shouldCache()) {
synchronized (mWaitingRequests) {
String cacheKey = request.getCacheKey();
Queue<Request<?>> waitingRequests = mWaitingRequests.remove(cacheKey);
if (waitingRequests != null) {
// Process all queued up requests. They won't be considered as in flight, but
// that's not a problem as the cache has been primed by 'request'.
mCacheQueue.addAll(waitingRequests);
}
}
}
六、对响应的处理是怎么切换回主线程的？
我们已知Volley的网络请求和缓存处理都是在子线程，那么处理完成后，得到的结果会交给一个结果传递器来处理，这个传递器是在一开始构造RequestQueue的时候，传入构造方法的：
public RequestQueue(Cache cache, Network network, int threadPoolSize) {
this(cache, network, threadPoolSize, new ExecutorDelivery(new Handler(Looper.getMainLooper())));
}
从new Handler(Looper.getMainLooper())可以知道，这个handler是主线程的handler。在每个Request完成之后，结果会包装成Runnable对象，传入这个handler的post方法里进行处理。
七、Volley对HTTP的304响应是怎么处理的？
http的304状态码的含义是：
如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not
Changed.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而
保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。
在Volley的流程里，如果网络请求返回304，就直接使用缓存的数据作为结果，然后结束这个请求。
NetworkDispatcher的run()方法：
public void run() {
...
NetworkResponse networkResponse = mNetwork.performRequest(request);
request.addMarker("network-http-complete");
// 如果是304并且已经将缓存分发出去里，就直接结束这个请求
if (networkResponse.notModified && request.hasHadResponseDelivered()) {
request.finish("not-modified");
continue;
}
...
}
}
下面是BasicNetwork.performRequest()里的相关处理：
if (statusCode == HttpStatus.SC_NOT_MODIFIED) { //SC_NOT_MODIFIED即304
return new NetworkResponse(HttpStatus.SC_NOT_MODIFIED,
request.getCacheEntry().data, responseHeaders, true);
}
八、为什么Volley不适合数据量大的场景？
http传输的数据，不管是发起请求的数据，还是得到的数据，都是会读取到内存中。那么如果几个线程同时访问数据量大的请求，就容易OOM了。
九、可缓存的网络请求结果，是以什么为key进行保存的？
从上面的分析我们已经知道，如果我们设置一个请求是可以从缓存里拿结果的，那就会优先从缓存里拿结果。网络请求的方式有GET, POST等多种，如果是POST，那么提交的参数可能是不一样的，那请求结果是怎么保存的呢？
我们来看下Request类里的getCacheKey()，即获取保存的数据的Key:
/** Returns the cache key for this request. By default, this is the URL. */
public String getCacheKey() {
String url = getUrl();
// If this is a GET request, just use the URL as the key.
// For callers using DEPRECATED_GET_OR_POST, we assume the method is GET, which matches
// legacy behavior where all methods had the same cache key. We can't determine which method
// will be used because doing so requires calling getPostBody() which is expensive and may
// throw AuthFailureError.
// TODO(#190): Remove support for non-GET methods.
int method = getMethod();
if (method == Method.GET || method == Method.DEPRECATED_GET_OR_POST) {
return url;
}
return Integer.toString(method) + '-' + url;
}
注释也说的比较清楚了，如果是GET方式，那么key就是请求的url。如果是其他方式，那么key是Integer.toString(method) + ‘-’ + url。但是将来会移除对非GET方式的支持。
也就是说如果我们想使用缓存结果的话，最好还是用GET方式来请求数据。
本文转自：https://blog.csdn.net/fenggering/article/details/88563418