1.概述
Volley的源代碼分析，網(wǎng)上一大把的分析博客，但是當(dāng)你看完這些博客后，也是云里霧里的，很多一上來就上源代碼分析，典型的就是這一篇：
http://blog.csdn.net/guolin_blog/article/details/17656437
還有從結(jié)構(gòu)上講，總的來說，比上從源代碼講強(qiáng)那么一點，典型的就是這一篇。單總的來說，這一篇比上一篇強(qiáng)一點。
對于一上來就開始分析源代碼的行為，我敬而遠(yuǎn)之。
現(xiàn)在回過頭來看Volley的源代碼，感覺從設(shè)計的角度來說，Volley設(shè)計并不算是優(yōu)秀，但是volley的擴(kuò)展性非常棒，面向接口編程在這里得到完美的體現(xiàn)，這是閱讀volley源代碼之后的最大感受。
volley的類沒有幾個，對于打基礎(chǔ)的階段，閱讀該庫對提升技術(shù)水平有很好的幫助。
volley說明
從名字由來和配圖中無數(shù)急促的火箭可以看出 Volley 的特點：特別適合數(shù)據(jù)量小，通信頻繁的網(wǎng)絡(luò)操作。
對于文件上傳，文件下載等操作，還是換成另外的庫吧。至于為什么，因為其設(shè)計就決定了。
源碼分析方法
其實Volley的設(shè)計思路和源碼分析的方式在上面的這個圖就已經(jīng)高度的概括展示出來了。這張圖已經(jīng)說明了volley的工作原理和設(shè)計思路。
這是是volley源代碼的結(jié)構(gòu)：
源代碼分析
我們先不看 "toolbox"文件夾，因為該文件夾主要是其接口的實現(xiàn)。
現(xiàn)在我們看下面一些無關(guān)緊要的類：
- VolleyLog。
是一個日志類，與此無關(guān)，去掉。
- VolleyError，TimeOutError，ServerError，ParseError,NetworkError,AuthFailureError，NoConnectionError。
這些都是異常的錯誤處理，其中后面的Error相關(guān)的類都時VolleyError的子類，這個對分析volley結(jié)構(gòu)沒有什么幫助，去掉不看。
- RetryPolicy ，DefaultRetryPolicy。
后者是前者的子類，我們只看RetryPolicy這個就行了。實際上這個是是重置訪問，比如本次訪問超時，設(shè)置20s后再次連接，這個就是重置的作用，對于分析Volley的整個結(jié)構(gòu)來說，無關(guān)緊要，可以不看。在分析具體的代碼和細(xì)節(jié)的時候再去看。
- ResponseDelivery 和 ExecutorDelivery。
后者是前者的一個實現(xiàn)。這個類作用就是異步操作，實際上就是一個Hanlder的事件分發(fā)，將子線的結(jié)果分發(fā)到主線程中。分析結(jié)構(gòu)的時候，只需要關(guān)心ResponseDelivery。
- Cache 緩存的接口。
去掉上面那那些無關(guān)緊要的類之后，剩下就沒有幾個類了，我們看看還剩下那些類。
Network 具體的網(wǎng)絡(luò)訪問
CacheDispatcher 緩存調(diào)度線程
NetworkDispatcher 網(wǎng)絡(luò)訪問調(diào)度線程
NetworkResponse 網(wǎng)絡(luò)訪問的直接結(jié)果,不是分發(fā)到主線程的結(jié)果
Request 網(wǎng)絡(luò)請求的封裝，包括請求的url,請求的方法，請求的的內(nèi)容等等。
RequestQueue 這個看起來好像是一個請求的對象，實際上這個只是將這些類根據(jù)規(guī)則組合在一起的東西。源代碼的分析就是從這里從這個類開始進(jìn)行的。
Response 封裝了分發(fā)的結(jié)果，這個怎么理解呢，就是 NetworkRespond的結(jié)果經(jīng)過進(jìn)一步處理分發(fā)到主線程中的結(jié)果。
怎么樣，剩下的也沒有幾個，這樣就大大的降低了閱讀代碼的難度了。
RequestQueue開始
這個類是整個Volley的開始部分，先看start（）方法：
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();
}
}
前面說過了，CacheDispatcher和NetworkDispatcher是兩個線程一個是緩存調(diào)度線程，一個是網(wǎng)絡(luò)請求調(diào)度的線程。
上面的代碼就是開啟一個緩存調(diào)度線程和若干個（默認(rèn)四個）網(wǎng)絡(luò)請求調(diào)度線程。
接下來我們看看CacheDispatcher線程。
CacheDispatcher線程
既然是一個線程，那么我們只關(guān)心 線程run方法就可以了
下面是偽代碼,剔除一些日志，異常判斷等無影響代碼后的結(jié)構(gòu)
while(true){
//先從緩存隊列中拿出一個請求
final Request request = mCacheQueue.take();
//如果這個請求取消了，那么這個請求直接結(jié)束，開始下一個循環(huán)
if (request.isCanceled()) {
request.finish("cache-discard-canceled");
ontinue;
}
// 如果沒有緩存或者緩存失效的話，就將這條請求添加到網(wǎng)絡(luò)請求調(diào)度線程中
Cache.Entry entry = mCache.get(request.getCacheKey());
if (entry == null || entry.isExpired()) {
mNetworkQueue.put(request);
continue;
}
//從緩存中拿出結(jié)果。
Response response = request.parseNetworkResponse(
new NetworkResponse(entry.data, entry.responseHeaders));
request.addMarker("cache-hit-parsed");
//分發(fā)結(jié)果
mDelivery.postResponse(request, response);
}
從上面的偽代碼可以看出，實際上緩存調(diào)度線程做的事情非常的簡單，邏輯一點也不復(fù)雜。
先從緩存隊列中拿出一條請求。
判斷這個請求是否已經(jīng)標(biāo)志結(jié)束了，如果結(jié)束了那么設(shè)置這條請求結(jié)束，并分發(fā)結(jié)果。否則進(jìn)入下一步。
判斷緩存是否存在，緩存是否過期，如果過期了，之前沒有緩存，那么就將這條請求放到網(wǎng)絡(luò)調(diào)度的線程中。
NetworkDispatcher
網(wǎng)絡(luò)請求調(diào)度線程的分析方法和上面類似，實際上，該類的run()方法中的代碼比CacheDispatcher 線程中 run()方法中代碼還少，無非就是：
從網(wǎng)絡(luò)請求隊列中拿出一條request。
判斷這條請求是否已經(jīng)結(jié)束或者取消了。如果沒有那么就是下一步。
開始執(zhí)行網(wǎng)絡(luò)請求，并拿到請求的結(jié)果。
是否需要緩存結(jié)果，如果需要緩存結(jié)果，那么就緩存結(jié)果。
將請求的結(jié)果進(jìn)行分發(fā)。
完成上面的步驟之后，實際上volley的核心代碼就分析完成了，其它部分就是細(xì)節(jié)的問題，比如具體的網(wǎng)絡(luò)請求是怎么樣子的。分發(fā)是什么樣子的，但這些都是細(xì)節(jié)問題，不是主干代碼。
對于初學(xué)者來說，很容易陷入代碼汪洋中，即使把代碼全部看一篇也無濟(jì)于事，抓住枝葉，不見主干，分析再多也沒有用。典型的例子有：
http://blog.csdn.net/guolin_blog/article/details/17656437
總結(jié)：
閱讀源代碼的方式我總結(jié)如下：
首先看一看設(shè)計的結(jié)構(gòu)圖。
去掉無關(guān)緊要的類，比如異常Error相關(guān)的類，日志類等。
分析主干代碼，比如重點看接口和抽象類而忽略掉其具體的實現(xiàn)，因為優(yōu)秀的開源庫一定是面向接口編程，這些接口和抽象類才是設(shè)計的框架所在。
在分析過程中去掉無用的代碼，這里的無用指的是那些為了框架穩(wěn)定性和環(huán)境適配的代碼，如NUll指針判斷，日志記錄，異常等。
使用偽代碼自己實現(xiàn)一遍框架。
