摘要：作為出品的工具還是非常不錯(cuò)的，今天整理一下對(duì)他的源碼分析，從中能夠?qū)W到一些。然后在這個(gè)對(duì)象的接口中啟動(dòng)了個(gè)線程來分別進(jìn)行請(qǐng)求的緩存管理和網(wǎng)絡(luò)處理。最后將我的分析圖奉上，基本上一張圖就可以看懂了。

volley作為google出品的工具還是非常不錯(cuò)的，今天整理一下對(duì)他的源碼分析，從中能夠?qū)W到一些。
借用網(wǎng)絡(luò)上的圖來表示下請(qǐng)求流程圖及類關(guān)系圖：

類關(guān)系圖：

從整體關(guān)系上看并不是很復(fù)雜。下面我就來解讀。

整個(gè)架構(gòu)是圍繞著RequestQueue開始的，這個(gè)對(duì)象基本上可以看做是各種容器的集合，其中最重要的是維護(hù)了request的請(qǐng)求隊(duì)列和network處理隊(duì)列，并且其中還做了緩存用來存放等待的請(qǐng)求。然后在這個(gè)對(duì)象的start接口中啟動(dòng)了1+n個(gè)線程來分別進(jìn)行請(qǐng)求的緩存管理（CacheDispatcher）和網(wǎng)絡(luò)處理（NetworkDispatcher）。將各項(xiàng)容器傳遞進(jìn)線程對(duì)象中，cache線程負(fù)責(zé)不停的從緩存隊(duì)列中讀取請(qǐng)求，并判定各種條件（包括超時(shí)判定，取消判定等），如果符合則傳遞給網(wǎng)絡(luò)隊(duì)列。而network線程也在不斷的從網(wǎng)絡(luò)隊(duì)列中獲取請(qǐng)求，符合條件的開始進(jìn)行網(wǎng)絡(luò)請(qǐng)求，并根據(jù)返回結(jié)果進(jìn)行緩存，然后通知給調(diào)用者。

下面我們從整個(gè)框架上看。
首先可以看到，2個(gè)線程的流程跟消息甭很類似。為什么要有2個(gè)線程來進(jìn)行這種交換式操作呢？因?yàn)樘峤坏恼?qǐng)求可能是從任意線程開始的，那么有風(fēng)險(xiǎn)在較短的時(shí)間內(nèi)對(duì)網(wǎng)絡(luò)進(jìn)行大量頻繁的請(qǐng)求，必然導(dǎo)致耗電/cpu和流量的各種不均衡，因此這里做了一個(gè)緩沖處理，先提交緩沖，然后利用根據(jù)當(dāng)前機(jī)型的cpu計(jì)算出的量級(jí)開辟的線程池來進(jìn)行網(wǎng)絡(luò)的請(qǐng)求；

整個(gè)框架擴(kuò)展性很好，幾乎任何的部件都可以擴(kuò)展。比如cache，可以不使用DiskBasedCache，改為使用內(nèi)存維護(hù)（當(dāng)然內(nèi)存開銷會(huì)增加），或者重寫磁盤文件，修正文件格式將所有的頭部獨(dú)立出來維護(hù)，實(shí)體內(nèi)容方在多帶帶的文件中；httpstack也是可以擴(kuò)展，比如使用其他的開源庫來代替現(xiàn)在的方式等，這里就不一一列舉了。

使用的支持線程并發(fā)的隊(duì)列PriorityBlockingQueue，同時(shí)多線程并發(fā)訪問時(shí)，除了最先的獲得訪問權(quán)的線程外，其他線程阻塞。

為何說volley適合頻繁的小的網(wǎng)絡(luò)請(qǐng)求，不適合大數(shù)據(jù)的請(qǐng)求呢？這里可以看到volley對(duì)請(qǐng)求和返回?cái)?shù)據(jù)的處理是緩存成文件，但在過程中一次讀到內(nèi)存中，如果是太大的數(shù)據(jù)，會(huì)導(dǎo)致oom。

最后將我的分析圖奉上，基本上一張圖就可以看懂了。