一、簡介
Volley請求網絡 是基於請求隊列的，只要把請求放入請求隊列就可以了。
Voller底層封裝的是HttpUrlConnection，支持圖片加載，網絡請求排序，優先級處理，緩存，與Activity生命週期聯動。擴展性好，支持httpclient，HttpUrlConnection，OkHttp，在頻繁請求和加載數據量少的時候優勢，不適合大數據加載.
使用、源碼詳解：見郭霖博客：https://blog.csdn.net/guolin_blog/article/details/17482095/
二、適合場景
適合場景：數據量小、頻率高的請求。但是爲什麼呢？（Read the fucking source code！）
首先，數據量小：
1. Volley的網絡請求線程池默認大小爲4。意味着可以併發進行4個請求，大於4個，會排在隊列中。
2. Request.getBody() 方法返回byte[]類型，作爲 Http.POST 和 Http.PUT body 中的數據。這就意味着需要把用 http 傳輸的數據一股腦讀取到內存中。如果文件過大，內存會爆！
Response也是使用byte數組存儲數據，大數據=大數組，消耗內存
考慮這樣一個場景:
你同時上傳4個文件，這四個文件都很大，這時候：a.你的內存佔用就很高，很容易oom。b.這時候，你再發網絡請求，所有的網絡線程都被上傳文件的任務佔滿了，你的網絡請求只有在文件上傳完畢後才能得到執行。體驗就是，很慢！
所以Volley適合數據量小的請求。
然後，頻率高：
ByteArrayPool產生背景
根據類名，知道這是一個字節數組緩存池。沒錯，就是用來緩存 網絡請求獲得的數據。 當網絡請求得到返回數據以後，我們需要在內存開闢出一塊區域來存放我們得到的網絡數據，不論是json還是圖片，都會存在於內存的某一塊區域，然後拿到UI顯示，然而客戶端請求是相當頻繁的操作，想一下我們平時使用知乎等一些客戶端，幾乎每一個操作都要進行網絡請求（雖然知乎大部分是WebView）。那麼問題來了：這麼頻繁的數據請求，獲得數據以後我們先要在堆內存開闢存儲空間，然後顯示，等到時機成熟，GC回收這塊區域，如此往復，那麼GC的負擔就相當的重，然而Android客戶端處理能力有限，頻繁GC對客戶端的性能有直接影響。我們能不能減少GC和內存的分配呢？我想這個問題就是這個類的產生背景。
ByteArrayPool利用getBuf和returnBuf以及mBuffersByLastUse和mBuffersBySize完成字節數組的緩存。當需要使內存區域的時候，先從已經分配的區域中獲得以減少內存分配次數。當空間用完以後，在將數據返回給此緩衝區。這樣，就會減少內存區域堆內存的波動和減少GC的回收，讓CPU把更多的性能留給頁面的渲染，提高性能。