深入解讀Android的Volley庫(kù)的功能結(jié)構(gòu)
Volley 是一個(gè) HTTP 庫(kù),它能夠幫助 Android app 更方便地執(zhí)行網(wǎng)絡(luò)操作,最重要的是,它更快速高效。我們可以通過(guò)開(kāi)源的 AOSP 倉(cāng)庫(kù)獲取到 Volley 。
Volley 有如下的優(yōu)點(diǎn):
- 自動(dòng)調(diào)度網(wǎng)絡(luò)請(qǐng)求。
- 高并發(fā)網(wǎng)絡(luò)連接。
- 通過(guò)標(biāo)準(zhǔn)的 HTTP cache coherence(高速緩存一致性)緩存磁盤和內(nèi)存透明的響應(yīng)。
- 支持指定請(qǐng)求的優(yōu)先級(jí)。
- 撤銷請(qǐng)求 API。我們可以取消單個(gè)請(qǐng)求,或者指定取消請(qǐng)求隊(duì)列中的一個(gè)區(qū)域。
- 框架容易被定制,例如,定制重試或者回退功能。
- 強(qiáng)大的指令(Strong ordering)可以使得異步加載網(wǎng)絡(luò)數(shù)據(jù)并正確地顯示到 UI 的操作更加簡(jiǎn)單。
- 包含了調(diào)試與追蹤工具。
Volley 擅長(zhǎng)執(zhí)行用來(lái)顯示 UI 的 RPC 類型操作,例如獲取搜索結(jié)果的數(shù)據(jù)。它輕松的整合了任何協(xié)議,并輸出操作結(jié)果的數(shù)據(jù),可以是原始的字符串,也可以是圖片,或者是 JSON。通過(guò)提供內(nèi)置的我們可能使用到的功能,Volley 可以使得我們免去重復(fù)編寫樣板代碼,使我們可以把關(guān)注點(diǎn)放在 app 的功能邏輯上。
Volley 不適合用來(lái)下載大的數(shù)據(jù)文件。因?yàn)?Volley 會(huì)保持在解析的過(guò)程中所有的響應(yīng)。對(duì)于下載大量的數(shù)據(jù)操作,請(qǐng)考慮使用 DownloadManager。
Volley 框架的核心代碼是托管在 AOSP 倉(cāng)庫(kù)的 frameworks/volley 中,相關(guān)的工具放在 toolbox 下。把 Volley 添加到項(xiàng)目中最簡(jiǎn)便的方法是 Clone 倉(cāng)庫(kù),然后把它設(shè)置為一個(gè) library project:
通過(guò)下面的命令來(lái)Clone倉(cāng)庫(kù):
git clone https://android.googlesource.com/platform/frameworks/volley
以一個(gè) Android library project 的方式導(dǎo)入下載的源代碼到你的項(xiàng)目中。
下面我們就來(lái)剖析一下Volley的Java源碼:
RequestQueue
使用 Volley 的時(shí)候,需要先獲得一個(gè) RequestQueue 對(duì)象。它用于添加各種請(qǐng)求任務(wù),通常是調(diào)用 Volly.newRequestQueue() 方法獲取一個(gè)默認(rèn)的 RequestQueue。我們就從這個(gè)方法開(kāi)始,下面是它的源碼:
public static RequestQueue newRequestQueue(Context context) { return newRequestQueue(context, null); } public static RequestQueue newRequestQueue(Context context, HttpStack stack) { File cacheDir = new File(context.getCacheDir(), DEFAULT_CACHE_DIR); String userAgent = "volley/0"; try { String packageName = context.getPackageName(); PackageInfo info = context.getPackageManager().getPackageInfo(packageName, 0); userAgent = packageName + "/" + info.versionCode; } catch (NameNotFoundException e) { } if (stack == null) { if (Build.VERSION.SDK_INT >= 9) { stack = new HurlStack(); } else { // 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); RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network); queue.start(); return queue; }
newRequestQueue(context) 調(diào)用了它的重載方法 newRequestQueue(context,null)。在這個(gè)方法中,先是通過(guò) context 獲得了緩存目錄并且構(gòu)建了 userAgent 信息。接著判斷 stack 是否為空,從上面的調(diào)用可以知道,默認(rèn)情況下 stack==null, 所以新建一個(gè) stack 對(duì)象。根據(jù)系統(tǒng)版本不同,在版本號(hào)大于 9 時(shí),stack 為 HurlStack,否則為 HttpClientStack。它們的區(qū)別是,HurlStack 使用 HttpUrlConnection 進(jìn)行網(wǎng)絡(luò)通信,而 HttpClientStack 使用 HttpClient。有了 stack 后,用它創(chuàng)建了一個(gè) BasicNetWork 對(duì)象,可以猜到它是用來(lái)處理網(wǎng)絡(luò)請(qǐng)求任務(wù)的。緊接著,新建了一個(gè) RequestQueue,這也是最終返回給我們的請(qǐng)求隊(duì)列。這個(gè) RequestQueue 接受兩個(gè)參數(shù),第一個(gè)是 DiskBasedCache 對(duì)象,從名字就可以看出這是用于硬盤緩存的,并且緩存目錄就是方法一開(kāi)始取得的 cacheDir;第二個(gè)參數(shù)是剛剛創(chuàng)建的 network 對(duì)象。最后調(diào)用 queue.start() 啟動(dòng)請(qǐng)求隊(duì)列。
在分析 start() 之前,先來(lái)了解一下 RequestQueue 一些關(guān)鍵的內(nèi)部變量以及構(gòu)造方法:
//重復(fù)的請(qǐng)求將加入這個(gè)集合 private final Map<String, Queue<Request>> mWaitingRequests = new HashMap<String, Queue<Request>>(); //所有正在處理的請(qǐng)求任務(wù)的集合 private final Set<Request> mCurrentRequests = new HashSet<Request>(); //緩存任務(wù)的隊(duì)列 private final PriorityBlockingQueue<Request> mCacheQueue = new PriorityBlockingQueue<Request>(); //網(wǎng)絡(luò)請(qǐng)求隊(duì)列 private final PriorityBlockingQueue<Request> mNetworkQueue = new PriorityBlockingQueue<Request>(); //默認(rèn)線程池大小 private static final int DEFAULT_NETWORK_THREAD_POOL_SIZE = 4; //用于響應(yīng)數(shù)據(jù)的存儲(chǔ)與獲取 private final Cache mCache; //用于網(wǎng)絡(luò)請(qǐng)求 private final Network mNetwork; //用于分發(fā)響應(yīng)數(shù)據(jù) private final ResponseDelivery mDelivery; //網(wǎng)絡(luò)請(qǐng)求調(diào)度 private NetworkDispatcher[] mDispatchers; //緩存調(diào)度 private CacheDispatcher mCacheDispatcher; public RequestQueue(Cache cache, Network network) { this(cache, network, DEFAULT_NETWORK_THREAD_POOL_SIZE); } 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; }
RequestQueue 有多個(gè)構(gòu)造方法,最終都會(huì)調(diào)用最后一個(gè)。在這個(gè)方法中,mCache 和 mNetWork 分別設(shè)置為 newRequestQueue 中傳來(lái)的 DiskBasedCache 和 BasicNetWork。mDispatchers 為網(wǎng)絡(luò)請(qǐng)求調(diào)度器的數(shù)組,默認(rèn)大小 4 (DEFAULT_NETWORK_THREAD_POOL_SIZE)。mDelivery 設(shè)置為 new ExecutorDelivery(new Handler(Looper.getMainLooper())),它用于響應(yīng)數(shù)據(jù)的傳遞,后面會(huì)具體介紹??梢钥闯?,其實(shí)我們可以自己定制一個(gè) RequestQueue 而不一定要用默認(rèn)的 newRequestQueue。
下面就來(lái)看看 start() 方法是如何啟動(dòng)請(qǐng)求隊(duì)列的:
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(); } }
代碼比較簡(jiǎn)單,就做了兩件事。第一,創(chuàng)建并且啟動(dòng)一個(gè) CacheDispatcher。第二,創(chuàng)建并啟動(dòng)四個(gè) NetworkDispatcher。所謂的啟動(dòng)請(qǐng)求隊(duì)列就是把任務(wù)交給緩存調(diào)度器和網(wǎng)絡(luò)請(qǐng)求調(diào)度器處理。
這里還有個(gè)問(wèn)題,請(qǐng)求任務(wù)是怎么加入請(qǐng)求隊(duì)列的?其實(shí)就是調(diào)用了 add() 方法。現(xiàn)在看看它內(nèi)部怎么處理的:
public Request add(Request 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; } }
這個(gè)方法的代碼稍微有點(diǎn)長(zhǎng),但邏輯并不復(fù)雜。首先把這個(gè)任務(wù)加入 mCurrentRequests,然后判斷是否需要緩存,不需要的話就直接加入網(wǎng)絡(luò)請(qǐng)求任務(wù)隊(duì)列 mNetworkQueue 然后返回。默認(rèn)所有任務(wù)都需要緩存,可以調(diào)用 setShouldCache(boolean shouldCache) 來(lái)更改設(shè)置。所有需要緩存的都會(huì)加入緩存任務(wù)隊(duì)列 mCacheQueue。不過(guò)先要判斷 mWaitingRequests 是不是已經(jīng)有了,避免重復(fù)的請(qǐng)求。
Dispatcher
RequestQueue 調(diào)用 start() 之后,請(qǐng)求任務(wù)就被交給 CacheDispatcher 和 NetworkDispatcher 處理了。它們都繼承自 Thread,其實(shí)就是后臺(tái)工作線程,分別負(fù)責(zé)從緩存和網(wǎng)絡(luò)獲取數(shù)據(jù)。
CacheDispatcher
CacheDispatcher 不斷從 mCacheQueue 取出任務(wù)處理,下面是它的 run() 方法:
public void run() { if (DEBUG) VolleyLog.v("start new dispatcher"); Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); // Make a blocking call to initialize the cache. mCache.initialize(); while (true) { try { // Get a request from the cache triage queue, blocking until // at least one is available. 取出緩存隊(duì)列的任務(wù) final Request request = mCacheQueue.take(); request.addMarker("cache-queue-take"); // If the request has been canceled, don't bother dispatching it. if (request.isCanceled()) { request.finish("cache-discard-canceled"); continue; } // Attempt to retrieve this item from cache. Cache.Entry entry = mCache.get(request.getCacheKey()); if (entry == null) { request.addMarker("cache-miss"); // Cache miss; send off to the network dispatcher. mNetworkQueue.put(request); continue; } // If it is completely expired, just send it to the network. if (entry.isExpired()) { request.addMarker("cache-hit-expired"); request.setCacheEntry(entry); mNetworkQueue.put(request); continue; } // We have a cache hit; parse its data for delivery back to the request. request.addMarker("cache-hit"); Response<?> response = request.parseNetworkResponse( new NetworkResponse(entry.data, entry.responseHeaders)); request.addMarker("cache-hit-parsed"); if (!entry.refreshNeeded()) { // Completely unexpired cache hit. Just deliver the response. mDelivery.postResponse(request, response); } else { // Soft-expired cache hit. We can deliver the cached response, // but we need to also send the request to the network for // refreshing. request.addMarker("cache-hit-refresh-needed"); request.setCacheEntry(entry); // Mark the response as intermediate. response.intermediate = true; // Post the intermediate response back to the user and have // the delivery then forward the request along to the network. mDelivery.postResponse(request, response, new Runnable() { @Override public void run() { try { mNetworkQueue.put(request); } catch (InterruptedException e) { // Not much we can do about this. } } }); } } catch (InterruptedException e) { // We may have been interrupted because it was time to quit. if (mQuit) { return; } continue; } } }
首先是調(diào)用 mCache.initialize() 初始化緩存,然后是一個(gè) while(true) 死循環(huán)。在循環(huán)中,取出緩存隊(duì)列的任務(wù)。先判斷任務(wù)是否取消,如果是就執(zhí)行 request.finish("cache-discard-canceled") 然后跳過(guò)下面的代碼重新開(kāi)始循環(huán),否則從緩存中找這個(gè)任務(wù)是否有緩存數(shù)據(jù)。如果緩存數(shù)據(jù)不存在,把任務(wù)加入網(wǎng)絡(luò)請(qǐng)求隊(duì)列,并且跳過(guò)下面的代碼重新開(kāi)始循環(huán)。如果找到了緩存,就判斷是否過(guò)期,過(guò)期的還是要加入網(wǎng)絡(luò)請(qǐng)求隊(duì)列,否則調(diào)用 request 的parseNetworkResponse 解析響應(yīng)數(shù)據(jù)。最后一步是判斷緩存數(shù)據(jù)的新鮮度,不需要刷新新鮮度的直接調(diào)用 mDelivery.postResponse(request, response) 傳遞響應(yīng)數(shù)據(jù),否則依然要加入 mNetworkQueue 進(jìn)行新鮮度驗(yàn)證。
上面的代碼邏輯其實(shí)不是很復(fù)雜,但描述起來(lái)比較繞,下面這張圖可以幫助理解:
NetworkDispatcher
CacheDispatcher 從緩存中尋找任務(wù)的響應(yīng)數(shù)據(jù),如果任務(wù)沒(méi)有緩存或者緩存失效就要交給 NetworkDispatcher 處理了。它不斷從網(wǎng)絡(luò)請(qǐng)求任務(wù)隊(duì)列中取出任務(wù)執(zhí)行。下面是它的 run() 方法:
public void run() { Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); Request request; while (true) { try { // Take a request from the queue. request = mQueue.take(); } catch (InterruptedException e) { // We may have been interrupted because it was time to quit. if (mQuit) { return; } continue; } try { request.addMarker("network-queue-take"); // If the request was cancelled already, do not perform the // network request. if (request.isCanceled()) { request.finish("network-discard-cancelled"); continue; } // Tag the request (if API >= 14) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) { TrafficStats.setThreadStatsTag(request.getTrafficStatsTag()); } // Perform the network request. 發(fā)送網(wǎng)絡(luò)請(qǐng)求 NetworkResponse networkResponse = mNetwork.performRequest(request); request.addMarker("network-http-complete"); // If the server returned 304 AND we delivered a response already, // we're done -- don't deliver a second identical response. if (networkResponse.notModified && request.hasHadResponseDelivered()) { request.finish("not-modified"); continue; } // Parse the response here on the worker thread. Response<?> response = request.parseNetworkResponse(networkResponse); request.addMarker("network-parse-complete"); // Write to cache if applicable. // TODO: Only update cache metadata instead of entire record for 304s. if (request.shouldCache() && response.cacheEntry != null) { mCache.put(request.getCacheKey(), response.cacheEntry); request.addMarker("network-cache-written"); } // Post the response back. request.markDelivered(); mDelivery.postResponse(request, response); } catch (VolleyError volleyError) { parseAndDeliverNetworkError(request, volleyError); } catch (Exception e) { VolleyLog.e(e, "Unhandled exception %s", e.toString()); mDelivery.postError(request, new VolleyError(e)); } } }
可以看出,run() 方法里面依然是個(gè)無(wú)限循環(huán)。從隊(duì)列中取出一個(gè)任務(wù),然后判斷任務(wù)是否取消。如果沒(méi)有取消就調(diào)用 mNetwork.performRequest(request) 獲取響應(yīng)數(shù)據(jù)。如果數(shù)據(jù)是 304 響應(yīng)并且已經(jīng)有這個(gè)任務(wù)的數(shù)據(jù)傳遞,說(shuō)明這是 CacheDispatcher 中驗(yàn)證新鮮度的請(qǐng)求并且不需要刷新新鮮度,所以跳過(guò)下面的代碼重新開(kāi)始循環(huán)。否則繼續(xù)下一步,解析響應(yīng)數(shù)據(jù),看看數(shù)據(jù)是不是要緩存。最后調(diào)用 mDelivery.postResponse(request, response) 傳遞響應(yīng)數(shù)據(jù)。下面這張圖展示了這個(gè)方法的流程:
Delivery
在 CacheDispatcher 和 NetworkDispatcher 中,獲得任務(wù)的數(shù)據(jù)之后都是通過(guò) mDelivery.postResponse(request, response) 傳遞數(shù)據(jù)。我們知道 Dispatcher 是另開(kāi)的線程,所以必須把它們獲取的數(shù)據(jù)通過(guò)某種方法傳遞到主線程,來(lái)看看 Deliver 是怎么做的。
mDelivery 的類型為 ExecutorDelivery,下面是它的 postResponse 方法源碼:
public void postResponse(Request<?> request, Response<?> response) { postResponse(request, response, null); } public void postResponse(Request<?> request, Response<?> response, Runnable runnable) { request.markDelivered(); request.addMarker("post-response"); mResponsePoster.execute(new ResponseDeliveryRunnable(request, response, runnable)); }
從上面的代碼可以看出,最終是通過(guò)調(diào)用 mResponsePoster.execute(new ResponseDeliveryRunnable(request, response, runnable)) 進(jìn)行數(shù)據(jù)傳遞。這里的 mResponsePoster 是一個(gè) Executor 對(duì)象。
private final Executor mResponsePoster; 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); } };
Executor 是線程池框架接口,里面只有一個(gè) execute() 方法,mResponsePoster 的這個(gè)方法實(shí)現(xiàn)為用 handler 傳遞 Runnable 對(duì)象。而在 postResponse 方法中,request 和 response 被封裝為 ResponseDeliveryRunnable, 它正是一個(gè) Runnable 對(duì)象。所以響應(yīng)數(shù)據(jù)就是通過(guò) handler 傳遞的,那么這個(gè) handler 是哪里來(lái)的?其實(shí)在介紹 RequestQueue 的時(shí)候已經(jīng)提到了:mDelivery 設(shè)置為 new ExecutorDelivery(new Handler(Looper.getMainLooper())),這個(gè) handler 便是 new Handler(Looper.getMainLooper()),是與主線程的消息循環(huán)連接在一起的,這樣數(shù)據(jù)便成功傳遞到主線程了。
總結(jié)
Volley 的基本工作原理就是這樣,用一張圖總結(jié)一下它的運(yùn)行流程:
- Android項(xiàng)目基本結(jié)構(gòu)詳解
- 淺析Android系統(tǒng)的架構(gòu)以及程序項(xiàng)目的目錄結(jié)構(gòu)
- 淺談Android開(kāi)發(fā)中項(xiàng)目的文件結(jié)構(gòu)及規(guī)范化部署建議
- 淺談Android系統(tǒng)的基本體系結(jié)構(gòu)與內(nèi)存管理優(yōu)化
- Android編程入門之HelloWorld項(xiàng)目目錄結(jié)構(gòu)分析
- Android應(yīng)用開(kāi)發(fā)的一般文件組織結(jié)構(gòu)講解
- Android源碼中的目錄結(jié)構(gòu)詳解
- Android程序結(jié)構(gòu)簡(jiǎn)單講解
相關(guān)文章
Android中的Looper對(duì)象詳細(xì)介紹
這篇文章主要介紹了Android中的Looper對(duì)象,需要的朋友可以參考下2014-02-02Android 中 onSaveInstanceState()使用方法詳解
這篇文章主要介紹了Android 中 onSaveInstanceState()使用方法詳解的相關(guān)資料,希望通過(guò)本文大家能夠掌握這部分知識(shí),需要的朋友可以參考下2017-09-09Android實(shí)現(xiàn)網(wǎng)絡(luò)多線程文件下載
這篇文章主要介紹了Android實(shí)現(xiàn)網(wǎng)絡(luò)多線程文件下載的相關(guān)資料,需要的朋友可以參考下2016-03-03Android?WebRTC?對(duì)?AudioRecord?的使用技術(shù)分享
這篇文章主要介紹了Android?WebRTC?對(duì)?AudioRecord?的使用技術(shù)分享,AudioRecord?是?Android?基于原始PCM音頻數(shù)據(jù)錄制的類,接下來(lái)和小編進(jìn)入文章了解更詳細(xì)的內(nèi)容吧2022-02-02Android學(xué)習(xí)筆記之ListView復(fù)用機(jī)制詳解
本篇文章主要介紹了Android學(xué)習(xí)筆記之ListView復(fù)用機(jī)制詳解,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2017-02-02Android模擬用戶點(diǎn)擊的實(shí)現(xiàn)方法
這篇文章主要給大家介紹了關(guān)于Android模擬用戶點(diǎn)擊的實(shí)現(xiàn)方法,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)學(xué)習(xí)學(xué)習(xí)吧。2018-02-02