volley作为google出品的工具还是非常不错的，今天整理一下对他的源码分析，从中能够学到一些。
借用网络上的图来表示下请求流程图及类关系图：

类关系图：

从整体关系上看并不是很复杂。下面我就来解读。

整个架构是围绕着RequestQueue开始的，这个对象基本上可以看做是各种容器的集合，其中最重要的是维护了request的请求队列和network处理队列，并且其中还做了缓存用来存放等待的请求。然后在这个对象的start接口中启动了1+n个线程来分别进行请求的缓存管理（CacheDispatcher）和网络处理（NetworkDispatcher）。将各项容器传递进线程对象中，cache线程负责不停的从缓存队列中读取请求，并判定各种条件（包括超时判定，取消判定等），如果符合则传递给网络队列。而network线程也在不断的从网络队列中获取请求，符合条件的开始进行网络请求，并根据返回结果进行缓存，然后通知给调用者。

下面我们从整个框架上看。
首先可以看到，2个线程的流程跟消息甭很类似。为什么要有2个线程来进行这种交换式操作呢？因为提交的请求可能是从任意线程开始的，那么有风险在较短的时间内对网络进行大量频繁的请求，必然导致耗电/cpu和流量的各种不均衡，因此这里做了一个缓冲处理，先提交缓冲，然后利用根据当前机型的cpu计算出的量级开辟的线程池来进行网络的请求；

整个框架扩展性很好，几乎任何的部件都可以扩展。比如cache，可以不使用DiskBasedCache，改为使用内存维护（当然内存开销会增加），或者重写磁盘文件，修正文件格式将所有的头部独立出来维护，实体内容方在单独的文件中；httpstack也是可以扩展，比如使用其他的开源库来代替现在的方式等，这里就不一一列举了。

使用的支持线程并发的队列PriorityBlockingQueue，同时多线程并发访问时，除了最先的获得访问权的线程外，其他线程阻塞。

为何说volley适合频繁的小的网络请求，不适合大数据的请求呢？这里可以看到volley对请求和返回数据的处理是缓存成文件，但在过程中一次读到内存中，如果是太大的数据，会导致oom。

最后将我的分析图奉上，基本上一张图就可以看懂了。