概述

Volley是Google在2013年推出的一個(gè)網(wǎng)絡(luò)庫(kù)，用于解決復(fù)雜網(wǎng)絡(luò)環(huán)境下網(wǎng)絡(luò)請(qǐng)求問(wèn)題。剛推出的時(shí)候是非常火的，現(xiàn)在該項(xiàng)目的變動(dòng)已經(jīng)很少了。項(xiàng)目庫(kù)地址為https://android.googlesource.com/platform/frameworks/volley

通過(guò)提交歷史可以看到，最后一次修改距離今天已經(jīng)有一段時(shí)間了。而volley包的release版本也已經(jīng)很久沒(méi)有更新了。

author JeffDavidson<jpd@google.com> SunMar1316:35:592016+0000雖然很久沒(méi)有更新了，Volley始終是一個(gè)很好的網(wǎng)絡(luò)框架，我們來(lái)分析一下volley的源碼，更好的了解volley的使用場(chǎng)景，設(shè)計(jì)模式，還有存在的一些小問(wèn)題，或者說(shuō)使用不當(dāng)出現(xiàn)的問(wèn)題。

創(chuàng)建RequestQueue

下面的代碼片段展示了建立一個(gè)RequestQueue需要的步驟：

// 使用 cache 和 network初始化 RequestQueue
mRequestQueue = new RequestQueue(cache, network);

// 啟動(dòng)隊(duì)列
mRequestQueue.start();

String url ="http://www.example.com";

// 明確描述請(qǐng)求（request）并處理響應(yīng)（response）
StringRequest stringRequest = new StringRequest(Request.Method.GET, url,
    new Response.Listener<String>() {
  @Override
  public void onResponse(String response) {
    // 處理響應(yīng)信息
  }
},
  new Response.ErrorListener() {
    @Override
    public void onErrorResponse(VolleyError error) {
      // Handle error
  }
});

// 添加request 到 RequestQueue.
mRequestQueue.add(stringRequest);

// ...

Volley類實(shí)質(zhì)上只提供了一個(gè)方法newRequestQueue，用來(lái)創(chuàng)建RequestQueue，RequestQueue是volley的請(qǐng)求隊(duì)列，mCurrentRequests中存儲(chǔ)了執(zhí)行中的和將要執(zhí)行的請(qǐng)求，DEFAULT_NETWORK_THREAD_POOL_SIZE是一個(gè)常量4。

可以通過(guò)RequestQueue的publicRequestQueue(Cachecache,Networknetwork,intthreadPoolSize)這個(gè)方法修改線程數(shù)量，默認(rèn)開啟4個(gè)線程，然后一直子后臺(tái)運(yùn)行。這里需要注意一下在調(diào)用Volley的RequestQueue的時(shí)候，內(nèi)部已經(jīng)調(diào)用了RequestQueue的start方法，不需要再次調(diào)用。如果自己創(chuàng)建RequestQueue需要自行調(diào)用start方法，整個(gè)APP的生命周期中使用一次即可。多次調(diào)用會(huì)增加線程開銷，每次調(diào)用start方法，都會(huì)調(diào)用stop方法終止原來(lái)的線程，然后重新開啟新的線程。

正常使用volley后臺(tái)請(qǐng)求線程數(shù)量是固定的，默認(rèn)4個(gè)并發(fā)不需要修改，可能是基于這個(gè)考慮，并沒(méi)有使用Executor線程池，線程池的考慮本身是為了管理線程頻繁創(chuàng)建，避免過(guò)多開銷的。默認(rèn)始終4個(gè)線程，不存在過(guò)度開銷問(wèn)題。個(gè)人感覺(jué)這里使用線程池會(huì)更好一些，當(dāng)然引入線程池復(fù)雜度一定會(huì)增加。始終只有4個(gè)線程也引發(fā)了一些問(wèn)題，使volley在某些場(chǎng)景不適用。如果請(qǐng)求服務(wù)器響應(yīng)時(shí)間太長(zhǎng)，4個(gè)線程都會(huì)處于阻塞狀態(tài)，這個(gè)時(shí)候新來(lái)的請(qǐng)求只能等待，不能直接執(zhí)行。volley是比較適合輕量級(jí)請(qǐng)求，請(qǐng)求頻繁，請(qǐng)求時(shí)間短。

