volley源码解析

前言

不知不觉接触安卓已经一年的时间了，在学习和开发的过程中，遇到过很多问题，当在博客上发现前人将解决办法记录下来的时候，就会想：我也要留下一些自己的知识和学习心路。就像那句话：种一棵树最好的时间是十年前，其次是现在，我想，现在是时候了。

volley解析

源码地址

github.com/mcxiaoke/android-volley

基本用法

关于volley的基本用法，已经有很多大神做过总结，推荐郭神的博客blog.csdn.net/guolin_blog/article/details/17482095/

源码解析

流程分析

在使用volley的时候，首先需要获取一个RequestQueue，我们可以通过Volley.newRequestQueue这个静态方法完成。

图3 获取RequestQueue

获取RequestQueue

在这个方法里，调用了getCacheDir()方法用于获取/data/data/cache目录，之后缓存的内容将会存放在这个路径。HurlStack类对HttpURLConnection进行了封装，简化了网络请求代码，BasicNetwork是Volley中默认使用的网络请求的类，因为不是本文的重点，不再赘述。然后可以看到new 了一个RequestQueue对象，传入了缓存目录和网络请求的对象。

然后我们看一下RequestQueue的构造函数

图4 RequestQueue构造函数

我们调用了两个参数的构造函数，看源码发现DEFAULT_NETWORK_THREAD_POOL_SIZE为4，也就是说，volley默认会开启四个线程，以前在Java并发编程实践这本书上看到过，线程数量为CPU+1时效果比较好，所以日后使用volley的时候，可以尝试着修改一下线程数量试试。这里还创建了NetworkDispatcher和ResponseDelivery，我们先将流程走完，一会就会提到他们。到这里我们也就创建了一个RequestQueue对象，然后我们看他的start()方法。

图5 start和stop方法

首先在第142行调用了stop方法来停止所有正在运行的缓存线程和网络请求线程。然后创建了CacheDispatcher对象，它继承自Thread，在145行开启了缓存线程。紧接着又创建了NetworkDispatcher对象，它也是继承自Thread，在152行开启了网络请求线程，之前我们已经分析过，此处网络请求线程的默认数量应该为4。mCacheDispather是一个线程，所以145行实际上调用了它的run方法，代码比较长，首先看前半部分。

图6 CacheDispather--run() 

在第84行，调用了DisBasedCache.initialize()方法，我们来看一下。

图7 DiskBasedCache--initialize()

可以看到，这是一个同步方法，所以当创建了多个RequestQueue时，这个方法是线程安全的。这个方法的作用也就是：遍历这个缓存文件夹，将缓存文件的key和CacheHeader存到map中。

回到图6，接着我们进入了一个无限循环。mCacheQueue 是一个BlockingQueue对象，能够很好的实现生产者-消费者模式，并且线程安全。使用volley时，发出一个请求也就是将这个请求加入了队列（网络请求和从硬盘中读缓存分别有一个队列）中。从缓存队列中读出请求(92)后，如果这个请求已经被取消(104)，就结束这个请求(105)，否则就通过key到缓存中查找(110)。如果查找结果为空(111)，则说明没有这一个缓存，就将这个请求加入到网络请求队列中(114)，否则说明查找成功。然后判断这个结果是否已经过期(119)，如果已经过期，也将这个请求加入到网络请求队列中。在缓存中查找到这条记录，也就进入了方法的下半部分，如图8。

图8 CacheDispather.run()

首先，调用parseNetworkResponse方法将查找结果包装成对象。然后判断Request请求结果是否新鲜(132)，如果新鲜，则分发请求结果(134)，如果不新鲜（148），依然将结果返回给用户，同时重新执行网络请求，刷新结果。为了清楚分发过程，我们来查看mDelivery:ExecutorDelivery，继承自ResponseDelivery。

图9 ExecutorDelivery

查看代码发现，默认调用的构造方法是参数为Handler的这个。由图10可知，将主线程的Looper传了进来。那么，以后的runnable也就都运行在主线程。当调用postResponse方法的时候，执行了ResponseDeliveryRunnable，如图11。

图10 

图11 ResponseDeliveryRunnable

如果这个请求已经被取消，就结束这个请求(93)。如果请求成功，则调用Request的deliverResponse方法将结果分发(99)，否则发送错误消息。如果这个请求是新鲜的，那么mRunnable == null；否则mRunnable ！= null，这个mRunnable实际上就是图8的148行的第三个参数，也就是将这个请求加入到网络请求的队列中。接下来，我们查看Request的deliverResponse方法。Requst有四个实现类，以StringRequest为例子。

图12 deliverResponse

这个mListener也就是我们在创建Request的时候，传入的回调函数，当请求成功时，就会在主线程中执行这个回调。上面这么长的追踪，我们终于找到了一次成功的网络请求的终点。但是，当发出请求的时候，我们实际上把请求加到了哪个队列呢？来看一下RequestQueue的add方法(图14)，以及RequestQueue中重要的成员对象(图13)。

图13 成员对象

图14 add方法

229行，让request持有requestQueue对象，然后将请求加入到当前正在执行的请求队列中(231)，当多个线程添加请求的时候，确保了线程安全。如果这个请求不需要缓存，则将请求加入到网络请求队列中(240)，然后结束。如果这个请求在waitingRequest中(247)，说明这个请求在刚才被请求过，但请求还没有执行结束，将这些同样的请求加入到一个队列中。如果不在waitingRequest中(258)，则将request加入到其中，表示Request正在执行。那么，什么时候将请求从waitingRequest中移除呢？查看源码发现，在图11的第109行，以及网络请求结束时，会调用request的finish函数,实际上是调用了图15 也就是RequestQueue的finish方法。

图15 finish方法

在这个方法里，首先会将这个请求从mCurrentRequest队列中移除，然后在287行将请求从waitingRequests中移除。

整体流程图如下

图16 流程图

不知不觉写了一上午，希望对大家有帮助。