概述

Volley是Google在2013年推出的一個網絡庫，用於解決復雜網絡環境下網絡請求問題。剛推出的時候是非常火的，現在該項目的變動已經很少了。項目庫地址為
https://android.googlesource.com/platform/frameworks/volley
通過提交歷史可以看到，最後一次修改距離今天已經有一段時間了。而volley包的release版本也已經很久沒有更新了。 author Jeff Davidson Sun Mar 13 16:35:59 2016 +0000 雖然很久沒有更新了，Volley始終是一個很好的網絡框架，我們來分析一下volley的源碼，更好的了解volley的使用場景，設計模式，還有存在的一些小問題，或者說使用不當出現的問題。

 

創建RequestQueue

Volley類實質上只提供了一個方法newRequestQueue，用來創建RequestQueue，RequestQueue是volley的請求隊列，mCurrentRequests中存儲了執行中的和將要執行的請求，DEFAULT_NETWORK_THREAD_POOL_SIZE是一個常量4。
可以通過RequestQueue 的public RequestQueue(Cache cache, Network network, int threadPoolSize)這個方法修改線程數量，默認開啟4個線程，然後一直子後台運行。這裡需要注意一下在調用Volley的RequestQueue的時候，內部已經調用了RequestQueue的start方法，不需要再次調用。如果自己創建RequestQueue需要自行調用start方法，整個APP的生命周期中使用一次即可。多次調用會增加線程開銷，每次調用start方法，都會調用stop方法終止原來的線程，然後重新開啟新的線程。
正常使用volley後台請求線程數量是固定的，默認4個並發不需要修改，可能是基於這個考慮，並沒有使用Executor線程池，線程池的考慮本身是為了管理線程頻繁創建，避免過多開銷的。默認始終4個線程，不存在過度開銷問題。個人感覺這裡使用線程池會更好一些，當然引入線程池復雜度一定會增加。始終只有4個線程也引發了一些問題，使volley在某些場景不適用。如果請求服務器響應時間太長，4個線程都會處於阻塞狀態，這個時候新來的請求只能等待，不能直接執行。volley是比較適合輕量級請求，請求頻繁，請求時間短。

 

 

    /** Number of network request dispatcher threads to start. */
    private static final int DEFAULT_NETWORK_THREAD_POOL_SIZE = 4;

 

 

    public RequestQueue(Cache cache, Network network) {
        this(cache, network, DEFAULT_NETWORK_THREAD_POOL_SIZE);
    }

  Network network = new BasicNetwork(stack);

        RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network);
        queue.start();

 

 

請求執行者HttpStack

HttpStack是真正執行網絡請求的接口，performRequest方法執行請求，源碼中有兩個實現，一個是HurlStack，另一個是HttpClientStack，SDK版本大於等於9使用的是HurlStack。

 

 

       if (stack == null) {
            if (Build.VERSION.SDK_INT >= 9) {
                stack = new HurlStack();
            } else {
                // Prior to Gingerbread, HttpUrlConnection was unreliable.
                // See: http://android-developers.blogspot.com/2011/09/androids-http-clients.html
                stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
            }
        }

 

DefaultHttpClient和它的兄弟AndroidHttpClient都是HttpClient具體的實現類，它們都擁有眾多的API，而且實現比較穩定，bug數量也很少。但同時也由於HttpClient的API數量過多，使得我們很難在不破壞兼容性的情況下對它進行升級和擴展，所以目前Android團隊在提升和優化HttpClient方面的工作態度並不積極。

HttpURLConnection是一種多用途、輕量極的HTTP客戶端，使用它來進行HTTP操作可以適用於大多數的應用程序。雖然HttpURLConnection的API提供的比較簡單，但是同時這也使得我們可以更加容易地去使用和擴展它。不過在Android 2.2版本之前，HttpURLConnection一直存在著一些令人厭煩的bug。比如說對一個可讀的InputStream調用close方法時，就有可能會導致連接池失效了。那麼我們通常的解決辦法就是直接禁用掉連接池的功能。Android 2.3版本之前HttpURLConnection存在bug不建議使用，而在Android 2.3版本及以後，HttpURLConnection則是最佳的選擇。它的API簡單，體積較小，因而非常適用於Android項目。壓縮和緩存機制可以有效地減少網絡訪問的流量，在提升速度和省電方面也起到了較大的作用。

目前來說，我們有一個更好的請求選擇okhttp，volley源碼中並沒有封裝它的請求，我們可以自己實現HttpStack接口，在performRequest使用okhttp請求。OkHttp 相較於其它的實現有以下的優點：支持SPDY，允許連接同一主機的所有請求分享一個socket。 如果SPDY不可用，會使用連接池減少請求延遲。 使用GZIP壓縮下載內容，且壓縮操作對用戶是透明的。 利用響應緩存來避免重復的網絡請求。 當網絡出現問題的時候，OKHttp會依然有效，它將從常見的連接問題當中恢復。 如果你的服務端有多個IP地址，當第一個地址連接失敗時，OKHttp會嘗試連接其他的地址，這對IPV4和IPV6以及寄宿在多個數據中心的服務而言，是非常有必要的。使用 OkHttp 作為替代是一個很好的選擇。

 

緩存與線程處理

剛才說有4個默認線程是不准確的，是有4個NetworkDispatcher執行網絡請求，還有一個CacheDispatcher緩存線程，本地緩存策略需要實現Cache接口，源碼中有兩個實現DiskBasedCache，NoCache，默認使用的是DiskBasedCache。我們可以根據自己的需要實現Cache接口。DiskBasedCache默認路徑是app緩存目錄下的volley，默認緩存5M，超出之後會覆蓋舊數據。

 

Request類

Request類的子類相當於volley的輸入，是創建請求的時候用的。JsonObjectRequest、JsonArrayRequest用來處理返回是json的數據，StringRequest處理stirng，ImageRequest用來處理圖片。

Volley 其實是一個生產者和消費者系統，調用方是生產者，而Volley是消費者。調用方通過RequestQueue 生產Request，而Vollery 消費Request 從而得到Response。那麼負責調配這些生產者和消費者的就是Dispatcher，分別是Cache 和 Network 的Dispatcher。