摘要：作為出品的工具還是非常不錯的，今天整理一下對他的源碼分析，從中能夠學到一些。然后在這個對象的接口中啟動了個線程來分別進行請求的緩存管理和網絡處理。最后將我的分析圖奉上，基本上一張圖就可以看懂了。

volley作為google出品的工具還是非常不錯的，今天整理一下對他的源碼分析，從中能夠學到一些。
借用網絡上的圖來表示下請求流程圖及類關系圖：

類關系圖：

從整體關系上看并不是很復雜。下面我就來解讀。

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

下面我們從整個框架上看。
首先可以看到，2個線程的流程跟消息甭很類似。為什么要有2個線程來進行這種交換式操作呢？因為提交的請求可能是從任意線程開始的，那么有風險在較短的時間內對網絡進行大量頻繁的請求，必然導致耗電/cpu和流量的各種不均衡，因此這里做了一個緩沖處理，先提交緩沖，然后利用根據當前機型的cpu計算出的量級開辟的線程池來進行網絡的請求；

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

使用的支持線程并發的隊列PriorityBlockingQueue，同時多線程并發訪問時，除了最先的獲得訪問權的線程外，其他線程阻塞。

為何說volley適合頻繁的小的網絡請求，不適合大數據的請求呢？這里可以看到volley對請求和返回數據的處理是緩存成文件，但在過程中一次讀到內存中，如果是太大的數據，會導致oom。

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