Dart Dio网络请求源码学习
最近在写Flutter的时候用到了Dio，但是由于没有仔细的看Readme，导致一段时间不知道该如何处理Http错误(给我们教训要好好看Readme啊)，于是感觉有必要来看看其请求的实现。
一、发起请求
在Dio中无论发起的是何种请求，最终一定是调用的request方法
Future<Response<T>> request<T>(
String path, {
data,
Map<String, dynamic> queryParameters,
CancelToken cancelToken,
Options options,
ProgressCallback onSendProgress,
ProgressCallback onReceiveProgress,
}) async {
return _request<T>(
path,
data: data,
queryParameters: queryParameters,
cancelToken: cancelToken,
options: options,
onSendProgress: onSendProgress ?? onSendProgress,
onReceiveProgress: onReceiveProgress,
);
}
注意：如果是普通的只传递path和queryParameters这两个参数的话，那么到这里的话其他的所有参数都是null。
可以发现，request方法调用的是_request方法
1. _request--一切的开始
_request方法比较长，这里分段展示
Future<Response<T>> _request<T> {
....
if (options == null) options = Options();
******** 1 *********
if (options is RequestOptions) {
data = data ?? options.data;
queryParameters = queryParameters ?? options.queryParameters;
cancelToken = cancelToken ?? options.cancelToken;
onSendProgress = onSendProgress ?? options.onSendProgress;
onReceiveProgress = onReceiveProgress ?? options.onReceiveProgress;
}
RequestOptions requestOptions =
_mergeOptions(options, path, data, queryParameters);
requestOptions.onReceiveProgress = onReceiveProgress;
requestOptions.onSendProgress = onSendProgress;
requestOptions.cancelToken = cancelToken;
if (T != dynamic &&
!(requestOptions.responseType == ResponseType.bytes ||
requestOptions.responseType == ResponseType.stream)) {
if (T == String) {
requestOptions.responseType = ResponseType.plain;
} else {
requestOptions.responseType = ResponseType.json;
}
}
if (data is FormData) {
requestOptions.headers[HttpHeaders.contentTypeHeader] =
'multipart/form-data; boundary=${data.boundary.substring(2)}';
}
....
}
该段代码实际上就是配置Options罢了，值得注意的是Dio对象在初始化的时候创建了一个BaseOptions options对象，而发起请求的时候也可以传递一个Options对象(RequestOptions继承自Options对象，但是BaseOptions对象和Options对象没有继承关系)，不要把请求参数中的Options和Dio的属性options搞混了。
_mergeOptions方法的作用就是将Dio的BaseOptions属性结合请求参数Options来生成一个RequestOptions对象，RequestOptions对象才是发起网络请求的真正Options
ResponseType
看了源码才知道，原来真正有用的ResponseType只有ResponseType.json和ResponseType.plain(仅当Response的泛型类为String且声明的ResponseType不为bytes和stream时)，不碍事，反正本人日常使用的话都是使用json
Future<Response<T>> _request<T> {
....
Future<Response<T>> future =
_checkIfNeedEnqueue<T>(interceptors.requestLock, () {
Future ret = _executeInterceptors<RequestOptions>(
requestOptions, (Interceptor inter, ob) => inter.onRequest(ob));
return ret.then<Response<T>>((data) {
FutureOr<Response<T>> response;
// If the Future value type is Options, continue the network request.
if (data is RequestOptions) {
requestOptions.method = data.method.toUpperCase();
response = _makeRequest<T>(data, cancelToken);
} else {
// Otherwise, use the Future value as the request result.
// If the return type is Error, we should throw it
if (data is Error) throw _assureDioError(data);
var r = _assureResponse<T>(data);
r.request = r.request ?? requestOptions;
response = r;
}
return response;
}).catchError((err) => throw _assureDioError(err));
});
....
}
这一段代码是最关键的,是否发起网络请求就是在这里进行决断的。
_checkIfNeedEnqueue方法的作用就是判断是否有未处理完(判断是否处理完从而加锁是通过Completer实现的)的请求，如果有的话，本次请求需要排队等待之前的请求的完成(值得学习的是由于一次请求返回的是Future，所以这里利用了future.then((Callback))返回的还是一个Future对象的特点，巧妙的实现了多次请求的顺序执行而相互之间不会干扰)，这里的then中的Callback回调就是_checkIfNeedEnqueue的第二个参数。
现在我们关注的重点就是在这个Callback回调之上了：
Future ret = _executeInterceptors<RequestOptions>(requestOptions, (Interceptor inter, ob) => inter.onRequest(ob));方法很简单，就是从Dio的属性interceptors(实际上就是保存了Dio对象添加过的所有拦截器Interceptor)中逐个的取拦截器inter，逐个的执行inter.onRequest(requestOptions),当其中有一个拦截器的onRequest返回的是Response(dio.resolve)或者DioError(或者dio.reject)的时候则返回该Response或者DioError，如果没有的话则返回requestOptions(注意，该RequestOptions对象是被所有拦截器处理了的)
而ret.then的处理也很值得注意，是否发起网络请求就看他了，可见，如果ret的类型是RequestOptions，那么就会执行_makeRequest(这才是真正的发起网络请求的方法，之前的都是对RequestOptions的处理)；如果ret的类型是Error或者Response的话，那么便不会发起请求。
Dio的Readme中有对拦截器的onRequest描述：如果你想完成请求并返回一些自定义数据，可以返回一个
Response对象或返回dio.resolve(data)。这样请求将会被终止，上层then会被调用，then中返回的数据将是你的自定义数据data.如果你想终止请求并触发一个错误,你可以返回一个DioError对象，或返回dio.reject(errMsg)，这样请求将被中止并触发异常，上层catchError会被调用。 到此，我们已经窥探到了拦截器的onRequest的意义了。
至此，拦截器的原理告一段落。
而真正的网络请求从_makeRequest才算开始
（后续）