/** 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(); 

請(qǐng)求執(zhí)行者HttpStack

HttpStack是真正執(zhí)行網(wǎng)絡(luò)請(qǐng)求的接口，performRequest方法執(zhí)行請(qǐng)求，源碼中有兩個(gè)實(shí)現(xiàn)，一個(gè)是HurlStack，另一個(gè)是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具體的實(shí)現(xiàn)類，它們都擁有眾多的API，而且實(shí)現(xiàn)比較穩(wěn)定，bug數(shù)量也很少。但同時(shí)也由于HttpClient的API數(shù)量過(guò)多，使得我們很難在不破壞兼容性的情況下對(duì)它進(jìn)行升級(jí)和擴(kuò)展，所以目前Android團(tuán)隊(duì)在提升和優(yōu)化HttpClient方面的工作態(tài)度并不積極。

HttpURLConnection是一種多用途、輕量極的HTTP客戶端，使用它來(lái)進(jìn)行HTTP操作可以適用于大多數(shù)的應(yīng)用程序。雖然HttpURLConnection的API提供的比較簡(jiǎn)單，但是同時(shí)這也使得我們可以更加容易地去使用和擴(kuò)展它。不過(guò)在Android2.2版本之前，HttpURLConnection一直存在著一些令人厭煩的bug。比如說(shuō)對(duì)一個(gè)可讀的InputStream調(diào)用close方法時(shí)，就有可能會(huì)導(dǎo)致連接池失效了。那么我們通常的解決辦法就是直接禁用掉連接池的功能。Android2.3版本之前HttpURLConnection存在bug不建議使用，而在Android2.3版本及以后，HttpURLConnection則是最佳的選擇。它的API簡(jiǎn)單，體積較小，因而非常適用于Android項(xiàng)目。壓縮和緩存機(jī)制可以有效地減少網(wǎng)絡(luò)訪問(wèn)的流量，在提升速度和省電方面也起到了較大的作用。

目前來(lái)說(shuō)，我們有一個(gè)更好的請(qǐng)求選擇okhttp，volley源碼中并沒(méi)有封裝它的請(qǐng)求，我們可以自己實(shí)現(xiàn)HttpStack接口，在performRequest使用okhttp請(qǐng)求。OkHttp相較于其它的實(shí)現(xiàn)有以下的優(yōu)點(diǎn)：支持SPDY，允許連接同一主機(jī)的所有請(qǐng)求分享一個(gè)socket。如果SPDY不可用，會(huì)使用連接池減少請(qǐng)求延遲。使用GZIP壓縮下載內(nèi)容，且壓縮操作對(duì)用戶是透明的。利用響應(yīng)緩存來(lái)避免重復(fù)的網(wǎng)絡(luò)請(qǐng)求。當(dāng)網(wǎng)絡(luò)出現(xiàn)問(wèn)題的時(shí)候，OKHttp會(huì)依然有效，它將從常見的連接問(wèn)題當(dāng)中恢復(fù)。如果你的服務(wù)端有多個(gè)IP地址，當(dāng)?shù)谝粋€(gè)地址連接失敗時(shí)，OKHttp會(huì)嘗試連接其他的地址，這對(duì)IPV4和IPV6以及寄宿在多個(gè)數(shù)據(jù)中心的服務(wù)而言，是非常有必要的。使用OkHttp作為替代是一個(gè)很好的選擇。

緩存與線程處理

剛才說(shuō)有4個(gè)默認(rèn)線程是不準(zhǔn)確的，是有4個(gè)NetworkDispatcher執(zhí)行網(wǎng)絡(luò)請(qǐng)求，還有一個(gè)CacheDispatcher緩存線程，本地緩存策略需要實(shí)現(xiàn)Cache接口，源碼中有兩個(gè)實(shí)現(xiàn)DiskBasedCache，NoCache，默認(rèn)使用的是DiskBasedCache。我們可以根據(jù)自己的需要實(shí)現(xiàn)Cache接口。DiskBasedCache默認(rèn)路徑是app緩存目錄下的volley，默認(rèn)緩存5M，超出之后會(huì)覆蓋舊數(shù)據(jù)。

Request類

Request類的子類相當(dāng)于volley的輸入，是創(chuàng)建請(qǐng)求的時(shí)候用的。JsonObjectRequest、JsonArrayRequest用來(lái)處理返回是json的數(shù)據(jù)，StringRequest處理stirng，ImageRequest用來(lái)處理圖片。

Volley其實(shí)是一個(gè)生產(chǎn)者和消費(fèi)者系統(tǒng)，調(diào)用方是生產(chǎn)者，而Volley是消費(fèi)者。調(diào)用方通過(guò)RequestQueue生產(chǎn)Request，而Vollery消費(fèi)Request從而得到Response。那么負(fù)責(zé)調(diào)配這些生產(chǎn)者和消費(fèi)者的就是Dispatcher，分別是Cache和Network的Dispatcher。

總結(jié)

以上就是本文關(guān)于Volley源碼之使用方式和使用場(chǎng)景詳解的全部?jī)?nèi)容，希望對(duì)大家有所幫助。如有不足指出，歡迎留言指出。感謝朋友們對(duì)本站的支持！

最新評(píng)論