volley介绍03
Posted 力能扛鼎
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了volley介绍03相关的知识，希望对你有一定的参考价值。
------------------------------------------------------------------------------
转载：http://blog.csdn.net/crazy__chen/article/details/46486123
------------------------------------------------------------------------------
在上一篇文章中，我们已经提到volley的使用方式和设计的整体思路，从这篇文章开始，我就要结合具体的源码来给大家说明volley功能的具体实现。
我们第一个要介绍的类是Request<T>这个一个抽象类，我将Request称为一个请求，通过继承Request<T>来自定义request，为volley提供了更加灵活的接口。
Request<T>中的泛型T，是指解析response以后的结果。在上一篇文章中我们知道，ResponseDelivery会把response分派给对应的request(中文翻译就是，把响应分派给对应的请求)。在我们定义的请求中，需要重写parseNetworkResponse(NetworkResponse response)这个方法，解析请求，解析出来的结果，就是T类型的。
OK，我们现在来直接看源码。
首先是一些属性
/**
* Base class for all network requests.
* 请求基类
* @param <T> The type of parsed response this request expects.
* T为响应类型
*/
public abstract class Request<T> implements Comparable<Request<T>> {
/**
* Default encoding for POST or PUT parameters. See {@link #getParamsEncoding()}.
* 默认编码
*/
private static final String DEFAULT_PARAMS_ENCODING = "UTF-8";
/**
* Supported request methods.
* 支持的请求方式
*/
public interface Method {
int DEPRECATED_GET_OR_POST = -1;
int GET = 0;
int POST = 1;
int PUT = 2;
int DELETE = 3;
int HEAD = 4;
int OPTIONS = 5;
int TRACE = 6;
int PATCH = 7;
}
/**
* An event log tracing the lifetime of this request; for debugging.
* 用于跟踪请求的生存时间，用于调试
* */
private final MarkerLog mEventLog = MarkerLog.ENABLED ? new MarkerLog() : null;
/**
* Request method of this request. Currently supports GET, POST, PUT, DELETE, HEAD, OPTIONS,
* TRACE, and PATCH.
* 当前请求方式
*/
private final int mMethod;
/**
* URL of this request.
* 请求地址
*/
private final String mUrl;
/**
* The redirect url to use for 3xx http responses
* 重定向地址
*/
private String mRedirectUrl;
/**
* The unique identifier of the request
* 该请求的唯一凭证
*/
private String mIdentifier;
/**
* Default tag for {@link TrafficStats}.
* 流量统计标签
*/
private final int mDefaultTrafficStatsTag;
/**
* Listener interface for errors.
* 错误监听器
*/
private final Response.ErrorListener mErrorListener;
/**
* Sequence number of this request, used to enforce FIFO ordering.
* 请求序号，用于fifo算法
*/
private Integer mSequence;
/**
* The request queue this request is associated with.
* 请求所在的请求队列
*/
private RequestQueue mRequestQueue;
/**
* Whether or not responses to this request should be cached.
* 是否使用缓存响应请求
*/
private boolean mShouldCache = true;
/**
* Whether or not this request has been canceled.
* 该请求是否被取消
*/
private boolean mCanceled = false;
/**
* Whether or not a response has been delivered for this request yet.
* 该请求是否已经被响应
*/
private boolean mResponseDelivered = false;
/**
* A cheap variant of request tracing used to dump slow requests.
* 一个简单的变量，跟踪请求，用来抛弃过慢的请求
* 请求产生时间
*/
private long mRequestBirthTime = 0;
/** Threshold at which we should log the request (even when debug logging is not enabled). */
private static final long SLOW_REQUEST_THRESHOLD_MS = 3000;
/**
* The retry policy for this request.
* 请求重试策略
*/
private RetryPolicy mRetryPolicy;
/**
* When a request can be retrieved from cache but must be refreshed from
* the network, the cache entry will be stored here so that in the event of
* a "Not Modified" response, we can be sure it hasn‘t been evicted from cache.
* 缓存记录。当请求可以从缓存中获得响应，但必须从网络上更新时。我们保留这个缓存记录，所以一旦从网络上获得的响应带有Not Modified
* (没有更新)时，来保证这个缓存没有被回收.
*/
private Cache.Entry mCacheEntry = null;
/**
* An opaque token tagging this request; used for bulk cancellation.
* 用于自定义标记，可以理解为用于请求的分类
*/
private Object mTag;
不得不说，上面的属性非常之多(我都有写注释)，但是每个属性都有其相应的用处，而且有些属性的设置，是我们不大能考虑到的。我要来介绍一下。
1，DEFAULT_PARAMS_ENCODING = "UTF-8"默认编码
2，mMethod请求方式
3，mUrl请求地址
4，mRedirectUrl重定向地址，这个地址在网络响应状态码是403时，会被使用
5，mSequence序列号，就是这个request在队列中的序号(不是顺序)
6，mRequestQueue请求所在的请求队列
7，mErrorListener错误监听器
9，mShouldCache是否缓存，如果这个属性为真，就会先视图从缓存中查询请求结果
10，mCacheEntry缓存记录,这个记录用于缓存响应头等
11，mTag自定义标记，用户可以给一些请求自定义标记，使用这些标记，我们可以统一管理用于这些标记的请求，例如统一取消它们
接下来看构造方法
/**
* Creates a new request with the given method (one of the values from {@link Method}),
* URL, and error listener. Note that the normal response listener is not provided here as
* delivery of responses is provided by subclasses, who have a better idea of how to deliver
* an already-parsed response.
* 根据请求方式，创建新的请求(需要地址，错误监听器等参数)
*/
public Request(int method, String url, Response.ErrorListener listener) {
mMethod = method;
mUrl = url;
mIdentifier = createIdentifier(method, url);//为请求创建唯一凭证
mErrorListener = listener;//设定监听器
setRetryPolicy(new DefaultRetryPolicy());//设置默认重试策略
mDefaultTrafficStatsTag = findDefaultTrafficStatsTag(url);//设置流量标志
}
首先是请求方式，请求地址的设定，这是作为一个请求必须有的。然后是监听器的设定，注意这里只是这是了ErrorListner，说明errorListener是必须的，但是正确响应，我们有可能不处理。这样设定是合理的，因为出错了，我们必须处理，至于请求成功，我们可以不处理。那么我们想处理成功的请求怎么办呢，这需要在子类中重写构造方法(例如StringRequest)。
然后是创建了一个唯一凭证
/**
* sha1(Request:method:url:timestamp:counter)
* @param method http method
* @param url http request url
* @return sha1 hash string
* 利用请求方式和地址，进行sha1加密，创建该请求的唯一凭证
*/
private static String createIdentifier(final int method, final String url) {
return InternalUtils.sha1Hash("Request:" + method + ":" + url +
":" + System.currentTimeMillis() + ":" + (sCounter++));
}
由上面的方法可以看出，这个凭证和当前时间有关，因此是独一无二的
接着是设置重试策略，这个类等下再介绍，接下来是流量标志的设置，所谓流量标志，是用于调试日志记录的，不是重点
/**
* @return The hashcode of the URL‘s host component, or 0 if there is none.
* 返回url的host(主机地址)部分的hashcode，如果host不存在，返回0
*/
private static int findDefaultTrafficStatsTag(String url) {
if (!TextUtils.isEmpty(url)) {
Uri uri = Uri.parse(url);
if (uri != null) {
String host = uri.getHost();
if (host != null) {
return host.hashCode();
}
}
}
return 0;
}
我们再回过头来看这个重试策略。
volley为重试策略专门定义了一个类，这样我们就可以根据需要实现自己的重试策略了，至于源码内部，为我们提供了一个默认的重试策略DefaultRetryPolicy()
要介绍重试策略，我们先看重试策略的基类RetryPolicy
/**
* Retry policy for a request.
* 请求重试策略类
*/
public interface RetryPolicy {
/**
* Returns the current timeout (used for logging).
* 获得当前时间，用于日志
*/
public int getCurrentTimeout();
/**
* Returns the current retry count (used for logging).
* 返回当前重试次数，用于日志
*/
public int getCurrentRetryCount();
/**
* Prepares for the next retry by applying a backoff to the timeout.
* @param error The error code of the last attempt.
* @throws VolleyError In the event that the retry could not be performed (for example if we
* ran out of attempts), the passed in error is thrown.
* 重试实现
*/
public void retry(VolleyError error) throws VolleyError;
}
重要的是retry()这个方法，我们来看DefaultRetryPolicy里面这个方法的具体实现
/**
* Prepares for the next retry by applying a backoff to the timeout.
* @param error The error code of the last attempt.
*/
@Override
public void retry(VolleyError error) throws VolleyError {
mCurrentRetryCount++;//当前重试次数
mCurrentTimeoutMs += (mCurrentTimeoutMs * mBackoffMultiplier);//当前超出时间
if (!hasAttemptRemaining()) {//是否已经到达最大重试次数
throw error;
}
}
/**
* Returns true if this policy has attempts remaining, false otherwise.
* 是否还重试
*/
protected boolean hasAttemptRemaining() {
return mCurrentRetryCount <= mMaxNumRetries;//最大重试次数
}
可以看到，在默认的重试策略中，只是简单地统计了重试的次数，然后，在超出最大次数以后，抛出异常。
就这么简单，那么究竟volley是怎么实现重试的呢？
实际上，当从队列中取出一个request去进行网络请求的时候，我们是写在一个死循环里面的(在以后的代码可以看到，这样不贴出来以免类过多造成困扰)。
一旦请求失败，就会调用上面的retry()方法，但是没有跳出循环。直到请求成功获得response，才return。如果一直请求失败，根据上面的重试策略，最后会抛出VolleyError异常,这个异常不处理，而是通过throws向外抛，从而结束死循环。
从程序设计的角度来说，通过抛出异常结束死循环，显得不是那么的优雅(通常我们用设置标记的方法结束循环)，但是在volley中使用了这个方式，原因是对于这个异常，要交给程序员自己处理，虽然这样使异常传递的过程变得复杂，但是增加了程序的灵活性。
最终的异常，我们会在Request<T>的parseNetworkError()和deliverError()方法里面处理，parseNetworkError()用于解析Volleyerror，deliverError()方法回调了上面一开始就提到的ErrorListener
其实除了上面两个处理错误的方法，还有两个方法用于处理成功响应,是必须要继承的
/**
* Subclasses must implement this to parse the raw network response
* and return an appropriate response type. This method will be
* called from a worker thread. The response will not be delivered
* if you return null.
* @param response Response from the network
* @return The parsed response, or null in the case of an error
* 解析响应
*/
public abstract Response<T> parseNetworkResponse(NetworkResponse response);
<pre name="code" class="java">/**
* Subclasses must implement this to perform delivery of the parsed
* response to their listeners. The given response is guaranteed to
* be non-null; responses that fail to parse are not delivered.
* @param response The parsed response returned by
* {@link #parseNetworkResponse(NetworkResponse)}
* 分发响应
*/
public abstract void deliverResponse(T response);
parseNetworkResponse(NetworkResponse response)用于将网络response解析为本地response，解析出来的response,会交给deliverResponse(T response)方法。
为什么要解析，其实上面已经说过，要将结果解析为T类型。至于这两个方法，其实是在ResponseDelivery响应分发器里面调用的。
看完初始化方法，我们来看结束请求的方法finish()，有时候我们想要主动终止请求，例如停止下载文件，又或者请求已经成功了，我们从队列中去除这个请求
/**
* Notifies the request queue that this request has finished (successfully or with error).
* 提醒请求队列，当前请求已经完成(失败或成功)
* <p>Also dumps all events from this request‘s event log; for debugging.</p>
*
*/
public void finish(final String tag) {
if (mRequestQueue != null) {
mRequestQueue.finish(this);//该请求完成
}
if (MarkerLog.ENABLED) {//如果开启调试
final long threadId = Thread.currentThread().getId();//线程id
if (Looper.myLooper() != Looper.getMainLooper()) {//请求不是在主线程
// If we finish marking off of the main thread, we need to
// actually do it on the main thread to ensure correct ordering.
//如果我们不是在主线程记录log，我们需要在主线程做这项工作来保证正确的顺序
Handler mainThread = new Handler(Looper.getMainLooper());
mainThread.post(new Runnable() {
@Override
public void run() {
mEventLog.add(tag, threadId);
mEventLog.finish(this.toString());
}
});
return;
}
//如果在主线程，直接记录
mEventLog.add(tag, threadId);
mEventLog.finish(this.toString());
} else {//不开启调试
long requestTime = SystemClock.elapsedRealtime() - mRequestBirthTime;
if (requestTime >= SLOW_REQUEST_THRESHOLD_MS) {
VolleyLog.d("%d ms: %s", requestTime, this.toString());
}
}
}
上面主要是做了一些日志记录的工作，最重要的是调用了mRequestQueue的finish()方法，来从队列中去除这个请求。
看完上面的介绍以后，大家是否注意到，Request<T>继承了Comparable<Request<T>>接口，为什么要继承这个接口了，我们当然要来看compareTo()方法了
这个方法比较了两个请求的优先级，如果优先级相等，就按照顺序。
实现这个接口的目的，正如上一篇文章提到的，有的请求比较重要，希望早点执行，也就是说让它排在请求队列的前头
通过比较方法，我们就可以设定请求在请求队列中排队顺序的根据，从而让优先级高的排在前面。
OK，Request<T>就基本介绍完了，当然有些属性，例如缓存mCacheEntry，mRedirectUrl重定向地址等我们还没有用到，我们先记住它们，在以后会使用到的。
其实Request<T>类并不复杂，主要就是一些属性的设置，这些属性有的比较难考虑到，例如优先级，重定向地址，自定义标记，重试策略等。
最后，我们通过StringRequest来看一下Request<T>类的具体实现
/**
* 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;
}
上面的构造方法中，添加了一个新的接口Listener<String> listener,用于监听成功的response
然后是parseNetworkResponse(NetworkResponse response)，这个方法
可以看到，将NetworkResponse解析为String类型的了，然后再构造成对应的本地response
@Override
public void deliverResponse(String response) {
mListener.onResponse(response);
}
至于deliverResponse(String response)，则调用了构造方法里面要求的，新的监听器。
到此为止，对于Request<T>的介绍就结束了，由于Request<T>和其他类的耦合并不是特别重，相信是比较容易理解。
在下一篇文章中，我们会来看RequestQueue队列，看看这个队列的作用到底是什么，我们为什么要创建一个队列来保存request而不是直接每个request开启一个线程去加载网络数据。
以上是关于volley介绍03的主要内容，如果未能解决你的问题，请参考以下文章
无法通过使用 Volley 库中的 Intent 从片段中移动下一个 Activity