volley源碼分析

volley做爲google出品的工具仍是很是不錯的，今天整理一下對他的源碼分析，從中可以學到一些。
借用網絡上的圖來表示下請求流程圖及類關係圖：

類關係圖：

從總體關係上看並非很複雜。下面我就來解讀。

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

下面咱們從整個框架上看。
首先能夠看到，2個線程的流程跟消息甭很相似。爲何要有2個線程來進行這種交換式操做呢？由於提交的請求多是從任意線程開始的，那麼有風險在較短的時間內對網絡進行大量頻繁的請求，必然致使耗電/cpu和流量的各類不均衡，所以這裏作了一個緩衝處理，先提交緩衝，而後利用根據當前機型的cpu計算出的量級開闢的線程池來進行網絡的請求；

整個框架擴展性很好，幾乎任何的部件均可以擴展。好比cache，能夠不使用DiskBasedCache，改成使用內存維護（固然內存開銷會增長），或者重寫磁盤文件，修正文件格式將全部的頭部獨立出來維護，實體內容方在單獨的文件中；httpstack也是能夠擴展，好比使用其餘的開源庫來代替如今的方式等，這裏就不一一列舉了。

使用的支持線程併發的隊列PriorityBlockingQueue，同時多線程併發訪問時，除了最早的得到訪問權的線程外，其餘線程阻塞。

爲什麼說volley適合頻繁的小的網絡請求，不適合大數據的請求呢？這裏能夠看到volley對請求和返回數據的處理是緩存成文件，但在過程當中一次讀到內存中，若是是太大的數據，會致使oom。

最後將個人分析圖奉上，基本上一張圖就能夠看懂了。