1.功能介紹
Android 異步網(wǎng)絡(luò)請求框架和圖片加載框架。特別適合數(shù)據(jù)量小，通信頻繁的網(wǎng)絡(luò)操作。而對于大數(shù)據(jù)量的網(wǎng)絡(luò)操作，比如說下載文件等，Volley的表現(xiàn)就會非常糟糕。
一個最基本的HTTP發(fā)送與響應(yīng)的功能分三步：
- 創(chuàng)建一個RequestQueue對象。
- 創(chuàng)建一個StringRequest對象。
- 將StringRequest對象添加到RequestQueue里面。
2.主要特點
- 擴展性強(可以定制任意類型的Request)。Volley 中大多是基于接口的設(shè)計，可配置性強。
- 一定程度符合 Http 規(guī)范，包括返回 ResponseCode(2xx、3xx、4xx、5xx）的處理，請求頭的處理，緩存機制的支持等。并支持重試及優(yōu)先級定義。
- 默認 Android2.3 及以上基于 HttpURLConnection，2.3 以下基于 HttpClient 實現(xiàn)。
- 提供簡便的圖片加載工具。
Volley框架的不足
- 它只適用于頻繁而數(shù)據(jù)量小的請求。（當請求的是比較大的數(shù)據(jù)時，這個Volley框架發(fā)揮的作用就不是很大了。)
- 它只實現(xiàn)了一級緩存(磁盤緩存)。(這樣做雖然節(jié)省內(nèi)存資源的消耗，但是讀寫數(shù)據(jù)的速度會比較慢。我們可以在這個基礎(chǔ)上進行優(yōu)化，多加一級內(nèi)存緩存，實現(xiàn)多級緩存。讀者可以自行對這個框架進行優(yōu)化。對于緩存機制，個人覺得可以學習下Universal image loader這個框架，里面有幾種緩存機制寫得很好)。
3.基本使用
3.1 導(dǎo)入類庫
implementation 'com.android.volley:volley:1.1.1'
3.2 配置權(quán)限
<uses-permission android:name="android.permission.INTERNET"/>
3.3 Get請求示例
// 1 創(chuàng)建一個請求隊列
RequestQueue requestQueue = Volley.newRequestQueue(this);
// 2 創(chuàng)建一個請求
String url = "http://192.168.3.6:8080/GetAndPostTest/MianTest";
StringRequest stringRequest = new StringRequest(url, new Response.Listener<String>() {
// 正確接收數(shù)據(jù)回調(diào)
@Override
public void onResponse(String s) {
Log.e("AppDebug", "onResponse: " + s);
}
}, new Response.ErrorListener() {
// 發(fā)生異常后的監(jiān)聽回調(diào)
@Override
public void onErrorResponse(VolleyError volleyError) {
Log.e("AppDebug", "onErrorResponse: " + volleyError);
}
});
// 3 將創(chuàng)建的請求添加到請求隊列中
requestQueue.add(stringRequest);
3.4 Post請求示例
// 1 創(chuàng)建一個請求隊列
RequestQueue requestQueue = Volley.newRequestQueue(this);
// 2 創(chuàng)建一個請求
String url = "http://192.168.3.6:8080/GetAndPostTest/MianTest";
StringRequest stringRequest = new StringRequest(Request.Method.POST, url, new Response.Listener<String>() {
// 正確接收數(shù)據(jù)回調(diào)
@Override
public void onResponse(String s) {
Log.e("AppDebug", "onResponse: " + s);
}
}, new Response.ErrorListener() {
// 發(fā)生異常后的監(jiān)聽回調(diào)
@Override
public void onErrorResponse(VolleyError volleyError) {
Log.e("AppDebug", "onErrorResponse: " + volleyError);
}
}) {
@Override
protected Map<String, String> getParams() throws AuthFailureError {
Map<String, String> map = new HashMap();
map.put("name", "param1");
return map;
}
};
// 3 將創(chuàng)建的請求添加到請求隊列中
requestQueue.add(stringRequest);
注：Post 請求是調(diào)用父類的getParams()方法獲得參數(shù)的。這里可以自定義自己的Volley版本。
3.5 Json請求示例
// 1 創(chuàng)建一個請求隊列
RequestQueue requestQueue = Volley.newRequestQueue(this);
// 2 創(chuàng)建一個請求
String url = "http://192.168.3.6:8080/GetAndPostTest/MianTest";
JsonObjectRequest jsonObjectRequest = new JsonObjectRequest(url, null, new Response.Listener<JSONObject>() {
@Override
public void onResponse(JSONObject jsonObject) {
Log.e("AppDebug", "onResponse: "+jsonObject.toString());
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError volleyError) {
Log.e("AppDebug", "onErrorResponse: "+volleyError);
}
});
// 3 將創(chuàng)建的請求添加到請求隊列中
requestQueue.add(jsonObjectRequest);
注：JsonRequest是一個抽象類有兩個直接的子類，JsonObjectRequest(請求一段JSON數(shù)據(jù)的)和JsonArrayRequest(請求一段JSON數(shù)組的)。
3.6 圖片請求示例
mImg.setImageResource(android.R.color.white);
// 1 創(chuàng)建一個請求隊列
RequestQueue requestQueue = Volley.newRequestQueue(this);
// 2 創(chuàng)建一個圖片的請求
String url = "http://img3.duitang.com/uploads/item/201510/11/20151011101817_fZ2hJ.thumb.700_0.jpeg";
ImageRequest imageRequest = new ImageRequest(url, new Response.Listener<Bitmap>() {
@Override
public void onResponse(Bitmap bitmap) {
// 正確接收到圖片
mImg.setVisibility(View.VISIBLE);
mImg.setImageBitmap(bitmap);
}
}, 0, 0, ImageView.ScaleType.CENTER, Bitmap.Config.RGB_565, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
//錯誤處理
}
});
// 3 將請求添加到請求隊列中
requestQueue.add(imageRequest);
注：ImageRequest構(gòu)造函數(shù)接收六個參數(shù)(ImageView.ScaleType.CENTER參數(shù)可有可無)，第一個參數(shù)就是圖片的URL地址。第二個參數(shù)是圖片請求成功的回調(diào)，這里我們把返回的Bitmap參數(shù)設(shè)置到ImageView中。第三第四個參數(shù)分別用于指定允許圖片最大的寬度和高度，如果指定的網(wǎng)絡(luò)圖片的寬度或高度大于這里的最大值，則會對圖片進行壓縮，指定成0的話就表示不管圖片有多大，都不會進行壓縮。第五個參數(shù)用于指定圖片的顏色屬性，Bitmap.Config下的幾個常量都可以在這里使用，其中ARGB_8888可以展示最好的顏色屬性，每個圖片像素占據(jù)4個字節(jié)的大小，而RGB_565則表示每個圖片像素占據(jù)2個字節(jié)大小。第六個參數(shù)是圖片請求失敗的回調(diào)，這里我們當請求失敗時在ImageView中顯示一張默認圖片。
3.7 ImageLoader 請求示例
// 1.創(chuàng)建一個請求隊列
RequestQueue requestQueue = Volley.newRequestQueue(this);
// 2.創(chuàng)建一個imageloader
ImageLoader imageLoader = new ImageLoader(requestQueue, new BitmapCache());
String url = "http://img3.duitang.com/uploads/item/201510/11/20151011101817_fZ2hJ.thumb.700_0.jpeg";
mImg.setVisibility(View.VISIBLE);
//3.獲取一個ImageListener對象
ImageLoader.ImageListener imageListener =ImageLoader.getImageListener(mImg,android.R.color.transparent,android.R.color.black);
//4.調(diào)用ImageLoader的get()方法加載網(wǎng)絡(luò)上的圖片
imageLoader.get(url, imageListener);
public class BitmapCache implements ImageLoader.ImageCache {
private LruCache<String, Bitmap> mCache;
public BitmapCache() {
int maxSize = 10 * 1024 * 1024;// 10m
mCache = new LruCache<String, Bitmap>(maxSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getRowBytes() * bitmap.getHeight();
}
};
}
@Override
public Bitmap getBitmap(String url) {
return mCache.get(url);
}
@Override
public void putBitmap(String url, Bitmap bitmap) {
mCache.put(url, bitmap);
}
}
注：ImageLoader明顯要比ImageRequest更加高效，因為它不僅可以幫我們對圖片進行緩存，還可以過濾掉重復(fù)的鏈接，避免重復(fù)發(fā)送請求。get()方法也可以接收四個參數(shù)，包含最大寬度和高度。新建一個BitmapCache并實現(xiàn)了ImageCache接口，實現(xiàn)圖片的緩存功能，這里借助了LruCache功能。參考Android高效加載大圖、多圖解決方案，有效避免程序OOM
3.8 框架附帶NetworkImageView控件示例
// 讓控件顯示
mNetworkImageView.setVisibility(View.VISIBLE);
// 默認圖片和異常圖片設(shè)置
mNetworkImageView.setDefaultImageResId(android.R.color.transparent);
mNetworkImageView.setErrorImageResId(android.R.color.black);
// 1.創(chuàng)建一個請求隊列
RequestQueue requestQueue = Volley.newRequestQueue(MainActivity.this);
// 2.創(chuàng)建一個Imageloader
ImageLoader imageLoader = new ImageLoader(requestQueue, new BitmapCache());
// 加載圖片
String url = "http://img3.duitang.com/uploads/item/201510/11/20151011101817_fZ2hJ.thumb.700_0.jpeg";
mNetworkImageView.setImageUrl(url, imageLoader);
//3.在布局文件中添加一個NetworkImageView控件
<com.android.volley.toolbox.NetworkImageView
android:id="@+id/network_image_view"
android:layout_width="150dp"
android:layout_height="150dp" />
注：NetworkImageView是一個自定義控制，它是繼承自ImageView的，具備ImageView控件的所有功能，并且在原生的基礎(chǔ)之上加入了加載網(wǎng)絡(luò)圖片的功能。NetworkImageView控件的用法要比前兩種方式更加簡單(NetworkImageView在加載圖片的時候它會自動獲取自身的寬高,壓縮過程是在內(nèi)部完全自動化的,并不需要提供任何設(shè)置最大寬高的方法也能夠?qū)虞d的圖片進行壓縮）
4.擴展實例(自定義Request)
Android Volley完全解析(三)，定制自己的Request
4.1參考StringRequest源碼
/**
* A canned request for retrieving the response body at a given URL as a String.
*/
public class StringRequest extends Request<String> {
private final Listener<String> mListener;
/**
* Creates a new request with the given method.
*
* @param method the request {@link Method} to use
* @param url URL to fetch the string at
* @param listener Listener to receive the String response
* @param errorListener Error listener, or null to ignore errors
*/
public StringRequest(int method, String url, Listener<String> listener,
ErrorListener errorListener) {
super(method, url, errorListener);
mListener = listener;
}
/**
* Creates a new GET request.
*
* @param url URL to fetch the string at
* @param listener Listener to receive the String response
* @param errorListener Error listener, or null to ignore errors
*/
public StringRequest(String url, Listener<String> listener, ErrorListener errorListener) {
this(Method.GET, url, listener, errorListener);
}
@Override
protected void deliverResponse(String response) {
mListener.onResponse(response);
}
@Override
protected Response<String> parseNetworkResponse(NetworkResponse response) {
String parsed;
try {
parsed = new String(response.data, HttpHeaderParser.parseCharset(response.headers));
} catch (UnsupportedEncodingException e) {
parsed = new String(response.data);
}
return Response.success(parsed, HttpHeaderParser.parseCacheHeaders(response));
}
}
注：StringRequest繼承自Request類，Request可以指定一個泛型類，這里是String。StringRequest中提供了兩個有參的構(gòu)造函數(shù)，參數(shù)包括請求類型，請求地址，以及響應(yīng)回調(diào)等。在構(gòu)造函數(shù)中一定要調(diào)用super()方法將這幾個參數(shù)傳給父類，因為HTTP的請求和響應(yīng)都是在父類中自動處理的。由于Request類中的deliverResponse()和parseNetworkResponse()是兩個抽象方法，因此StringRequest中需要對這兩個方法進行實現(xiàn)。deliverResponse()方法中的實現(xiàn)很簡單，僅僅是調(diào)用了mListener中的onResponse()方法，并將response內(nèi)容傳入即可，這樣就可以將服務(wù)器響應(yīng)的數(shù)據(jù)進行回調(diào)了。parseNetworkResponse()方法中則應(yīng)該對服務(wù)器響應(yīng)的數(shù)據(jù)進行解析，其中數(shù)據(jù)是以字節(jié)的形式存放在NetworkResponse的data變量中的，這里將數(shù)據(jù)取出然后組裝成一個String，并傳入Response的success()方法中即可。
4.2 自定義XMLRequest
public class XMLRequest extends Request<XmlPullParser> {
private final Listener<XmlPullParser> mListener;
public XMLRequest(int method, String url, Listener<XmlPullParser> listener,ErrorListener errorListener) {
super(method, url, errorListener);
mListener = listener;
}
public XMLRequest(String url, Listener<XmlPullParser> listener, ErrorListener errorListener) {
this(Method.GET, url, listener, errorListener);
}
@Override
protected Response<XmlPullParser> parseNetworkResponse(NetworkResponse response) {
try {
String xmlString = new String(response.data,HttpHeaderParser.parseCharset(response.headers));
XmlPullParserFactory factory = XmlPullParserFactory.newInstance();
XmlPullParser xmlPullParser = factory.newPullParser();
xmlPullParser.setInput(new StringReader(xmlString));
return Response.success(xmlPullParser, HttpHeaderParser.parseCacheHeaders(response));
} catch (UnsupportedEncodingException e) {
return Response.error(new ParseError(e));
} catch (XmlPullParserException e) {
return Response.error(new ParseError(e));
}
}
@Override
protected void deliverResponse(XmlPullParser response) {
mListener.onResponse(response);
}
}
4.3 自定義GsonRequest
public class GsonRequest<T> extends Request<T> {
private final Listener<T> mListener;
private Gson mGson;
private Class<T> mClass;
public GsonRequest(int method, String url, Class<T> clazz, Listener<T> listener,ErrorListener errorListener) {
super(method, url, errorListener);
mGson = new Gson();
mClass = clazz;
mListener = listener;
}
public GsonRequest(String url, Class<T> clazz, Listener<T> listener,ErrorListener errorListener) {
this(Method.GET, url, clazz, listener, errorListener);
}
@Override
protected Response<T> parseNetworkResponse(NetworkResponse response) {
try {
String jsonString = new String(response.data,
HttpHeaderParser.parseCharset(response.headers));
return Response.success(mGson.fromJson(jsonString, mClass), HttpHeaderParser.parseCacheHeaders(response));
} catch (UnsupportedEncodingException e) {
return Response.error(new ParseError(e));
}
}
@Override
protected void deliverResponse(T response) {
mListener.onResponse(response);
}
}
5.設(shè)計
5.1總體設(shè)計圖
上面是 Volley 的總體設(shè)計圖，主要是通過兩種Diapatch Thread不斷從RequestQueue中取出請求，根據(jù)是否已緩存調(diào)用Cache或Network這兩類數(shù)據(jù)獲取接口之一，從內(nèi)存緩存或是服務(wù)器取得請求的數(shù)據(jù)，然后交由ResponseDelivery去做結(jié)果分發(fā)及回調(diào)處理。
Volley框架使用了線程池作為基礎(chǔ)結(jié)構(gòu)，主要分為主線程(UI線程)、CacheDispatcher線程和NetworkDispatcher線程。其中主線程和CacheDispatcher線程都只有一個，而NetworkDispatcher線程可以有多個，默認為4個，也就是在初始化Volley框架后會在后臺默認運行這5個線程，并且所有的網(wǎng)絡(luò)請求都會復(fù)用這5個線程。
5.2詳細設(shè)計
Volley 的調(diào)用比較簡單，通過 newRequestQueue(…) 函數(shù)新建并啟動一個請求隊列RequestQueue后，只需要往這個RequestQueue不斷 add Request 即可。
Volley：Volley 對外暴露的 API，通過 newRequestQueue(…) 函數(shù)新建并啟動一個請求隊列RequestQueue。
Request：表示一個請求的抽象類。StringRequest、JsonRequest、ImageRequest 都是它的子類，表示某種類型的請求。
RequestQueue：表示請求隊列，里面包含一個CacheDispatcher(用于處理走緩存請求的調(diào)度線程)、NetworkDispatcher數(shù)組(用于處理走網(wǎng)絡(luò)請求的調(diào)度線程)，一個ResponseDelivery(返回結(jié)果分發(fā)接口)，通過 start() 函數(shù)啟動時會啟動CacheDispatcher和NetworkDispatchers。
CacheDispatcher：一個線程，用于調(diào)度處理走緩存的請求。啟動后會不斷從緩存請求隊列中取請求處理，隊列為空則等待，請求處理結(jié)束則將結(jié)果傳遞給ResponseDelivery去執(zhí)行后續(xù)處理。當結(jié)果未緩存過、緩存失效或緩存需要刷新的情況下，該請求都需要重新進入NetworkDispatcher去調(diào)度處理。
NetworkDispatcher：一個線程，用于調(diào)度處理走網(wǎng)絡(luò)的請求。啟動后會不斷從網(wǎng)絡(luò)請求隊列中取請求處理，隊列為空則等待，請求處理結(jié)束則將結(jié)果傳遞給ResponseDelivery去執(zhí)行后續(xù)處理，并判斷結(jié)果是否要進行緩存。
ResponseDelivery：返回結(jié)果分發(fā)接口，目前只有基于ExecutorDelivery的在入?yún)?handler 對應(yīng)線程內(nèi)進行分發(fā)。
HttpStack：處理 Http 請求，返回請求結(jié)果。目前 Volley 中有基于 HttpURLConnection 的HurlStack和 基于 Apache HttpClient 的HttpClientStack。
Network：調(diào)用HttpStack處理請求，并將結(jié)果轉(zhuǎn)換為可被ResponseDelivery處理的NetworkResponse。
Cache：緩存請求結(jié)果，Volley 默認使用的是基于 sdcard 的DiskBasedCache。NetworkDispatcher得到請求結(jié)果后判斷是否需要存儲在 Cache，CacheDispatcher會從 Cache 中取緩存結(jié)果。
5.3請求流程圖
其中藍色部分代表主線程，綠色部分代表緩存線程，橙色部分代表網(wǎng)絡(luò)線程。我們在主線程中調(diào)用RequestQueue的add()方法來添加一條網(wǎng)絡(luò)請求，這條請求會先被加入到緩存隊列當中，如果發(fā)現(xiàn)可以找到相應(yīng)的緩存結(jié)果就直接讀取緩存并解析，然后回調(diào)給主線程。如果在緩存中沒有找到結(jié)果，則將這條請求加入到網(wǎng)絡(luò)請求隊列中，然后處理發(fā)送HTTP請求，解析響應(yīng)結(jié)果，寫入緩存，并回調(diào)主線程。
5.4類關(guān)系圖
圖中紅色圈內(nèi)的部分，組成了 Volley 框架的核心，圍繞 RequestQueue 類，將各個功能點以組合的方式結(jié)合在了一起。各個功能點也都是以接口或者抽象類的形式提供。
紅色圈外面的部分，在 Volley 源碼中放在了 toolbox 包中，作為 Volley 為各個功能點提供的默認的具體實現(xiàn)。
通過類圖我們看出， Volley 有著非常好的拓展性。通過各個功能點的接口，我們可以給出自定義的，更符合我們需求的具體實現(xiàn)。
多用組合，少用繼承；針對接口編程，不針對具體實現(xiàn)編程。
優(yōu)秀框架的設(shè)計，令人叫絕，受益良多。
6.核心類功能介紹
6.1 Volley.java
這個和 Volley 框架同名的類，其實是個工具類，作用是構(gòu)建一個可用于添加網(wǎng)絡(luò)請求的RequestQueue對象。
(1). 主要函數(shù)
Volley.java 有兩個重載的靜態(tài)方法。
public static RequestQueue newRequestQueue(Context context)
public static RequestQueue newRequestQueue(Context context, HttpStack stack)
第一個方法的實現(xiàn)調(diào)用了第二個方法，傳 HttpStack 參數(shù)為 null。
第二個方法中，如果 HttpStatck 參數(shù)為 null，則如果系統(tǒng)在 Gingerbread 及之后(即 API Level >= 9)，采用基于 HttpURLConnection 的 HurlStack，如果小于 9，采用基于 HttpClient 的 HttpClientStack。
if (stack == null) {
if (Build.VERSION.SDK_INT >= 9) {
stack = new HurlStack();
} else {
stack = new HttpClientStack(AndroidHttpClient.newInstance(userAgent));
}
}
得到了 HttpStack,然后通過它構(gòu)造一個代表網(wǎng)絡(luò)（Network）的具體實現(xiàn)BasicNetwork。
接著構(gòu)造一個代表緩存（Cache）的基于 Disk 的具體實現(xiàn)DiskBasedCache。
最后將網(wǎng)絡(luò)（Network）對象和緩存（Cache）對象傳入構(gòu)建一個 RequestQueue，啟動這個 RequestQueue，并返回。
Network network = new BasicNetwork(stack);
RequestQueue queue = new RequestQueue(new DiskBasedCache(cacheDir), network);
queue.start();
return queue;
我們平時大多采用Volly.newRequestQueue(context)的默認實現(xiàn)，構(gòu)建 RequestQueue。
通過源碼可以看出，我們可以拋開 Volley 工具類構(gòu)建自定義的 RequestQueue，采用自定義的HttpStatck，采用自定義的Network實現(xiàn)，采用自定義的 Cache 實現(xiàn)等來構(gòu)建RequestQueue。
優(yōu)秀框架的高可拓展性的魅力來源于此啊
(2). HttpURLConnection 和 AndroidHttpClient(HttpClient 的封裝)如何選擇及原因：
在 Froyo(2.2) 之前，HttpURLConnection 有個重大 Bug，調(diào)用 close() 函數(shù)會影響連接池，導(dǎo)致連接復(fù)用失效，所以在 Froyo 之前使用 HttpURLConnection 需要關(guān)閉 keepAlive。
另外在 Gingerbread(2.3) HttpURLConnection 默認開啟了 gzip 壓縮，提高了 HTTPS 的性能，Ice Cream Sandwich(4.0) HttpURLConnection 支持了請求結(jié)果緩存。
再加上 HttpURLConnection 本身 API 相對簡單，所以對 Android 來說，在 2.3 之后建議使用 HttpURLConnection，之前建議使用 AndroidHttpClient。
(3). 關(guān)于 User Agent
通過代碼我們發(fā)現(xiàn)如果是使用 AndroidHttpClient，Volley 還會將請求頭中的 User-Agent 字段設(shè)置為App 的{versionCode}，如果異常則使用 "volley/0"，不過這個獲取 User-Agent 的操作應(yīng)該放到 if else 內(nèi)部更合適。而對于 HttpURLConnection 卻沒有任何操作，為什么呢？
如果用 Fiddler 或 Charles 對數(shù)據(jù)抓包我們會發(fā)現(xiàn)，我們會發(fā)現(xiàn) HttpURLConnection 默認是有 User-Agent 的，類似：
Dalvik/1.6.0 (Linux; U; Android 4.1.1; Google Nexus 4 - 4.1.1 - API 16 - 768x1280_1 Build/JRO03S)
經(jīng)常用 WebView 的同學會也許會發(fā)現(xiàn)似曾相識，是的，WebView 默認的 User-Agent 也是這個。實際在請求發(fā)出之前，會檢測 User-Agent 是否為空，如果不為空，則加上系統(tǒng)默認 User-Agent。在 Android 2.1 之后，我們可以通過
String userAgent = System.getProperty("http.agent");
得到系統(tǒng)默認的 User-Agent，Volley 如果希望自定義 User-Agent，可在自定義 Request 中重寫 getHeaders() 函數(shù)
@Override
public Map<String, String> getHeaders() throws AuthFailureError {
// self-defined user agent
Map<String, String> headerMap = new HashMap<String, String>();
headerMap.put("User-Agent", "android-open-project-analysis/1.0");
return headerMap;
}
6.2 Request.java
代表一個網(wǎng)絡(luò)請求的抽象類。我們通過構(gòu)建一個Request類的非抽象子類(StringRequest、JsonRequest、ImageRequest 或自定義)對象，并將其加入到·RequestQueue·中來完成一次網(wǎng)絡(luò)請求操作。
Volley 支持 8 種 Http 請求方式 GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, PATCH
Request 類中包含了請求 url，請求請求方式，請求 Header，請求 Body，請求的優(yōu)先級等信息。
因為是抽象類，子類必須重寫的兩個方法。
abstract protected Response<T> parseNetworkResponse(NetworkResponse response);
子類重寫此方法，將網(wǎng)絡(luò)返回的原生字節(jié)內(nèi)容，轉(zhuǎn)換成合適的類型。此方法會在工作線程中被調(diào)用。
abstract protected void deliverResponse(T response);
子類重寫此方法，將解析成合適類型的內(nèi)容傳遞給它們的監(jiān)聽回調(diào)。
以下兩個方法也經(jīng)常會被重寫
public byte[] getBody()
重寫此方法，可以構(gòu)建用于 POST、PUT、PATCH 請求方式的 Body 內(nèi)容。
protected Map<String, String> getParams()
在上面getBody函數(shù)沒有被重寫情況下，此方法的返回值會被 key、value 分別編碼后拼裝起來轉(zhuǎn)換為字節(jié)碼作為 Body 內(nèi)容。
6.3 RequestQueue.java
Volley 框架的核心類，將請求 Request 加入到一個運行的RequestQueue中，來完成請求操作。
(1). 主要成員變量
RequestQueue 中維護了兩個基于優(yōu)先級的 Request 隊列，緩存請求隊列和網(wǎng)絡(luò)請求隊列。
放在緩存請求隊列中的 Request，將通過緩存獲取數(shù)據(jù)；放在網(wǎng)絡(luò)請求隊列中的 Request，將通過網(wǎng)絡(luò)獲取數(shù)據(jù)。
private final PriorityBlockingQueue<Request<?>> mCacheQueue = new PriorityBlockingQueue<Request<?>>();
private final PriorityBlockingQueue<Request<?>> mNetworkQueue = new PriorityBlockingQueue<Request<?>>();
維護了一個正在進行中，尚未完成的請求集合。
private final Set<Request<?>> mCurrentRequests = new HashSet<Request<?>>();
維護了一個等待請求的集合，如果一個請求正在被處理并且可以被緩存，后續(xù)的相同 url 的請求，將進入此等待隊列。
private final Map<String, Queue<Request<?>>> mWaitingRequests = new HashMap<String, Queue<Request<?>>>();
(2). 啟動隊列
創(chuàng)建出 RequestQueue 以后，調(diào)用 start 方法，啟動隊列。
/**
* Starts the dispatchers in this queue.
*/
public void start() {
stop(); // Make sure any currently running dispatchers are stopped.
// Create the cache dispatcher and start it.
mCacheDispatcher = new CacheDispatcher(mCacheQueue, mNetworkQueue, mCache, mDelivery);
mCacheDispatcher.start();
// Create network dispatchers (and corresponding threads) up to the pool size.
for (int i = 0; i < mDispatchers.length; i++) {
NetworkDispatcher networkDispatcher = new NetworkDispatcher(mNetworkQueue, mNetwork,
mCache, mDelivery);
mDispatchers[i] = networkDispatcher;
networkDispatcher.start();
}
}
start 方法中，開啟一個緩存調(diào)度線程CacheDispatcher和 n 個網(wǎng)絡(luò)調(diào)度線程NetworkDispatcher，這里 n 默認為 4，存在優(yōu)化的余地，比如可以根據(jù) CPU 核數(shù)以及網(wǎng)絡(luò)類型計算更合適的并發(fā)數(shù)。
緩存調(diào)度線程不斷的從緩存請求隊列中取出 Request 去處理，網(wǎng)絡(luò)調(diào)度線程不斷的從網(wǎng)絡(luò)請求隊列中取出 Request 去處理。
(3). 加入請求
public <T> Request<T> add(Request<T> request);
流程圖如下：
[圖片上傳失敗...(image-4a0c-1600141169919)]
(4). 請求完成
void finish(Request<?> request)
Request 請求結(jié)束
(1). 首先從正在進行中請求集合
mCurrentRequests中移除該請求。
(2). 然后查找請求等待集合mWaitingRequests中是否存在等待的請求，如果存在，則將等待隊列移除，并將等待隊列所有的請求添加到緩存請求隊列中，讓緩存請求處理線程CacheDispatcher自動處理。
(5). 請求取消
public void cancelAll(RequestFilter filter)
public void cancelAll(final Object tag)
取消當前請求集合中所有符合條件的請求。
filter 參數(shù)表示可以按照自定義的過濾器過濾需要取消的請求。
tag 表示按照Request.setTag設(shè)置好的 tag 取消請求，比如同屬于某個 Activity 的。
6.4 CacheDispatcher.java
一個線程，用于調(diào)度處理走緩存的請求。啟動后會不斷從緩存請求隊列中取請求處理，隊列為空則等待，請求處理結(jié)束則將結(jié)果傳遞給ResponseDelivery 去執(zhí)行后續(xù)處理。當結(jié)果未緩存過、緩存失效或緩存需要刷新的情況下，該請求都需要重新進入NetworkDispatcher去調(diào)度處理。
(1). 成員變量
BlockingQueue<Request<?>> mCacheQueue 緩存請求隊列
BlockingQueue<Request<?>> mNetworkQueue 網(wǎng)絡(luò)請求隊列
Cache mCache 緩存類，代表了一個可以獲取請求結(jié)果，存儲請求結(jié)果的緩存
ResponseDelivery mDelivery 請求結(jié)果傳遞類
(2). 處理流程圖
[圖片上傳失敗...(image-a41af-1600141509364)]
6.5 NetworkDispatcher.java
一個線程，用于調(diào)度處理走網(wǎng)絡(luò)的請求。啟動后會不斷從網(wǎng)絡(luò)請求隊列中取請求處理，隊列為空則等待，請求處理結(jié)束則將結(jié)果傳遞給 ResponseDelivery 去執(zhí)行后續(xù)處理，并判斷結(jié)果是否要進行緩存。
(1). 成員變量
BlockingQueue<Request<?>> mQueue 網(wǎng)絡(luò)請求隊列
Network mNetwork 網(wǎng)絡(luò)類，代表了一個可以執(zhí)行請求的網(wǎng)絡(luò)
Cache mCache 緩存類，代表了一個可以獲取請求結(jié)果，存儲請求結(jié)果的緩存
ResponseDelivery mDelivery 請求結(jié)果傳遞類，可以傳遞請求的結(jié)果或者錯誤到調(diào)用者
(2). 處理流程圖
[圖片上傳失敗...(image-a1dfbe-1600141509364)]
6.6 Cache.java
緩存接口，代表了一個可以獲取請求結(jié)果，存儲請求結(jié)果的緩存。
(1). 主要方法：
public Entry get(String key); 通過 key 獲取請求的緩存實體
public void put(String key, Entry entry); 存入一個請求的緩存實體
public void remove(String key); 移除指定的緩存實體
public void clear(); 清空緩存
(2). 代表緩存實體的內(nèi)部類 Entry
成員變量和方法
byte[] data 請求返回的數(shù)據(jù)（Body 實體）
String etag Http 響應(yīng)首部中用于緩存新鮮度驗證的 ETag
long serverDate Http 響應(yīng)首部中的響應(yīng)產(chǎn)生時間
long ttl 緩存的過期時間
long softTtl 緩存的新鮮時間
Map<String, String> responseHeaders 響應(yīng)的 Headers
boolean isExpired() 判斷緩存是否過期，過期緩存不能繼續(xù)使用
boolean refreshNeeded() 判斷緩存是否新鮮，不新鮮的緩存需要發(fā)到服務(wù)端做新鮮度的檢測
6.7 DiskBasedCache.java
繼承 Cache 類，基于 Disk 的緩存實現(xiàn)類。
(1). 主要方法：
public synchronized void initialize() 初始化，掃描緩存目錄得到所有緩存數(shù)據(jù)摘要信息放入內(nèi)存。
public synchronized Entry get(String key) 從緩存中得到數(shù)據(jù)。先從摘要信息中得到摘要信息，然后讀取緩存數(shù)據(jù)文件得到內(nèi)容。
public synchronized void put(String key, Entry entry) 將數(shù)據(jù)存入緩存內(nèi)。先檢查緩存是否會滿，會則先刪除緩存中部分數(shù)據(jù)，然后再新建緩存文件。
private void pruneIfNeeded(int neededSpace) 檢查是否能再分配 neededSpace 字節(jié)的空間，如果不能則刪除緩存中部分數(shù)據(jù)。
public synchronized void clear() 清空緩存。 public synchronized void remove(String key) 刪除緩存中某個元素。
(2). CacheHeader 類
CacheHeader 是緩存文件摘要信息，存儲在緩存文件的頭部，與上面的Cache.Entry相似。
6.8 NoCache.java
繼承 Cache 類，不做任何操作的緩存實現(xiàn)類，可將它作為構(gòu)建
RequestQueue的參數(shù)以實現(xiàn)一個不帶緩存的請求隊列。
6.9 Network.java
代表網(wǎng)絡(luò)的接口，處理網(wǎng)絡(luò)請求。
唯一的方法，用于執(zhí)行特定請求。
public NetworkResponse performRequest(Request<?> request) throws VolleyError;
6.10 NetworkResponse.java
Network中方法 performRequest 的返回值，Request的 parseNetworkResponse(…) 方法入?yún)?，?Volley 中用于內(nèi)部 Response 轉(zhuǎn)換的一級。
封裝了網(wǎng)絡(luò)請求響應(yīng)的 StatusCode，Headers 和 Body 等。
(1). 成員變量
int statusCode Http 響應(yīng)狀態(tài)碼
byte[] data Body 數(shù)據(jù)
Map<String, String> headers 響應(yīng) Headers
boolean notModified 表示是否為 304 響應(yīng)
long networkTimeMs 請求耗時
(2). Volley 的內(nèi)部 Response 轉(zhuǎn)換流程圖
[圖片上傳失敗...(image-623f17-1600141509363)]
從上到下表示從得到數(shù)據(jù)后一步步的處理，箭頭旁的注釋表示該步處理后的實體類。
6.11 BasicNetwork.java
實現(xiàn) Network，Volley 中默認的網(wǎng)絡(luò)接口實現(xiàn)類。調(diào)用
HttpStack處理請求，并將結(jié)果轉(zhuǎn)換為可被ResponseDelivery處理的NetworkResponse。
主要實現(xiàn)了以下功能：
(1). 利用 HttpStack 執(zhí)行網(wǎng)絡(luò)請求。
(2). 如果 Request 中帶有實體信息，如 Etag,Last-Modify 等，則進行緩存新鮮度的驗證，并處理 304（Not Modify）響應(yīng)。
(3). 如果發(fā)生超時，認證失敗等錯誤，進行重試操作，直到成功、拋出異常(不滿足重試策略等)結(jié)束。
6.12 HttpStack.java
用于處理 Http 請求，返回請求結(jié)果的接口。目前 Volley 中的實現(xiàn)有基于 HttpURLConnection 的 HurlStack 和 基于 Apache HttpClient 的 HttpClientStack。
唯一方法，執(zhí)行請求
public HttpResponse performRequest(Request<?> request, Map<String, String> additionalHeaders)
throws IOException, AuthFailureError;
執(zhí)行 Request 代表的請求，第二個參數(shù)表示發(fā)起請求之前，添加額外的請求 Headers。
6.13 HttpClientStack.java
實現(xiàn) HttpStack 接口，利用 Apache 的 HttpClient 進行各種請求方式的請求。
基本就是 org.apache.http 包下面相關(guān)類的常見用法，不做詳解，不過與下面 HttpURLConnection 做下對比就能發(fā)現(xiàn) HttpURLConnection 的 API 相對簡單的多。
6.14 HurlStack.java
實現(xiàn) HttpStack 接口，利用 Java 的 HttpURLConnection 進行各種請求方式的請求。
6.15 Response.java
封裝了經(jīng)過解析后的數(shù)據(jù)，用于傳輸。并且有兩個內(nèi)部接口 Listener 和 ErrorListener 分別可表示請求失敗和成功后的回調(diào)。
Response 的構(gòu)造函數(shù)被私有化，而通過兩個函數(shù)名更易懂的靜態(tài)方法構(gòu)建對象。
6.16 ByteArrayPool.java
byte[] 的回收池，用于 byte[] 的回收再利用，減少了內(nèi)存的分配和回收。 主要通過一個元素長度從小到大排序的ArrayList作為 byte[] 的緩存，另有一個按使用時間先后排序的ArrayList屬性用于緩存滿時清理元素。
public synchronized void returnBuf(byte[] buf)
將用過的 byte[] 回收，根據(jù) byte[] 長度按照從小到大的排序?qū)?byte[] 插入到緩存中合適位置。
public synchronized byte[] getBuf(int len)
獲取長度不小于 len 的 byte[]，遍歷緩存，找出第一個長度大于傳入?yún)?shù)len的 byte[]，并返回；如果最終沒有合適的 byte[]，new 一個返回。
private synchronized void trim()
當緩存的 byte 超過預(yù)先設(shè)置的大小時，按照先進先出的順序刪除最早的 byte[]。
6.17 PoolingByteArrayOutputStream.java
繼承 ByteArrayOutputStream，原始 ByteArrayOutputStream 中用于接受寫入 bytes 的 buf，每次空間不足時便會 new 更大容量的 byte[]，而 PoolingByteArrayOutputStream 使用了 ByteArrayPool 作為 Byte[] 緩存來減少這種操作，從而提高性能。
6.18 HttpHeaderParser.java
Http header 的解析工具類，在 Volley 中主要作用是用于解析 Header 從而判斷返回結(jié)果是否需要緩存，如果需要返回 Header 中相關(guān)信息。
有三個方法
public static long parseDateAsEpoch(String dateStr)
解析時間，將 RFC1123 的時間格式，解析成 epoch 時間
public static String parseCharset(Map<String, String> headers)
解析編碼集，在 Content-Type 首部中獲取編碼集，如果沒有找到，默認返回 ISO-8859-1
public static Cache.Entry parseCacheHeaders(NetworkResponse response)
比較重要的方法，通過網(wǎng)絡(luò)響應(yīng)中的緩存控制 Header 和 Body 內(nèi)容，構(gòu)建緩存實體。如果 Header 的 Cache-Control 字段含有no-cache或no-store表示不緩存，返回 null。
(1). 根據(jù) Date 首部，獲取響應(yīng)生成時間
(2). 根據(jù) ETag 首部，獲取響應(yīng)實體標簽
(3). 根據(jù) Cache－Control 和 Expires 首部，計算出緩存的過期時間，和緩存的新鮮度時間
兩點需要說明下：
1.沒有處理Last-Modify首部，而是處理存儲了Date首部，并在后續(xù)的新鮮度驗證時，使用Date來構(gòu)建If-Modified-Since。 這與 Http 1.1 的語義有些違背。
2.計算過期時間，Cache－Control 首部優(yōu)先于 Expires 首部。
6.19 RetryPolicy.java
重試策略接口
有三個方法：
public int getCurrentTimeout();
獲取當前請求用時（用于 Log）
public int getCurrentRetryCount();
獲取已經(jīng)重試的次數(shù)（用于 Log）
public void retry(VolleyError error) throws VolleyError;
確定是否重試，參數(shù)為這次異常的具體信息。在請求異常時此接口會被調(diào)用，可在此函數(shù)實現(xiàn)中拋出傳入的異常表示停止重試。
6.20 DefaultRetryPolicy.java
實現(xiàn) RetryPolicy，Volley 默認的重試策略實現(xiàn)類。主要通過在 retry(…) 函數(shù)中判斷重試次數(shù)是否達到上限確定是否繼續(xù)重試。
其中mCurrentRetryCount變量表示已經(jīng)重試次數(shù)。
mBackoffMultiplier表示每次重試之前的 timeout 該乘以的因子。
mCurrentTimeoutMs變量表示當前重試的 timeout 時間，會以mBackoffMultiplier作為因子累計前幾次重試的 timeout。
4.2.21 ResponseDelivery.java
請求結(jié)果的傳輸接口，用于傳遞請求結(jié)果或者請求錯誤。
有三個方法：
public void postResponse(Request<?> request, Response<?> response);
此方法用于傳遞請求結(jié)果，request 和 response 參數(shù)分別表示請求信息和返回結(jié)果信息。
public void postResponse(Request<?> request, Response<?> response, Runnable runnable);
此方法用于傳遞請求結(jié)果，并在完成傳遞后執(zhí)行 Runnable。
public void postError(Request<?> request, VolleyError error);
此方法用于傳輸請求錯誤。
6.22 ExecutorDelivery.java
請求結(jié)果傳輸接口具體實現(xiàn)類。
在 Handler 對應(yīng)線程中傳輸緩存調(diào)度線程或者網(wǎng)絡(luò)調(diào)度線程中產(chǎn)生的請求結(jié)果或請求錯誤，會在請求成功的情況下調(diào)用 Request.deliverResponse(…) 函數(shù)，失敗時調(diào)用 Request.deliverError(…) 函數(shù)。
6.23 StringRequest.java
繼承 Request 類,代表了一個返回值為 String 的請求。將網(wǎng)絡(luò)返回的結(jié)果數(shù)據(jù)解析為 String 類型。通過構(gòu)造函數(shù)的 listener 傳參，支持請求成功后的 onResponse(…) 回調(diào)。
6.24 JsonRequest.java
抽象類，繼承自 Request，代表了 body 為 JSON 的請求。提供了構(gòu)建 JSON 請求參數(shù)的方法。
6.25 JsonObjectRequest.java
繼承自 JsonRequest，將網(wǎng)絡(luò)返回的結(jié)果數(shù)據(jù)解析為 JSONObject 類型。
6.26 JsonArrayRequest.java
繼承自 JsonRequest，將網(wǎng)絡(luò)返回的結(jié)果數(shù)據(jù)解析為 JSONArray 類型。
6.27 ImageRequest.java
繼承 Request 類，代表了一個返回值為 Image 的請求。將網(wǎng)絡(luò)返回的結(jié)果數(shù)據(jù)解析為 Bitmap 類型。
可以設(shè)置圖片的最大寬度和最大高度，并計算出合適尺寸返回。每次最多解析一張圖片防止 OOM。
6.28 ImageLoader.java
封裝了 ImageRequst 的方便使用的圖片加載工具類。
1.可以設(shè)置自定義的
ImageCache，可以是內(nèi)存緩存，也可以是 Disk 緩存，將獲取的圖片緩存起來，重復(fù)利用，減少請求。
2.可以定義圖片請求過程中顯示的圖片和請求失敗后顯示的圖片。
3.相同請求（相同地址，相同大小）只發(fā)送一個，可以避免重復(fù)請求。
// TODO
6.29 NetworkImageView.java
利用 ImageLoader，可以加載網(wǎng)絡(luò)圖片的 ImageView
有三個公開的方法：
public void setDefaultImageResId(int defaultImage)
設(shè)置默認圖片，加載圖片過程中顯示。
public void setErrorImageResId(int errorImage)
設(shè)置錯誤圖片，加載圖片失敗后顯示。
public void setImageUrl(String url, ImageLoader imageLoader)
設(shè)置網(wǎng)絡(luò)圖片的 Url 和 ImageLoader，將利用這個 ImageLoader 去獲取網(wǎng)絡(luò)圖片。
如果有新的圖片加載請求，會把這個 ImageView 上舊的加載請求取消。
6.30 ClearCacheRequest.java
用于人為清空 Http 緩存的請求。
添加到 RequestQueue 后能很快執(zhí)行，因為優(yōu)先級很高，為Priority.IMMEDIATE。并且清空緩存的方法mCache.clear()寫在了isCanceled()方法體中，能最早的得到執(zhí)行。
ClearCacheRequest 的寫法不敢茍同，目前看來唯一的好處就是可以將清空緩存操作也當做一個請求。而在isCanceled()中做清空操作本身就造成了歧義，不看源碼沒人知道在NetworkDispatcherrun 方法循環(huán)的過程中，isCanceled()這個讀操作竟然做了可能造成緩存被清空。只能跟源碼的解釋一樣當做一個 Hack 操作。
6.31 Authenticator.java
身份認證接口，用于基本認證或者摘要認證。這個類是 Volley 用于和身份驗證打通的接口，比如 OAuth，不過目前的使用不是特別廣泛和 Volley 的內(nèi)部結(jié)合也不是特別緊密。
6.32 AndroidAuthenticator.java
繼承 Authenticator，基于 Android AccountManager 的認證交互實現(xiàn)類。
6.33 VolleyLog.java
Volley 的 Log 工具類。
6.34 VolleyError.java
Volley 中所有錯誤異常的父類，繼承自 Exception，可通過此類設(shè)置和獲取 NetworkResponse 或者請求的耗時。
6.35 AuthFailureError.java
繼承自 VolleyError，代表請求認證失敗錯誤，如 RespondeCode 的 401 和 403。
6.36 NetworkError.java
繼承自 VolleyError，代表網(wǎng)絡(luò)錯誤。
6.37 ParseError.java
繼承自 VolleyError，代表內(nèi)容解析錯誤。
6.38 ServerError.java
繼承自 VolleyError，代表服務(wù)端錯誤。
6.39 TimeoutError.java
繼承自 VolleyError，代表請求超時錯誤。
6.40 NoConnectionError.java
繼承自 NetworkError，代表無法建立連接錯誤。
7. 其他
7.1 關(guān)于 Http 緩存
Volley 構(gòu)建了一套相對完整的符合 Http 語義的緩存機制。
優(yōu)點和特點
(1). 根據(jù)Cache-Control和Expires首部來計算緩存的過期時間。如果兩個首部都存在情況下，以Cache-Control為準。
(2). 利用If-None-Match和If-Modified-Since對過期緩存或者不新鮮緩存，進行請求再驗證，并處理 304 響應(yīng)，更新緩存。
(3). 默認的緩存實現(xiàn)，將緩存以文件的形式存儲在 Disk，程序退出后不會丟失。
緩存的再驗證方面，在構(gòu)建If-Modified-Since請求首部時，Volley 使用了服務(wù)端響應(yīng)的Date首部，沒有使用Last-Modified首部。整個框架沒有使用Last-Modified首部。這與 Http 語義不符。
private void addCacheHeaders(Map<String, String> headers, Cache.Entry entry) {
// If there's no cache entry, we're done.
if (entry == null) {
return;
}
if (entry.etag != null) {
headers.put("If-None-Match", entry.etag);
}
if (entry.serverDate > 0) {
Date refTime = new Date(entry.serverDate);
headers.put("If-Modified-Since", DateUtils.formatDate(refTime));
}
}
服務(wù)端根據(jù)請求時通過If-Modified-Since首部傳過來的時間，判斷資源文件是否在If-Modified-Since時間 以后 有改動，如果有改動，返回新的請求結(jié)果。如果沒有改動，返回 304 not modified。
Last-Modified代表了資源文件的最后修改時間。通常使用這個首部構(gòu)建If-Modified-Since的時間。
Date代表了響應(yīng)產(chǎn)生的時間，正常情況下Date時間在Last-Modified時間之后。也就是Date>=Last-Modified。
通過以上原理，既然Date>=Last-Modified。那么我利用Date構(gòu)建，也是完全正確的。
可能的問題出在服務(wù)端的 Http 實現(xiàn)上，如果服務(wù)端完全遵守 Http 語義，采用時間比較的方式來驗證If-Modified-Since，判斷服務(wù)器資源文件修改時間是不是在If-Modified-Since之后。那么使用Date完全正確。
可是有的服務(wù)端實現(xiàn)不是比較時間，而是直接的判斷服務(wù)器資源文件修改時間，是否和If-Modified-Since所傳時間相等。這樣使用Date就不能實現(xiàn)正確的再驗證，因為Date的時間總不會和服務(wù)器資源文件修改時間相等。
盡管使用Date可能出現(xiàn)的不正確情況，歸結(jié)于服務(wù)端沒有正確的實現(xiàn) Http 語義。
但我還是希望 Volley 也能完全正確的實現(xiàn) Http 語義，至少同時處理Last-Modified和Date,并且優(yōu)先使用Last-Modified。
7.2 Bug
(1). BasicNetwork.performRequest(…)
如下代碼：
@Override
public NetworkResponse performRequest(Request<?> request) throws VolleyError {
……
while (true) {
……
try {
……
} catch (IOException e) {
int statusCode = 0;
NetworkResponse networkResponse = null;
……
if (responseContents != null) {
……
} else {
throw new NetworkError(networkResponse);
}
}
}
}
BasicNetwork.performRequest(…) 最后的
throw new NetworkError(networkResponse);
應(yīng)該是
throw new NetworkError(e);
更合理。
