Volley是Google出品的一个轻量级的网络框架，默认实现，主要用于小数据量的网络请求。这里就按从粗到细，自上而下的过程，给大家剖析这个牛X的框架。
这个框架的代码量虽少，但却把面向接口的编程这个原则发挥的淋漓尽致。这个框架是怎么构成的呢？
先看包的结构。
有com.android.volley 及 com.android.volley.toolbox两个包。
其中com.android.volley中的接口和类，是基础框架，构成了一个基于队列的网络请求功能。
而com.android.volley.toolbox这个子包，则是对框架的一些默认实现，和基本功能的扩展。
先看下面一个粗略的类关系图，列出了几个比较重要的接口与类。
我们着重研究图的上半部分，即下图中红色框住的部分，它是volley的最基础框架。
这几个类和接口都是在com.android.volley中，他们搭建了一个最基础的网络框架。
RequestQueue，是整个框架的核心类之一，它既是volley框架对外使用的api，也包含所有基础的接口。在这里，它与其他类是一种组合关系。
我们看到，这个类中包含了多个以Request为类型的集合（用以存储多个网络请求以及相关去重，优先级等），一个继承了Cache接口的实例，一个具备Network能力的实例，一个ResponseDelivery能力的实例，以及两个Dispaher。
Request的集合，包括一个HashMap mWaitingRequests，主要用于请求时进行去重处理。
HashSet mCurrentRequests ，主要用于保存所有的请求对象。
PriorityBlockingQueue，两个优先级阻塞队列，用于保存将要进行处理的请求。这里注意的是这个队列是自带排序功能，因为每一个Request对象都是可Comparable的，通过每次加入时进行比较Priority来排序。
Cache接口，主要有get和put两个方法，用于实现缓存。默认在子包中实现了两种方式的缓存，无缓存（NoCache)及磁盘缓存(DiskBasedCache)，如果这两个自带的缓存不能实现我们的需求，则可自行继承这个接口来扩展新的Cache策略。
Network接口，唯一一个方法输入request，输出NetworkResponse, 默认的子包中实现了一个BaseNetwork（基于HTTP的能力），同样，如果不满足HTTP的协议，则自行继承这个Network接口来实现。
两个Dispather很类似，CacheDispatcher是单线程处理，这里为什么要用线程呢，因为存取缓存可能会涉及到IO操作，可能会阻塞，因此，这里使用了一个线程来处理。在CacheDispatcher中也包含了两个优先级阻塞队列，一个可缓存队型，一个网络队型。在运行时，首先从可缓存队列中take一个请求，如发现是已有缓存的，则直接处理，否则就塞入到网络队型去处理（交给NetworkDispatcher)。
NetworkDispacther默认开启4个线程来处理（构造RequestQueue对象时可以修改)，整个网络请求都在run中完成，主要是调用 Network接口的performRequest方法来实现通信。
ResponseDelivery主要用于把结果通知出去，默认的实现有一个ExecutorDelivery。
经过分析，我们发现这个volley的设计是相当灵活的。它灵活运用了设计模式中的策略模式，对于一些可变的行为，都统一使用接口，并不去关心具体用什么实现，把实现交给使用者去定义，非常符合“对修改关闭，对扩展开放”的设计原则。
由于volley对一些细节处理的非常完善，后续我们会有针对性的介绍每一个类的实现，及为什么
原文地址：http://blog.csdn.net/zoudifei/article/details/45180335
