Android中关于Volley的使用（五）从RequestQueue开始来深入认识Volley

在前面的几篇文章中，我们学习了如何用Volley去网络加载JSON数据，如何利用ImageRequest和NetworkImageView去网络加载数据，而关于Volley的使用，我们都是从下面一行代码开始的：

1. Volley.newRequestQueue(this);

这是Volley类创建了一个RequestQueue，而关于Volley的一切就是从这个时候开始的，我们就深入地学习一下在这个方法后面到底有着什么样的实现吧。

我们来看看Volley类的实现：

1. public class Volley {
2. ...
3. public static RequestQueue newRequestQueue(Context context, HttpStack stack) {
4. ...
5. }
6. /**
7. * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it.
8. *
9. * @param context A {@link Context} to use for creating the cache dir.
10. * @return A started {@link RequestQueue} instance.
11. */
12. public static RequestQueue newRequestQueue(Context context) {
13. return newRequestQueue(context, null);
14. }
15. }

Volley类只有两个方法，而主要的创建RequestQueue的方法就是包含两个参数Context和HttpStack的newRequestQueue方法了，另外一个只是调用这个方法，将传一个null的HttpStack而已。

我们看看这个方法里面的实现：

1. public static RequestQueue newRequestQueue(Context context, HttpStack stack) {
2. File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR);//缓存文件
3. String userAgent = "volley/0";//UserAgent用来封装应用的包名跟版本号，提供给服务器，就跟浏览器信息一样
4. try {
5. String packageName = context.getPackageName();
6. PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0);
7. userAgent = packageName + "/" + info.versionCode;
8. } catch (NameNotFoundException e) {
9. }
10. if (stack == null) {//一般我们都不需要传这个参数进来，而volley则在这里会根据SDK的版本号来判断
11. if (Build.VERSION.SDK_INT >= 9) {
12. stack = new HurlStack();//SDK如果大于等于9，也就是Android 2.3以后，因为引进了HttpUrlConnection，所以会用一个HurlStack
13. } else {//如果小于9,则是用HttpClient来实现
14. // Prior to Gingerbread, HttpUrlConnection was unreliable.
15. // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
16. stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
17. }
18. }
19. Network network = new BasicNetwork(stack);//创建一个Network，构造函数需要一个stack参数，Network里面会调用stack去跟网络通信
20. n style="white-space:pre">  </span>//创建RequestQueue，并将缓存实现DiskBasedCache和网络实现BasicNetwork传进去，然后调用start方法
21. RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network);
22. queue.start();
23. return queue;
24. }

大家可以看代码中的注释，这里简要说明一下步骤：

1）创建缓存文件和UserAgenp字符串

2）根据SDK版本来创建HttpStack的实现，如果是2.3以上的，则使用基于HttpUrlConnection实现的HurlStack，反之，则利用HttpClient实现的HttpClientStack。

3）创建一个BasicNetwork对象，并将HttpStack封装在Network中

4）创建一个DiskBasedCache对象，和Network一起，传给RequestQueue作为参数，创建RequestQueue对象。

5）调用 RequestQueue的 start 方法，然后返回创建的queue对象。

接下来，我们看看RequestQueue的构造函数：

1. public RequestQueue(Cache cache, Network network) {
2. this(cache, network, DEFAULT_NETWORK_THREAD_POOL_SIZE);//跟网络交互的线程数量，默认是4
3. }

很明显，调用了另外一个构造函数：

1. public RequestQueue(Cache cache, Network network, int threadPoolSize) {
2. this(cache, network, threadPoolSize,
3. new ExecutorDelivery(new Handler(Looper.getMainLooper())));
4. }

而最终会调用到下面这个构造函数来创建对象：

1. public RequestQueue(Cache cache, Network network, int threadPoolSize,
2. ResponseDelivery delivery) {
3. mCache = cache;//缓存
4. mNetwork = network;//网络
5. mDispatchers = new NetworkDispatcher[threadPoolSize];//线程池
6. mDelivery = delivery;//派送Response的实现
7. }

在构造函数中，我们可以看到在Volley类中创建的Cache和Network。

另外，通过前面传进来的线程数量（默认是4），会创建一个NetworkDispatcher的数组，也就是创建了一个有4个线程的线程池，因为NetworkDispatcher是继承于Thread的实现类，其定义如下：

