雖然在2017年,volley已是一個逐漸被淘汰的框架,但其代碼短小精悍,網絡架構設計巧妙,仍是有不少值得學習的地方。
第一篇文章,分析了請求隊列的代碼,請求隊列也是咱們使用Volley的關鍵一步。
第二篇文章會分析Dispatcher緩存
建立RequestQueue對象的方式是採用以下的代碼:網絡
RequestQueue queue = Volley.newRequestQueue(getApplicationContext());
該隊列是用來發起Http請求。主要看newRequestQueue方法
該方法的核心實現是2個參數的方法架構
newRequestQueue(Context context, HttpStack stack)
該方法作的事情以下:框架
Network network = new BasicNetwork(stack);
用建立好的CacheDir去初始化DiskBasedCache對象,從而完成RequestQueue對象的初始化,RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network);
下面,咱們看一下HttpStack的做用,以及DiskBasedCache和NetWork的做用,最後看一下start方法作了什麼。ide
HttpStack是一個接口,該接口只有兩個實現類,一個是HttpClientStack,另外一個是HulStack。咱們先不看具體的實現類,只看接口方法的聲明。oop
HttpResponse performRequest(Request<?> request, Map<String, String> additionalHeaders) throws IOException, AuthFailureError;
該方法的做用是用來真正進行網絡請求的,具體用那種http實現類去請求,就分紅了HttpClient以及HttpUrl。源碼分析
再看NetWork接口,該接口只有一個實現類,BasicNetWork,咱們仍是先不看具體的實現類,只看接口的方法聲明:學習
NetworkResponse performRequest(Request<?> request) throws VolleyError;
該方法的說明是執行一個指定的Request。ui
最後再看DiskBasedCache的功能。該類是Cache的一個具體的實現類,該類的功能是用緩存的文件存在硬盤中,默認的硬盤大小是5M。
上面的幾個接口的功能都說完了,經過其實現類的對象最終構造了RequestQueue。接下來咱們看一下構造器方法的執行。this
咱們先看一下RequestQueue的成員變量都有什麼:
下面咱們繼續看構造方法:
public RequestQueue(Cache cache, Network network, int threadPoolSize, ResponseDelivery delivery) { mCache = cache; mNetwork = network; mDispatchers = new NetworkDispatcher[threadPoolSize]; mDelivery = delivery; }
不管幾個參數的構造方法,最終都會執行這個。上面在 new RequestQueue
中,咱們的傳入的構造方法只有Cache和NetWork對象,這樣的話,threadPoolSize默認就是4,而delivery就是 new ExecutorDelivery(new Handler(Looper.getMainLooper()))
關於這個ExecutorDelivery這個後面在分析。
下面,咱們主要看RequestQueue的幾個關鍵方法:
public void stop() { if (mCacheDispatcher != null) { mCacheDispatcher.quit(); } for (final NetworkDispatcher mDispatcher : mDispatchers) { if (mDispatcher != null) { mDispatcher.quit(); } } }
stop方法的所有代碼很是少,主要的作的事情以下:
關鍵就在於quit方法。
quit方法的代碼以下:
public void quit() { mQuit = true; interrupt(); }
CacheDispatcher是繼承與Thread。quit方法的做用是設置一個退出的標誌位,而且調用interrupt方法,這樣在run方法執行的過程當中,因爲線程已經中斷,會執行catch語句塊的內容,檢查標誌位,直接return。
下面是去掉了與自身功能相關的代碼之後,剩下的部分。能夠看出是很標準的線程退出寫法。
。
public void run() { //執行初始化的操做,省略掉 while (true) { try { //執行業務代碼,省略掉 } catch (InterruptedException e) { // We may have been interrupted because it was time to quit. if (mQuit) { return; } } } }
stop的方法分析完畢
public void start() { stop(); // Make sure any currently running dispatchers are stopped. // Create the cache dispatcher and start it. mCacheDispatcher = new CacheDispatcher(mCacheQueue, mNetworkQueue, mCache, mDelivery); mCacheDispatcher.start(); // Create network dispatchers (and corresponding threads) up to the pool size. for (int i = 0; i < mDispatchers.length; i++) { NetworkDispatcher networkDispatcher = new NetworkDispatcher(mNetworkQueue, mNetwork, mCache, mDelivery); mDispatchers[i] = networkDispatcher; networkDispatcher.start(); } }
start方法比較簡潔,所以我在這裏放出所有的方法源碼。start方法主要作了如下幾件事情。
stop方法上面已經分析了,就不在說了,先調用stop的目的就是先中止已經啓動的dispatcher。
建立CacheDispather,NetWorkDispatcher,他們其實就是一堆線程,調用他們的start方法。關於他們的分析,後面在具體介紹。
cancel方法其實是cancalAll方法,但實際上最終都會調用cancelAll(RequestFilter filter) filter的做用其實是過濾出要取消的request。而後調用request.cancel。
關於request類,這個放到後面的分析。
<T> void finish(Request<T> request) { // Remove from the set of requests currently being processed. synchronized (mCurrentRequests) { mCurrentRequests.remove(request); } synchronized (mFinishedListeners) { for (RequestFinishedListener<T> listener : mFinishedListeners) { listener.onRequestFinished(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); } } } }
finish方法是一個泛型方法,該finish方法執行了如下幾個事情:
從上面的成員變量說明上,能夠看出CurrentRequst實際上存儲正在分派或者執行的request,對於finish天然是從該隊列中移除。
/** Callback interface for completed requests. */ public interface RequestFinishedListener<T> { /** Called when a request has finished processing. */ void onRequestFinished(Request<T> request); }
該接口的目的是提供一個request結束之後回調的接口。
判斷request是否須要緩存,能夠經過setShouldCache設置,而後從mWaitingReuqests中移除該key對應的隊列,而後將隊列加入cacheQueue。也就說,若是waitingQueue中還存在同樣的request,則所有移除掉。
add方法是添加request的方法,其所有的代碼以下:
public <T> Request<T> add(Request<T> request) { // Tag the request as belonging to this queue and add it to the set of current requests. request.setRequestQueue(this); synchronized (mCurrentRequests) { mCurrentRequests.add(request); } // Process requests in the order they are added. request.setSequence(getSequenceNumber()); request.addMarker("add-to-queue"); // If the request is uncacheable, skip the cache queue and go straight to the network. if (!request.shouldCache()) { mNetworkQueue.add(request); return request; } // Insert request into stage if there's already a request with the same cache key in flight. synchronized (mWaitingRequests) { String cacheKey = request.getCacheKey(); if (mWaitingRequests.containsKey(cacheKey)) { // 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 { // Insert 'null' queue for this cacheKey, indicating there is now a request in // flight. mWaitingRequests.put(cacheKey, null); mCacheQueue.add(request); } return request; } }
將request關聯到當前的requestQueue,而後mCurrentRequeue添加添加該request,request設置加入隊列的次序,判斷該request是否須要緩存,若是不須要緩存,就直接加入netWorkQueue中,等待被執行。
若是須要緩存,就先判斷該WaitingRequest中是否有該request,若是有就獲得該cacheKey對應的隊列,把該request加進去,若是沒有,就建立一個stagedRequests,將它加進去。而後將stagedRequests放入WaitiingRequest中。若是沒有cacheKey,waitingRequest就插入一個key爲cacheKey,value爲null的值進入,而後將request加入cacheQueue。
至此,RequestQueue的部分就分析完了,其主要的功能是根據傳入的Request來決定將該Request加入到那個Queue中,而後在經過Dispatcher進行調度。