Volley---適合場景：適合資料量小、頻率高的請求，為什麼？
一、簡介
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把更多的效能留給頁面的渲染，提高效能。