1. public class NetworkDispatcher extends Thread {

而delivery的实现则是ExecutorDelivery，我们可以看到它的参数是一个Handler，而Handler的构造函数参
数则是Looper.getMainLooper()，这其实是应用的主线程的Looper，也就是说，Handler其实是主线程中的
Hanlder，ExecutorDelivery的定义如下：

1. public ExecutorDelivery(final Handler handler) {
2. // Make an Executor that just wraps the handler.
3. mResponsePoster = new Executor() {
4. @Override
5. public void execute(Runnable command) {
6. handler.post(command);
7. }
8. };
9. }

主要作用也就是利用Handler来将Response传回主线程进行UI更新，比如之前的更新ImageView，因为我们知道，UI的更新必须在主线程。

到这里，我们的RequestQueue对象就创建好了，下面就是要调用它的start方法了。

1. public void start() {
2. stop();  // 保证所有正在运行的Dispatcher（也就是线程）都停止
3. // 创建缓存的派发器（也是一个线程），并启动线程。
4. mCacheDispatcher = new CacheDispatcher(mCacheQueue, mNetworkQueue, mCache, mDelivery);
5. mCacheDispatcher.start();
6. // 根据线程池的大小，创建相对应的NetworkDispatcher（线程），并启动所有的线程。
7. for (int i = 0; i < mDispatchers.length; i++) {
8. NetworkDispatcher networkDispatcher = new NetworkDispatcher(mNetworkQueue, mNetwork,
9. mCache, mDelivery);
10. mDispatchers[i] = networkDispatcher;
11. networkDispatcher.start();
12. }
13. }
14. /**
15. * 停止缓存线程跟所有的网络线程
16. */
17. public void stop() {
18. if (mCacheDispatcher != null) {
19. mCacheDispatcher.quit();
20. }
21. for (int i = 0; i < mDispatchers.length; i++) {
22. if (mDispatchers[i] != null) {
23. mDispatchers[i].quit();
24. }
25. }
26. }

我们可以看到，

1）start方法的一开始，会先调用stop方法。stop会将缓存线程还有所有的网络线程停止。

2）重新创建一个缓存线程，并启动，在这里，会将 mCacheQueue，mNetwrok, mCache 和 mDelivery 传给其构造函数。

3）根据线程池的大小，创建相对应数目的网络线程，而在这里，我们可以看到会将 mNetworkQueue，mNetwrok，mCache 和 mDelivery作为参数传给NetworkDispatcher。

很明显，当调用RequestQueue的 start方法的时候，其实也就是启动了一个缓存线程和默认的4个网络线程，它们就会在后面静静地等待请求的到来。

在两个构造函数上面，mNetwork, mCache 和 mDelivery，我们上面都介绍过了，但是 mCacheQueue 和 mNetworkQueue，这两个具体是什么样的呢？

1. private final PriorityBlockingQueue<Request<?>> mCacheQueue =
2. new PriorityBlockingQueue<Request<?>>();
3. /** The queue of requests that are actually going out to the network. */
4. private final PriorityBlockingQueue<Request<?>> mNetworkQueue =
5. new PriorityBlockingQueue<Request<?>>();

我们可以看到它们其实都是Java并发（Concurrent）包中提供的利用优先级来执行的阻塞队列
PriorityBlockingQueue。显然，它们就应该是来放置从外面传进来的请求的，比如JsonRequest，ImageRequest和
StringRequest。

而RequestQueue类中，还有另外两个请求集合：

1. //等待中的请求集合
2. private final Map<String, Queue<Request<?>>> mWaitingRequests =
3. new HashMap<String, Queue<Request<?>>>();
4. //所有在队列中，或者正在被处理的请求都会在这个集合中
5. private final Set<Request<?>> mCurrentRequests = new HashSet<Request<?>>();

我们记得，当我们创建好RequestQueue对象之后，如果我们想要去加载图片，我们就会创建ImageRequest对象，如果我们想要去获
取Json数据，我们就会创建JsonRequest对象，而最后我们都会调用 RequestQueue的add方法，来将请求加入到队列中的。

1. public <T> Request<T> add(Request<T> request) {
2. // 将请求的队列设置为当前队列，并将请求添加到mCurrentRequests中，表明是正在处理中的，而在这里，我们可以看到利用synchronized来同步
3. request.setRequestQueue(this);
4. synchronized (mCurrentRequests) {
5. mCurrentRequests.add(request);
6. }
7. // 在这里会设置序列号，保证每个请求都是按顺序被处理的。
8. request.setSequence(getSequenceNumber());
9. request.addMarker("add-to-queue");
10. // 如果这个请求是设置不缓存的，那么就会将其添加到mNetworkQueue中，直接去网络中获取数据
11. if (!request.shouldCache()) {
12. mNetworkQueue.add(request);
13. return request;
14. }
15. // 到这里，表明这个请求可以去先去缓存中获取数据。
16. synchronized (mWaitingRequests) {
17. String cacheKey = request.getCacheKey();
18. if (mWaitingRequests.containsKey(cacheKey)) {//<span style="font-
    family: Arial, Helvetica, sans-serif; font-size: 12px;">如果这个请求已经有一个相同
    的请求（相同的CacheKey）在mWatingRequest中，那么就要将相同CacheKey的请求用一个LinkedList给装起来，先不需
    要处理，等那个正在处理的请求结束后，再看看应该怎么处理。</span>
19. // There is already a request in flight. Queue up.
20. Queue<Request<?>> stagedRequests = mWaitingRequests.get(cacheKey);
21. if (stagedRequests == null) {
22. stagedRequests = new LinkedList<Request<?>>();
23. }
24. stagedRequests.add(request);
25. mWaitingRequests.put(cacheKey, stagedRequests);
26. if (VolleyLog.DEBUG) {
27. VolleyLog.v("Request for cacheKey=%s is in flight, putting on hold.", cacheKey);
28. }
29. } else {
30. n style="white-space:pre">      </span>//如果mWaitingRequest中没有，那么就将其添加到集合中,将添加到mCacheQueue队列中，表明现在这个cacheKey的请求已经在处理了。
31. mWaitingRequests.put(cacheKey, null);
32. mCacheQueue.add(request);
33. }
34. return request;
35. }
36. }

而当mCacheQueue或者mNetworkQueue利用add方法添加请求之后，在运行的线程就会接收到请求，从而去处理相对应的请求，最后将处理的结果由mDelivery来发送到主线程进行更新。

到这里，我们的请求就会在缓存线程或者网络线程中去处理了，当它们结束之后，每一个Request就会调用自身的finish方法，如下：

1. void finish(final String tag) {
2. if (mRequestQueue != null) {
3. mRequestQueue.finish(this);
4. }

而在这里，它调用的其实是 RequestQueue的finish方法，如下：

1. void finish(Request<?> request) {
2. // Remove from the set of requests currently being processed.
3. synchronized (mCurrentRequests) {
4. mCurrentRequests.remove(request);
5. }
6. if (request.shouldCache()) {
7. synchronized (mWaitingRequests) {
8. String cacheKey = request.getCacheKey();
9. Queue<Request<?>> waitingRequests = mWaitingRequests.remove(cacheKey);
10. if (waitingRequests != null) {
11. if (VolleyLog.DEBUG) {
12. VolleyLog.v("Releasing %d waiting requests for cacheKey=%s.",
13. waitingRequests.size(), cacheKey);
14. }
15. // Process all queued up requests. They won't be considered as in flight, but
16. // that's not a problem as the cache has been primed by 'request'.
17. mCacheQueue.addAll(waitingRequests);
18. }
19. }
20. }
21. }

可以看到，第一步就是将请求从mCurrentRequests中移除，正好对应了上面add方法中的添加。

第二步就是判断这个请求有没有缓存，如果有，那么我们这个时候，将前面mWaitingQueue中相同CacheKey的一大批请求再一股脑儿的
扔到mCacheQueue中，为什么现在才扔呢？因为前面我们不知道相同CacheKey的那个请求到底在缓存中有没有，如果没有，它需要去网络中获
取，那就等到它从网络中获取之后，放到缓存中后，它结束了，并且已经缓存了，这个时候，我们就可以保证后面那堆相同CacheKey的请求可以在缓存中去
取到数据了，而不需要再去网络中获取了。

在RequestQueue中，还提供了两个方法去取消请求，如下：

1. public void cancelAll(RequestFilter filter) {
2. synchronized (mCurrentRequests) {
3. for (Request<?> request : mCurrentRequests) {
4. if (filter.apply(request)) {
5. request.cancel();
6. }
7. }
8. }
9. }
10. /**
11. * Cancels all requests in this queue with the given tag. Tag must be non-null
12. * and equality is by identity.
13. */
14. public void cancelAll(final Object tag) {
15. if (tag == null) {
16. throw new IllegalArgumentException("Cannot cancelAll with a null tag");
17. }
18. cancelAll(new RequestFilter() {
19. @Override
20. public boolean apply(Request<?> request) {
21. return request.getTag() == tag;
22. }
23. });
24. }

如上，第一个cancleAll会获取一个RequestFilter，这是RequestQueue的内部接口，定义如下：

1. public interface RequestFilter {
2. public boolean apply(Request<?> request);
3. }

我们需要自己去实现，什么样的请求才是符合我们的过滤器的，然后在cancel中根据我们定义的过滤规则去批量地取消请求。

而第二个则是利用创建Request时设置的Tag值，实现RequestFilter，然后调用上一个cancelAll方法，来取消一批同个Tag值的请求。

这两个方法（其实是一种，主要是利用Tag来批量取消请求）跟我们这个流程的关系不大，所以就不在这里多讲了。

嗯，关于RequestQueue中一切，到这里，也就结束了，不知道讲得清不清楚，还希望大家多给点建议。

http://www.cnblogs.com/android100/p/Android-Volley5.html