Android中關於Volley的使用（五）從RequestQueue開始來深入認識Volley

在前面的幾篇文章中，我們學習了如何用Volley去網絡加載JSON數據，如何利用ImageRequest和NetworkImageView去網絡加載數據，而關於Volley的使用，我們都是從下面一行代碼開始的：

  

Volley.newRequestQueue(this);

這是Volley類創建了一個RequestQueue，而關於Volley的一切就是從這個時候開始的，我們就深入地學習一下在這個方法后面到底有着什么樣的實現吧。

 

我們來看看Volley類的實現：

  

public class Volley {

    ...
    public static RequestQueue newRequestQueue(Context context, HttpStack stack) {
        ...
    }

    /**
     * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it.
     *
     * @param context A {@link Context} to use for creating the cache dir.
     * @return A started {@link RequestQueue} instance.
     */
    public static RequestQueue newRequestQueue(Context context) {
        return newRequestQueue(context, null);
    }
}

Volley類只有兩個方法，而主要的創建RequestQueue的方法就是包含兩個參數Context和HttpStack的newRequestQueue方法了，另外一個只是調用這個方法，將傳一個null的HttpStack而已。

 

我們看看這個方法里面的實現：

  

public static RequestQueue newRequestQueue(Context context, HttpStack stack) {
    File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR);//緩存文件

    String userAgent = "volley/0";//UserAgent用來封裝應用的包名跟版本號，提供給服務器，就跟瀏覽器信息一樣
    try {
        String packageName = context.getPackageName();
        PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0);
        userAgent = packageName + "/" + info.versionCode;
    } catch (NameNotFoundException e) {
    }

    if (stack == null) {//一般我們都不需要傳這個參數進來，而volley則在這里會根據SDK的版本號來判斷
        if (Build.VERSION.SDK_INT >= 9) {
            stack = new HurlStack();//SDK如果大於等於9，也就是Android 2.3以后，因為引進了HttpUrlConnection，所以會用一個HurlStack
        } else {//如果小於9,則是用HttpClient來實現
            // Prior to Gingerbread, HttpUrlConnection was unreliable.
            // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
            stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
        }
    }

    Network network = new BasicNetwork(stack);//創建一個Network，構造函數需要一個stack參數，Network里面會調用stack去跟網絡通信
n style="white-space:pre">  </span>//創建RequestQueue，並將緩存實現DiskBasedCache和網絡實現BasicNetwork傳進去，然后調用start方法
    RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network);
    queue.start();

    return queue;
}

大家可以看代碼中的注釋，這里簡要說明一下步驟：

 

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的構造函數：

  

public RequestQueue(Cache cache, Network network) {
    this(cache, network, DEFAULT_NETWORK_THREAD_POOL_SIZE);//跟網絡交互的線程數量，默認是4
}

 

很明顯，調用了另外一個構造函數： 

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

而最終會調用到下面這個構造函數來創建對象： 

public RequestQueue(Cache cache, Network network, int threadPoolSize,
        ResponseDelivery delivery) {
    mCache = cache;//緩存
    mNetwork = network;//網絡
    mDispatchers = new NetworkDispatcher[threadPoolSize];//線程池
    mDelivery = delivery;//派送Response的實現
}

在構造函數中，我們可以看到在Volley類中創建的Cache和Network。

 

另外，通過前面傳進來的線程數量（默認是4），會創建一個NetworkDispatcher的數組，也就是創建了一個有4個線程的線程池，因為NetworkDispatcher是繼承於Thread的實現類，其定義如下：

  

