volley源码分析

摘要：作为出品的工具还是非常不错的，今天整理一下对他的源码分析，从中能够学到一些。然后在这个对象的接口中启动了个线程来分别进行请求的缓存管理和网络处理。最后将我的分析图奉上，基本上一张图就可以看懂了。

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

类关系图：

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

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

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

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

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

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

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