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才算开始

（后续）