面相接口的编程思想已经深入到volley的骨髓中了,当学习完volley,就算没有别的收货,但面相接口的编程思想必定深深印在脑海中,从HttpStack、到Network、再到Request等都是利用的接口思想。今天所说的请求重试策略RetryPolicy依然遵循了此思想,不得不令人感叹!!!
其实,直到现在这一刻,才忽然意识到,似乎volley就是利用接口来搭建其骨架的,之前的时候知道volley内利用了大量的接口,但是自己也只是明白,但是没有什么直观的概念,对于volley源码的学习和研究已经有段时间了,对其各个部分,也有了直观的了解,现在想想在各个关键点用的都是接口,骨架使用接口搭建的,而volley也有一套默认的对这些接口的实现类,形成了骨架间的血肉。嘿嘿,跑远了。
请求重试策略,很高大上的样子,但其内部结构真的很简单,先看看最直观的源码:
/**
* Retry policy for a request.
* 请求的重新请求策略
*/
public interface RetryPolicy {
/**
* Returns the current timeout (used for logging).
* 获取当前请求用时(用于Log)
*/
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;
}
接口就定义了三个方法:获取当前超时时间、获取重试次数和重试。前两个方法很直观,重要的是第三个方法public void retry(VolleyError error) throws VolleyError ,而对于第三个方法想要强调的是throws VolleyError 抛出异常,也就是说在retry内部会抛出异常,之前一个字面retry就认为是在该方法内部重新发出网络请求,其实不是这样的,在内部的真正操作是变更重试策略的属性,如超时时间和重试次数,当超过了重试策略设定的限定就会抛出异常。注意注意注意:retry并不是真正的去重新发出网络请求。请求的重试是在BasicNetwork内实现的。稍后会涉及到。
DefaultRetryPolicy,RetryPolicy的默认实现类,也是volley的默认的请求重试策略。
该类内部定义了重试策略的必备属性:
/** The