簡介
本篇文章分析Volley的網絡請求的過程，以及獲取緩存數據時是如何判斷緩存是否過期，是否需要刷新。
RequestQueue再分析
從之前的文章Volley – 基本用法 中知道，每一個請求都添加到RequestQueue中，有其分配管理，那麼它是怎麼管理的呢？？
查看其成員變量可以發現其有4個集合對象，現在先來看看分別是什麼
/**
* Staging area for requests that already have a duplicate request in flight.
*
* <ul>
* <li>containsKey(cacheKey) indicates that there is a request in flight for the given cache
* key.</li>
* <li>get(cacheKey) returns waiting requests for the given cache key. The in flight request
* is <em>not</em> contained in that list. Is null if no requests are staged.</li>
* </ul>
*/
// #由註釋可知，該集合用於保存正在執行中的請求，並且處理重複添加的請求，等到第一個請求執行完畢，在ExecutorDelivery中傳遞到主線程接口並調用mRequest.finish("done");釋放對象。
private final Map<String, Queue<Request<?>>> mWaitingRequests =
new HashMap<String, Queue<Request<?>>>();
/**
* The set of all requests currently being processed by this RequestQueue. A Request
* will be in this set if it is waiting in any queue or currently being processed by
* any dispatcher.
*/
// #該集合用於保存最近添加的請求，在cancelAll()方法中釋放對象，因此應該在Activity的onDestroy()方法中調用釋放對象。
private final Set<Request<?>> mCurrentRequests = new HashSet<Request<?>>();
/** The cache triage queue. */
// #該集合存儲等待從緩存中獲取數據的請求
private final PriorityBlockingQueue<Request<?>> mCacheQueue =
new PriorityBlockingQueue<Request<?>>();
/** The queue of requests that are actually going out to the network. */
// #該集合存儲等待從服務器獲取數據的請求
private final PriorityBlockingQueue<Request<?>> mNetworkQueue =
new PriorityBlockingQueue<Request<?>>();回到原來問題，RequestQueue是如何管理Request對象，查看add(Request request)代碼：
/**
* Adds a Request to the dispatch queue.
* @param request The request to service
* @return The passed-in request
*/
public <T> Request<T> add(Request<T> request) {
// Tag the request as belonging to this queue and add it to the set of current requests.
request.setRequestQueue(this);
// #先添加到最近請求的集合中
synchronized (mCurrentRequests) {
mCurrentRequests.add(request);
}
// Process requests in the order they are added.
request.setSequence(getSequenceNumber());
request.addMarker("add-to-queue");
// If the request is uncacheable, skip the cache queue and go straight to the network.
// #判斷該請求是否需要緩存，默認爲true，如果不需要則添加到等待從服務器獲取數據的請求的集合中
if (!request.shouldCache()) {
mNetworkQueue.add(request);
return request;
}
// Insert request into stage if there's already a request with the same cache key in flight.
synchronized (mWaitingRequests) {
String cacheKey = request.getCacheKey();
// #如果mWaitingRequests包含該請求的cacheKey，則說明，該請求正在加載中，並且將該請求保存起來
if (mWaitingRequests.containsKey(cacheKey)) {
// There is already a request in flight. Queue up.
Queue<Request<?>> stagedRequests = mWaitingRequests.get(cacheKey);
if (stagedRequests == null) {
stagedRequests = new LinkedList<Request<?>>();
}
// #保存該請求
stagedRequests.add(request);
mWaitingRequests.put(cacheKey, stagedRequests);
if (VolleyLog.DEBUG) {
VolleyLog.v("Request for cacheKey=%s is in flight, putting on hold.", cacheKey);
}
} else {
// Insert 'null' queue for this cacheKey, indicating there is now a request in
// flight.
//# 該請求沒有正在加載中，則添加null標記爲正在加載中
mWaitingRequests.put(cacheKey, null);
// #添加到mCacheQueue集合中，由CacheDispatecher處理，如果沒有緩存再添加到mNetworkQueue中等待NetworkDispatecher處理。
mCacheQueue.add(request);
}
return request;
}
}從上面可以看出：
- mWaitingRequests：用於處理重複請求，並且將重複請求保存起來，等到第一個請求執行完畢後，在後調到結果接口時通過。Request..finish(“done”)方法調用所在RequestQueue的finish方法釋放請求對象。
- mCurrentRequests：用於保存最近添加的請求，在Acitivty的onStop()和onDestroy()方法中可通過調用RequestQueue的cancelAll()方法釋放請求對象。
- mCacheQueue：用於保存待處理請求，等待從緩存中獲取緩存，如果沒有緩存或者緩存過期，則添加到mNetworkQueue中。
- mNetworkQueue：用於存儲等待從服務器獲取數據的請求。
CacheDispatcher再討論
從 Volley – 源碼分析 這篇文章的問題三中可以知道，CacheDispatcher在處理請求時會發生不存在緩存文件和緩存文件過期以及緩存文件是否需要刷新的情況，那麼緩存文件是根據什麼來判斷以上這些請求的發生呢？
通過Cache接口的內部類Entry的isExpired()方法判斷緩存是否過期，refreshNeeded()方法判斷緩存是否需要刷新
追溯到Entry類
/**
* Data and metadata for an entry returned by the cache.
*/
public static class Entry {
/** The data returned from cache. */
// #所請求的數據
public byte[] data;
/** ETag for cache coherency. */
// # Http 響應字段：用於判斷所請求數據的一致性
public String etag;
/** Date of this response as reported by the server. */
// #向服務器發送請求的時間
public long serverDate;
/** The last modified date for the requested object. */
// #請求對象上一次修改的時間
public long lastModified;
/** TTL for this record. */
// #該緩存存活的時間
public long ttl;
/** Soft TTL for this record. */
public long softTtl;
/** Immutable response headers as received from server; must be non-null. */
public Map<String, String> responseHeaders = Collections.emptyMap();
/** True if the entry is expired. */
// # 判斷改緩存是否過期
public boolean isExpired() {
return this.ttl < System.currentTimeMillis();
}
/** True if a refresh is needed from the original data source. */
// # 判斷該緩存是否需要刷新
public boolean refreshNeeded() {
return this.softTtl < System.currentTimeMillis();
}
}
那麼Entry類的這些成員變量從何而來？？讓我們看一下NetworkDispatcher先
NetworkDispatcher再討論
從 Volley – 源碼分析 這篇文章的問題二中可以知道，從Request到Response的大致過程，接下來就詳細的分析一下。先看一下Network的類圖
這裏分析一下BasicNetwork是怎麼得到NetworkResponse的。代碼比較多，只截取performRequest(Request
@Override
public NetworkResponse performRequest(Request<?> request) throws VolleyError {
long requestStart = SystemClock.elapsedRealtime();
while (true) {
HttpResponse httpResponse = null;
byte[] responseContents = null;
Map<String, String> responseHeaders = Collections.emptyMap();
try {
// Gather headers.
Map<String, String> headers = new HashMap<String, String>();
// #添加緩存信息到請求頭 -- HTTP報頭 ，後面再講解
addCacheHeaders(headers, request.getCacheEntry());
httpResponse = mHttpStack.performRequest(request, headers);
StatusLine statusLine = httpResponse.getStatusLine();
int statusCode = statusLine.getStatusCode();
// # 獲取響應頭信息
responseHeaders = convertHeaders(httpResponse.getAllHeaders());
// Handle cache validation.
// # 結果碼爲304 -- 表示資源已經找到，但是未滿足條件請求
if (statusCode == HttpStatus.SC_NOT_MODIFIED) {
Entry entry = request.getCacheEntry();
if (entry == null) {
return new NetworkResponse(HttpStatus.SC_NOT_MODIFIED, null,
responseHeaders, true,
SystemClock.elapsedRealtime() - requestStart);
}
// A HTTP 304 response does not have all header fields. We
// have to use the header fields from the cache entry plus
// the new ones from the response.
// http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5
entry.responseHeaders.putAll(responseHeaders);
return new NetworkResponse(HttpStatus.SC_NOT_MODIFIED, entry.data,
entry.responseHeaders, true,
SystemClock.elapsedRealtime() - requestStart);
}
// Handle moved resources
// #結果碼爲301 -- 永久性重定向，表示資源的URL已經更新，這時根據Location首部字段獲取新的URL
if (statusCode == HttpStatus.SC_MOVED_PERMANENTLY || statusCode == HttpStatus.SC_MOVED_TEMPORARILY) {
String newUrl = responseHeaders.get("Location");
request.setRedirectUrl(newUrl);
}
// Some responses such as 204s do not have content. We must check.
if (httpResponse.getEntity() != null) {
responseContents = entityToBytes(httpResponse.getEntity());
} else {
// Add 0 byte response as a way of honestly representing a
// no-content request.
responseContents = new byte[0];
}
// if the request is slow, log it.
long requestLifetime = SystemClock.elapsedRealtime() - requestStar
if (statusCode < 200 || statusCode > 299) {
throw new IOException();
}
return new NetworkResponse(statusCode, responseContents, responseHeaders, false,
SystemClock.elapsedRealtime() - requestStart);
}
// # catch部分
....
}private void addCacheHeaders(Map<String, String> headers, Cache.Entry entry) {
// If there's no cache entry, we're done.
if (entry == null) {
return;
}
// # 這裏涉及到請求首部字段"If-None-Match"，
// # 在解析之前，要知道響應首部字段"ETag"的作用：用於告知客戶端實體標識，服務器會爲每份資源分配對應的ETag值，另外，當資源更新時，ETag也需要更新.
// # 而請求首部字段"If-None-Match"的作用是：用於指定If-None-Match字段值的實體標記(ETag)不一致時，就告知服務器處理該請求。在GET和HEAD方法中使用首部字段If-None-Match可獲取最新資源
if (entry.etag != null) {
headers.put("If-None-Match", entry.etag);
}
// # 如果在If-Modified-Since字段指定的時間之後，資源發生了更新，服務器會接受請求。
// # 如果在If-Modified-Since字段指定的時間之後，如果請求的資源都沒有更新過，則返回狀態碼304 Not Modified的響應
if (entry.lastModified > 0) {
// # 獲取entry上一次修改的時間
Date refTime = new Date(entry.lastModified);
headers.put("If-Modified-Since", DateUtils.formatDate(refTime));
}
}通過上面代碼可以知道，通過設置添加If-Modified-Since和If-None-Match的請求頭字段來獲取NetworkResponse，現在來分析一下NetworkResponse的成員變量：
/**
* Data and headers returned from {@link Network#performRequest(Request)}.
*/
public class NetworkResponse implements Serializable{
// # 構造方法...
/** The HTTP status code. */
// # Http結果碼
public final int statusCode;
/** Raw data from this response. */
// # 結果數據
public final byte[] data;
/** Response headers. */
// # 響應頭
public final Map<String, String> headers;
/** True if the server returned a 304 (Not Modified). */
// # 是否返回304的結果碼
public final boolean notModified;
/** Network roundtrip time in milliseconds. */
// # 從服務器獲取數據花費的時間
public final long networkTimeMs;
}
接下來分析NetworkDispatcher處理Request的主要流程：
@Override
public void run() {
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
Request<?> request;
while (true) {
long startTimeMs = SystemClock.elapsedRealtime();
// # 先獲取request對象
try {
request.addMarker("network-queue-take");
// If the request was cancelled already, do not perform the
// network request.
// # 判斷請求是否取消
if (request.isCanceled()) {
request.finish("network-discard-cancelled");
continue;
}
addTrafficStatsTag(request);
// Perform the network request.
// # 執行獲取NetworkResponse結果
NetworkResponse networkResponse = mNetwork.performRequest(request);
request.addMarker("network-http-complete");
// If the server returned 304 AND we delivered a response already,
// we're done -- don't deliver a second identical response.
// # 判斷是否爲304結果並且結果已經傳送完成
if (networkResponse.notModified && request.hasHadResponseDelivered()) {
request.finish("not-modified");
continue;
}
// Parse the response here on the worker thread.
// # 獲取Response對象
Response<?> response = request.parseNetworkResponse(networkResponse);
request.addMarker("network-parse-complete");
// Write to cache if applicable.
// TODO: Only update cache metadata instead of entire record for 304s.
// # 判斷是否需要緩存
if (request.shouldCache() && response.cacheEntry != null) {
mCache.put(request.getCacheKey(), response.cacheEntry);
request.addMarker("network-cache-written");
}
// Post the response back.
// # 傳遞結果
request.markDelivered();
mDelivery.postResponse(request, response);
} catch (VolleyError volleyError) {
volleyError.setNetworkTimeMs(SystemClock.elapsedRealtime() - startTimeMs);
parseAndDeliverNetworkError(request, volleyError);
} catch (Exception e) {
// ...
}
}
}看到這裏你會發現，結果都已經被傳送了，卻沒有發現關於Entry類中的存活時間等數據。其實不然，看一下StringRequest的parseNetworkResponse(NetworkResponse 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);
}
// # 通過HttpHeaderParser將NetworkResponse 結果解析成Entry對象
return Response.success(parsed, HttpHeaderParser.parseCacheHeaders(response));
}看一下parseCacheHeaders(NetworkResponse response) 方法：
/**
* Extracts a {@link Cache.Entry} from a {@link NetworkResponse}.
*
* @param response The network response to parse headers from
* @return a cache entry for the given response, or null if the response is not cacheable.
*/
public static Cache.Entry parseCacheHeaders(NetworkResponse response) {
long now = System.currentTimeMillis();
Map<String, String> headers = response.headers;
// ...
// # 首部字段Date -- 表明創建HTTP報文日期和時間
// # HTTP/1.1協議使用RFC1123中規定的時間格式，具體解析看parseDateAsEpoch()方法
headerValue = headers.get("Date");
if (headerValue != null) {
serverDate = parseDateAsEpoch(headerValue);
}
// # 首部字段Cache-Control
headerValue = headers.get("Cache-Control");
if (headerValue != null) {
hasCacheControl = true;
String[] tokens = headerValue.split(",");
for (int i = 0; i < tokens.length; i++) {
String token = tokens[i].trim();
// # no-cache -- 緩存前必須先確定其有效性
// # no-store -- 不緩存請求或響應的任何內容
// # 在這裏表示無緩存
if (token.equals("no-cache") || token.equals("no-store")) {
return null;
} else if (token.startsWith("max-age=")) {
// # max-age -- 資源文件的存活時間
try {
maxAge = Long.parseLong(token.substring(8));
} catch (Exception e) {
}
} else if (token.startsWith("stale-while-revalidate=")) {
// # stale-while-revalidate : 這個指令的解釋相對比較少，根據一篇論文的介紹，大概可能解釋爲緩存超過存活時間，重新請求或者資源更新過程的延遲時間（論文地址：http://tools.ietf.org/html/draft-nottingham-http-stale-while-revalidate-01#section-1）
try {
staleWhileRevalidate = Long.parseLong(token.substring(23));
} catch (Exception e) {
}
} else if (token.equals("must-revalidate") || token.equals("proxy-revalidate")) {
// # must-revalidate -- 表示可緩存但必須再向源服務器進行確認
// # proxy-revalidate -- 表示中間緩存服務器對緩存響應的有效性再進行確認
mustRevalidate = true;
}
}
}
// # Expires -- 資源失效日期
// # 當Cache-Control有指令max-age時，優先處理max-age指令
headerValue = headers.get("Expires");
if (headerValue != null) {
serverExpires = parseDateAsEpoch(headerValue);
}
// # Last-Modified -- 資源最終修改的時間
headerValue = headers.get("Last-Modified");
if (headerValue != null) {
lastModified = parseDateAsEpoch(headerValue);
}
// # ETag -- 資源標識
serverEtag = headers.get("ETag");
// Cache-Control takes precedence over an Expires header, even if both exist and Expires
// is more restrictive.
if (hasCacheControl) {
softExpire = now + maxAge * 1000;
finalExpire = mustRevalidate
? softExpire
: softExpire + staleWhileRevalidate * 1000;
} else if (serverDate > 0 && serverExpires >= serverDate) {
// Default semantic for Expire header in HTTP specification is softExpire.
softExpire = now + (serverExpires - serverDate);
finalExpire = softExpire;
}
Cache.Entry entry = new Cache.Entry();
// ...
return entry;
}到了這裏，才發現Entry的相關信息是在這裏被賦值初始化。
總結
- 知道RequestQueue是如何管理Request
- 知道緩存數據Entry是如何判斷是否過期是否需要更新
- 知道HTTP的部分首部字段的使用，有
- ETag
- If-None-Match
- If-Modified-Since
- Cache-control
- Data
- Expires
- Location
最後，如果有哪個地方不足或者錯誤，希望能夠指出