public class NetworkDispatcher extends Thread {

而delivery的實現則是ExecutorDelivery，我們可以看到它的參數是一個Handler，而Handler的構造函數參數則是Looper.getMainLooper()，這其實是應用的主線程的Looper，也就是說，Handler其實是主線程中的Hanlder，ExecutorDelivery的定義如下：

  

public ExecutorDelivery(final Handler handler) {
    // Make an Executor that just wraps the handler.
    mResponsePoster = new Executor() {
        @Override
        public void execute(Runnable command) {
            handler.post(command);
        }
    };
}

主要作用也就是利用Handler來將Response傳回主線程進行UI更新，比如之前的更新ImageView，因為我們知道，UI的更新必須在主線程。

 

到這里，我們的RequestQueue對象就創建好了，下面就是要調用它的start方法了。

  

public void start() {
    stop();  // 保證所有正在運行的Dispatcher（也就是線程）都停止
    // 創建緩存的派發器（也是一個線程），並啟動線程。
    mCacheDispatcher = new CacheDispatcher(mCacheQueue, mNetworkQueue, mCache, mDelivery);
    mCacheDispatcher.start();

    // 根據線程池的大小，創建相對應的NetworkDispatcher（線程），並啟動所有的線程。
    for (int i = 0; i < mDispatchers.length; i++) {
        NetworkDispatcher networkDispatcher = new NetworkDispatcher(mNetworkQueue, mNetwork,
                mCache, mDelivery);
        mDispatchers[i] = networkDispatcher;
        networkDispatcher.start();
    }
}

/**
 * 停止緩存線程跟所有的網絡線程
 */
public void stop() {
    if (mCacheDispatcher != null) {
        mCacheDispatcher.quit();
    }
    for (int i = 0; i < mDispatchers.length; i++) {
        if (mDispatchers[i] != null) {
            mDispatchers[i].quit();
        }
    }
}

我們可以看到，

 

1）start方法的一開始，會先調用stop方法。stop會將緩存線程還有所有的網絡線程停止。

2）重新創建一個緩存線程，並啟動，在這里，會將 mCacheQueue，mNetwrok, mCache 和 mDelivery 傳給其構造函數。

3）根據線程池的大小，創建相對應數目的網絡線程，而在這里，我們可以看到會將 mNetworkQueue，mNetwrok，mCache 和 mDelivery作為參數傳給NetworkDispatcher。

很明顯，當調用RequestQueue的 start方法的時候，其實也就是啟動了一個緩存線程和默認的4個網絡線程，它們就會在后面靜靜地等待請求的到來。

在兩個構造函數上面，mNetwork, mCache 和 mDelivery，我們上面都介紹過了，但是 mCacheQueue 和 mNetworkQueue，這兩個具體是什么樣的呢？

 

private final PriorityBlockingQueue<Request<?>> mCacheQueue =
    new PriorityBlockingQueue<Request<?>>();

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

我們可以看到它們其實都是Java並發（Concurrent）包中提供的利用優先級來執行的阻塞隊列PriorityBlockingQueue。顯然，它們就應該是來放置從外面傳進來的請求的，比如JsonRequest，ImageRequest和 StringRequest。

 

而RequestQueue類中，還有另外兩個請求集合：

 

//等待中的請求集合
private final Map<String, Queue<Request<?>>> mWaitingRequests =
        new HashMap<String, Queue<Request<?>>>();

//所有在隊列中，或者正在被處理的請求都會在這個集合中
private final Set<Request<?>> mCurrentRequests = new HashSet<Request<?>>();

 

我們記得，當我們創建好RequestQueue對象之后，如果我們想要去加載圖片，我們就會創建ImageRequest對象，如果我們想要去獲取Json數據，我們就會創建JsonRequest對象，而最后我們都會調用 RequestQueue的add方法，來將請求加入到隊列中的。 

public <T> Request<T> add(Request<T> request) {
    // 將請求的隊列設置為當前隊列，並將請求添加到mCurrentRequests中，表明是正在處理中的，而在這里，我們可以看到利用synchronized來同步
    request.setRequestQueue(this);
    synchronized (mCurrentRequests) {
        mCurrentRequests.add(request);
    }

    // 在這里會設置序列號，保證每個請求都是按順序被處理的。
    request.setSequence(getSequenceNumber());
    request.addMarker("add-to-queue");

    // 如果這個請求是設置不緩存的，那么就會將其添加到mNetworkQueue中，直接去網絡中獲取數據
    if (!request.shouldCache()) {
        mNetworkQueue.add(request);
        return request;
    }

    // 到這里，表明這個請求可以去先去緩存中獲取數據。
    synchronized (mWaitingRequests) {
        String cacheKey = request.getCacheKey();
        if (mWaitingRequests.containsKey(cacheKey)) {//<span style="font-family: Arial, Helvetica, sans-serif; font-size: 12px;">如果這個請求已經有一個相同的請求（相同的CacheKey）在mWatingRequest中，那么就要將相同CacheKey的請求用一個LinkedList給裝起來，先不需要處理，等那個正在處理的請求結束后，再看看應該怎么處理。</span>

            // There is already a request in flight. Queue up.
            Queue<Request<?>> stagedRequests = mWaitingRequests.get(cacheKey);
            if (stagedRequests == null) {
                stagedRequests = new LinkedList<Request<?>>();
            }
            stagedRequests.add(request);
            mWaitingRequests.put(cacheKey, stagedRequests);
            if (VolleyLog.DEBUG) {
                VolleyLog.v("Request for cacheKey=%s is in flight, putting on hold.", cacheKey);
            }
        } else {
n style="white-space:pre">      </span>//如果mWaitingRequest中沒有，那么就將其添加到集合中,將添加到mCacheQueue隊列中，表明現在這個cacheKey的請求已經在處理了。
            mWaitingRequests.put(cacheKey, null);
            mCacheQueue.add(request);
        }
        return request;
    }
}

而當mCacheQueue或者mNetworkQueue利用add方法添加請求之后，在運行的線程就會接收到請求，從而去處理相對應的請求，最后將處理的結果由mDelivery來發送到主線程進行更新。

 

到這里，我們的請求就會在緩存線程或者網絡線程中去處理了，當它們結束之后，每一個Request就會調用自身的finish方法，如下：

 

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

而在這里，它調用的其實是 RequestQueue的finish方法，如下：

  

void finish(Request<?> request) {
    // Remove from the set of requests currently being processed.
    synchronized (mCurrentRequests) {
        mCurrentRequests.remove(request);
    }

    if (request.shouldCache()) {
        synchronized (mWaitingRequests) {
            String cacheKey = request.getCacheKey();
            Queue<Request<?>> waitingRequests = mWaitingRequests.remove(cacheKey);
            if (waitingRequests != null) {
                if (VolleyLog.DEBUG) {
                    VolleyLog.v("Releasing %d waiting requests for cacheKey=%s.",
                            waitingRequests.size(), cacheKey);
                }
                // Process all queued up requests. They won't be considered as in flight, but
                // that's not a problem as the cache has been primed by 'request'.
                mCacheQueue.addAll(waitingRequests);
            }
        }
    }
}

可以看到，第一步就是將請求從mCurrentRequests中移除，正好對應了上面add方法中的添加。

 

第二步就是判斷這個請求有沒有緩存，如果有，那么我們這個時候，將前面mWaitingQueue中相同CacheKey的一大批請求再一股腦兒的扔到mCacheQueue中，為什么現在才扔呢？因為前面我們不知道相同CacheKey的那個請求到底在緩存中有沒有，如果沒有，它需要去網絡中獲取，那就等到它從網絡中獲取之后，放到緩存中后，它結束了，並且已經緩存了，這個時候，我們就可以保證后面那堆相同CacheKey的請求可以在緩存中去取到數據了，而不需要再去網絡中獲取了。

在RequestQueue中，還提供了兩個方法去取消請求，如下：

  

public void cancelAll(RequestFilter filter) {
    synchronized (mCurrentRequests) {
        for (Request<?> request : mCurrentRequests) {
            if (filter.apply(request)) {
                request.cancel();
            }
        }
    }
}

/**
 * Cancels all requests in this queue with the given tag. Tag must be non-null
 * and equality is by identity.
 */
public void cancelAll(final Object tag) {
    if (tag == null) {
        throw new IllegalArgumentException("Cannot cancelAll with a null tag");
    }
    cancelAll(new RequestFilter() {
        @Override
        public boolean apply(Request<?> request) {
            return request.getTag() == tag;
        }
    });
}

如上，第一個cancleAll會獲取一個RequestFilter，這是RequestQueue的內部接口，定義如下：

  

public interface RequestFilter {
    public boolean apply(Request<?> request);
}

我們需要自己去實現，什么樣的請求才是符合我們的過濾器的，然后在cancel中根據我們定義的過濾規則去批量地取消請求。

 

而第二個則是利用創建Request時設置的Tag值，實現RequestFilter，然后調用上一個cancelAll方法，來取消一批同個Tag值的請求。

這兩個方法（其實是一種，主要是利用Tag來批量取消請求）跟我們這個流程的關系不大，所以就不在這里多講了。

嗯，關於RequestQueue中一切，到這里，也就結束了，不知道講得清不清楚，還希望大家多給點建議。