概述

OkHttp也火了好多年了，江湖上各种扩展，各种文章也一大堆。后面的Retrofit也是基于OkHttp。这个自不必多说，相信每个人看源码都能有自己的体会。这次也是基于使用和源码分析对这个网络加载框架的了解做一些总结。文章会基于框架的使用对框架进行两个方面的分析和总结，一个是任务调度分析，另一个是拦截器责任链分析。
OkHttp源码 ：OkHttp

一、任务调度

还是老规矩我们从最基本的使用方式作为切入点，去瞧一瞧：

 OkHttpClient.Builder builder = new OkHttpClient.Builder()
                .connectTimeout(15 , TimeUnit.SECONDS)
                .writeTimeout(20 , TimeUnit.SECONDS)
                .readTimeout(20 , TimeUnit.SECONDS)
                .cache(new Cache(cache.getAbsoluteFile() , cacheSize));
      OkHttpClient  mOkHttpClient = builder.build();
final Request request = new Request.Builder()
                .url(url)
                .get()
                .build();
   Call call = mOkHttpClient.newCall(request);
    // 注释 1 
   call.enqueue(new Callback() {
            @Override
            public void onFailure(Call call, IOException e) {
                sendFailGet(call , e , callback);
            }
            @Override
            public void onResponse(Call call, Response response) throws IOException {
                sendSuccessGet(response , callback);
            }
        });

这应该算是最简单的使用方式了吧。话不多说，使用方式不做解释。上面注释 1的 enqueue方法我们点进去看一下（找到 Call的实现类 RealCall）。

// RealCall,java
  @Override public Response execute() throws IOException {
    synchronized (this) {
     ......
    try {
      // 注释 2，  Dispatcher 同步任务
      client.dispatcher().executed(this);
      Response result = getResponseWithInterceptorChain();
      if (result == null) throw new IOException("Canceled");
      return result;
    } catch (IOException e) {
      eventListener.callFailed(this, e);
      throw e;
    } 
     .....
  }

@Override public void enqueue(Callback responseCallback) {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    captureCallStackTrace();
    eventListener.callStart(this);
    // 注释 3， Dispatcher 异步任务
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
  }

上面贴出了RealCall里面的 execute和 enqueue两个方法，一个是执行的同步、阻塞式的任务，另一个是执行的异步非阻塞式的任务。就是是否涉及到线程切换的问题，我们现在分析异步任务就好。看上面注释 3处，创建了一个 AsyncCall对象作为 Dispatcher 的 enqueue方法的对象，而 AsyncCall继承自 Runnable，这个待会再分析，现在我们点进上面注释 3处的 enqueue方法，看看这个 Runnable被传到了哪里：

public final class Dispatcher {
    //注释 4， 最大请求数
    private int maxRequests = 64;
    // 注释 5，每个Host最大请求数 
    private int maxRequestsPerHost = 5;
    // 注释 6，线程池
    private @Nullable
    ExecutorService executorService;
    /** 注释 7， 等待执行的异步任务 双端队列*/
    private final Deque<RealCall.AsyncCall> readyAsyncCalls = new ArrayDeque<>();
    /** 注释 8，正在执行的异步任务 双端队列*/
    private final Deque<RealCall.AsyncCall> runningAsyncCalls = new ArrayDeque<>();
    /** 注释 9，正在执行的同步任务，双端队列. */
    private final Deque<RealCall> runningSyncCalls = new ArrayDeque<>();
    ......
    // 注释 10 ，线程池
    public synchronized ExecutorService executorService() {
        if (executorService == null) {
            executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
                    new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
        }
        return executorService;
    }
.........
     // 注释 11， 异步任务入队
    synchronized void enqueue(RealCall.AsyncCall call) {
     // 注释 12，当前运行的任务数小于最大任务数，且当前请求的 Host的请求数小于每个 Host的最大请求数。
        if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
            runningAsyncCalls.add(call);
            executorService().execute(call);
        } else {
            readyAsyncCalls.add(call);
        }
    }
...........
    /** 注释 13， 同步任务入队 */
    synchronized void executed(RealCall call) {
        runningSyncCalls.add(call);
    }
}

这里一样也不拖泥带水了，上面贴出了任务调度器 Dispatcher 一些主要代码。刚才的 enqueue方法我们看到了，在上面注释 11处。异步任务会被放到一个队列里面，上面的条件判断的意思：当前运行的任务数小于最大任务数，且当前请求的 Host的请求数小于每个 Host的最大请求数。所以异步任务的的请求数量也会有限制，默认的请求任务数见上面注释 4、注释 5处。当然，像 maxRequests 、maxRequestsPerHost 这样的参数也是可以设置的，只不过上面粘贴的代码省掉了。
上面的注释 7，注释 8，注释 9共维护了任务调度器的三个双端队列，一个是同步任务的队列，另两个是维护异步任务的队列。在注释 12处，如果满足条件，异步任务将被放进当前正被执行的队列，并且丢进线程池执行。若不满足条件，将被放进等待执行的队列，等待执行。这个不用多说，其实 OkHttp源码最核心的部分还是拦截器链这一块。下面分析一下框架里的这个责任链设计模式。

二、拦截器链

我们还是回到刚才 RealCall将请求打包传入调度器 Dispatcher 的地方 ：

// RealCall,java
@Override public void enqueue(Callback responseCallback) {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    captureCallStackTrace();
    eventListener.callStart(this);
    // 注释 3， Dispatcher 异步任务
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
  }

上面注释 3处的 AsyncCall，我们点进去看一下这个 Runnable里面干了啥：

final class AsyncCall extends NamedRunnable {
    private final Callback responseCallback;
    AsyncCall(Callback responseCallback) {
        super("OkHttp %s", redactedUrl());
        this.responseCallback = responseCallback;
    }
    @Override protected void execute() {
        boolean signalledCallback = false;
        try {
            // 注释 14，获取请求响应
            Response response = getResponseWithInterceptorChain();
            if (retryAndFollowUpInterceptor.isCanceled()) {
                signalledCallback = true;
                responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
            } else {
                signalledCallback = true;
                responseCallback.onResponse(RealCall.this, response);
            }
        } catch (IOException e) {
            if (signalledCallback) {
                // Do not signal the callback twice!
                Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e);
            } else {
                eventListener.callFailed(RealCall.this, e);
                responseCallback.onFailure(RealCall.this, e);
            }
        }
    }
}

我们看到上面的 AsyncCall 会被丢进线程池，然后上面的 execute()方法会被执行。看上面注释 14处，请求的响应是从 getResponseWithInterceptorChain();这个方法获取的，我们点进去看一下这个方法干了啥：

// RealCall.java
Response getResponseWithInterceptorChain() throws IOException {
    // Build a full stack of interceptors.
    // 注释 15，收集所有拦截器对象 
    List<Interceptor> interceptors = new ArrayList<>();
    interceptors.addAll(client.interceptors());
    interceptors.add(retryAndFollowUpInterceptor);
    interceptors.add(new BridgeInterceptor(client.cookieJar()));
    interceptors.add(new CacheInterceptor(client.internalCache()));
    interceptors.add(new ConnectInterceptor(client));
    if (!forWebSocket) {
      interceptors.addAll(client.networkInterceptors());
    }
    interceptors.add(new CallServerInterceptor(forWebSocket));
    // 注释 16，创建 RealInterceptorChain对象，并将拦截器链丢进去
    Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0,
        originalRequest, this, eventListener, client.connectTimeoutMillis(),
        client.readTimeoutMillis(), client.writeTimeoutMillis());
    // 注释 17，执行 RealInterceptorChain的 proceed()方法
    return chain.proceed(originalRequest);
  }

看看上面的方法，拦截器链粉墨登场了。上面方法做了 3件事，注释 15、注释 16、注释 17，分别是创建拦截器并放到列表里、创建 RealInterceptorChain对象，并将拦截器链丢进去、执行 RealInterceptorChain的 proceed()方法并返回 Response 。现在我们看看 RealInterceptorChain的 proceed()方法干了啥：

   // RealInterceptorChain.java
    public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
                            RealConnection connection) throws IOException {
        if (index >= interceptors.size()) throw new AssertionError();
        // 注释 18，索引自加 1，执行下一个拦截器 
        calls++;
        ...... 
        ......
        // Call the next interceptor in the chain.
        // 注释 19， 创建下一个 RealInterceptorChain对象
        RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec,
                connection, index + 1, request, call, eventListener, connectTimeout, readTimeout,
                writeTimeout);
        //注释20， 获取下一个拦截器并执行 intercept
        Interceptor interceptor = interceptors.get(index);
        Response response = interceptor.intercept(next);
        ......
        return response;
    }

上面又省略了一些代码，从上面注释 19和注释 20我们可以看到，每个拦截器的执行都会先创建一个 RealInterceptorChain 对象与之协助。上面的注释 18处是拦截器列表索引自加 1，所以各拦截器的执行的顺序是按照列表的添加顺序来的。每个拦截器执行完后都会调用下一个拦截器的 RealInterceptorChain对象的 proceed()方法，以执行下一个环节。这一点待会儿在下面拦截器的介绍环节会说到。

上面对拦截器链的执行流程已经做了介绍，下面我们分析一下各个拦截器都干了啥。下面主要分析一下这些拦截器：RetryAndFollowUpInterceptor、BridgeInterceptor、CacheInterceptor、ConnectInterceptor、CallServerInterceptor。

*重连及重定向：RetryAndFollowUpInterceptor
RetryAndFollowUpInterceptor拦截器在遇到一些异常情况时，会选择重连或执行重定向，比如服务未授权、请求超时、请求重定向等。
我们来看一下RetryAndFollowUpInterceptor 拦截器调用请求出现异常之后的处理方法 recover() :

   // RetryAndFollowUpInterceptor.java
    private boolean recover(IOException e, StreamAllocation streamAllocation,
                            boolean requestSendStarted, Request userRequest) {
        streamAllocation.streamFailed(e);
        // The application layer has forbidden retries.
        // 注释 21, 用户设置的是否可以重连
        if (!client.retryOnConnectionFailure()) return false;
        // We can't send the request body again.
        // 注释22， 单次请求不可恢复
        if (requestSendStarted && userRequest.body() instanceof UnrepeatableRequestBody) return false;
        // This exception is fatal.
        // 注释 23， 不可恢复的异常，例如协议错误、验证错误等
        if (!isRecoverable(e, requestSendStarted)) return false;
        // No more routes to attempt.
        // 注释 24，没有更多的路由了
        if (!streamAllocation.hasMoreRoutes()) return false;
        // For failure recovery, use the same route selector with a new connection.
        return true;
    }

上面注释 21-注释 24列出了一些不可重连的条件包括用户设置不可重连等。下面我们来看看根据响应码执行相关重定向的方法 followUpRequest：

// RetryAndFollowUpInterceptor.java
    private Request followUpRequest(Response userResponse, Route route) throws IOException {
        if (userResponse == null) throw new IllegalStateException();
        int responseCode = userResponse.code();
        final String method = userResponse.request().method();
        switch (responseCode) {
            // 注释 25， 响应码为 401 或者 407 则表示请求未认证，此时重新对请求进行认证，然后返回认证后的 Request。
            case HTTP_PROXY_AUTH:
                Proxy selectedProxy = route != null
                        ? route.proxy()
                        : client.proxy();
                if (selectedProxy.type() != Proxy.Type.HTTP) {
                    throw new ProtocolException("Received HTTP_PROXY_AUTH (407) code while not using proxy"); }
                return client.proxyAuthenticator().authenticate(route, userResponse);
            case HTTP_UNAUTHORIZED:
                return client.authenticator().authenticate(route, userResponse);

            // 注释 26，响应码为 3xx 表示重定向，此时重定向地址在响应 Header 的 Location 字段中，
            // 然后通过这个新的地址以及之前的 Request 构建一个新的 Request 并返回。
            case HTTP_PERM_REDIRECT:
            case HTTP_TEMP_REDIRECT:
                if (!method.equals("GET") && !method.equals("HEAD")) {
                    return null; }
            case HTTP_MULT_CHOICE:
            case HTTP_MOVED_PERM:
            case HTTP_MOVED_TEMP:
            case HTTP_SEE_OTHER:
                if (!client.followRedirects()) return null;
                String location = userResponse.header("Location");
                if (location == null) return null;
                HttpUrl url = userResponse.request().url().resolve(location);
                if (url == null) return null;
                boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
                if (!sameScheme && !client.followSslRedirects()) return null;
                Request.Builder requestBuilder = userResponse.request().newBuilder();
                if (HttpMethod.permitsRequestBody(method)) {
                    final boolean maintainBody = HttpMethod.redirectsWithBody(method);
                    if (HttpMethod.redirectsToGet(method)) {
                        requestBuilder.method("GET", null);
                    } else {
                        RequestBody requestBody = maintainBody ? userResponse.request().body() : null;
                        requestBuilder.method(method, requestBody); }
                    if (!maintainBody) {
                        requestBuilder.removeHeader("Transfer-Encoding");
                        requestBuilder.removeHeader("Content-Length");
                        requestBuilder.removeHeader("Content-Type"); } }
                if (!sameConnection(userResponse, url)) {
                    requestBuilder.removeHeader("Authorization"); }
                return requestBuilder.url(url).build();
                
            // 注释 27，响应码 503 表示服务器错误，但这个是暂时的，可能马上就会恢复，所以会直接返回之前的请求。
            case HTTP_UNAVAILABLE:
                if (userResponse.priorResponse() != null
                        && userResponse.priorResponse().code() == HTTP_UNAVAILABLE) {
                    return null; }
                if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) {
                    // specifically received an instruction to retry without delay
                    return userResponse.request(); }
                return null;
            default:
                return null;
        }
    }

上面注释 25-注释 27，分别根据几种响应码进行相关操作。
响应码为 401 或者 407 则表示请求未认证，此时重新对请求进行认证，然后返回认证后的 Request。
响应码为 3xx 表示重定向，此时重定向地址在响应 Header 的 Location 字段中，然后通过这个新的地址以及之前的 Request 构建一个新的 Request 并返回。
响应码 503 表示服务器错误，但这个是暂时的，可能马上就会恢复，所以会直接返回之前的请求。

*设置请求头： BridgeInterceptor

    // BridgeInterceptor.java
    @Override public Response intercept(Interceptor.Chain chain) throws IOException {
        Request userRequest = chain.request();
        Request.Builder requestBuilder = userRequest.newBuilder();
        RequestBody body = userRequest.body();
        if (body != null) {
            MediaType contentType = body.contentType();
            if (contentType != null) {
                requestBuilder.header("Content-Type", contentType.toString());
            }
            long contentLength = body.contentLength();
            if (contentLength != -1) {
                requestBuilder.header("Content-Length", Long.toString(contentLength));
                requestBuilder.removeHeader("Transfer-Encoding");
            } else {
                requestBuilder.header("Transfer-Encoding", "chunked");
                requestBuilder.removeHeader("Content-Length");
            }
        }
     ...............
    // 看看是否有 Cookie
    List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
    if (!cookies.isEmpty()) {
      requestBuilder.header("Cookie", cookieHeader(cookies));
    }
     ...............
     ...............   
    }

请求头的参数设置太多了，所以上面只贴出一小部分瞧一瞧。
BridgeInterceptor 拦截器主要工作就是将用户请求转换为网络请求，具体一点来讲，就是根据 Request 信息组建网络 Header 以及设置响应数据。BridgeInterceptor 除了设置 Content-Length、Connect、Host 等等的基本请求头之外，还会负责设置 Cookie 以及 gzip。网络请求之前会先通过 url 判断是否有 cookie，有的话就会把这个 cookie 带上。

*缓存设置：CacheInterceptor

  //CacheInterceptor.java
  @Override public Response intercept(Interceptor.Chain chain) throws IOException {
        Response cacheCandidate = cache != null
                ? cache.get(chain.request())
                : null;
        // 注释 28， 取缓存策略
        long now = System.currentTimeMillis();
        CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
        Request networkRequest = strategy.networkRequest;
        Response cacheResponse = strategy.cacheResponse;
        ......
        // If we're forbidden from using the network and the cache is insufficient, fail.
        // 注释 29， 如果没缓存又不让联网 ，那就抛 504异常
        if (networkRequest == null && cacheResponse == null) {
            return new Response.Builder()
                    .request(chain.request())
                    .protocol(Protocol.HTTP_1_1)
                    .code(504)
                    .message("Unsatisfiable Request (only-if-cached)")
                    .body(Util.EMPTY_RESPONSE)
                    .sentRequestAtMillis(-1L)
                    .receivedResponseAtMillis(System.currentTimeMillis())
                    .build(); }
        // If we don't need the network, we're done.
        // 注释 30，如果没网，但有缓存，那就直接返回缓存
        if (networkRequest == null) {
            return cacheResponse.newBuilder()
                    .cacheResponse(stripBody(cacheResponse))
                    .build(); }
        Response networkResponse = null;
        try {
            networkResponse = chain.proceed(networkRequest);
        } finally {
            // If we're crashing on I/O or otherwise, don't leak the cache body.
            if (networkResponse == null && cacheCandidate != null) {
                closeQuietly(cacheCandidate.body());
            } }
        // If we have a cache response too, then we're doing a conditional get.
        // 注释 31，如果有缓存、有网络，且响应码为 304.那么返回缓存并更新缓存
        if (cacheResponse != null) {
            if (networkResponse.code() == HTTP_NOT_MODIFIED) {
                Response response = cacheResponse.newBuilder()
                        .headers(combine(cacheResponse.headers(), networkResponse.headers()))
                        .sentRequestAtMillis(networkResponse.sentRequestAtMillis())
                        .receivedResponseAtMillis(networkResponse.receivedResponseAtMillis())
                        .cacheResponse(stripBody(cacheResponse))
                        .networkResponse(stripBody(networkResponse))
                        .build();
                networkResponse.body().close();
                // 更新缓存
                cache.trackConditionalCacheHit();
                cache.update(cacheResponse, response);
                return response;
            } else {
                closeQuietly(cacheResponse.body());
            } }
        Response response = networkResponse.newBuilder()
                .cacheResponse(stripBody(cacheResponse))
                .networkResponse(stripBody(networkResponse))
                .build();
        if (cache != null) {
            if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
                // Offer this request to the cache.
                // 注释 32，如果没缓存，且网络响应可用，那么返回响应数据，并存入缓存。
                CacheRequest cacheRequest = cache.put(response);
                return cacheWritingResponse(cacheRequest, response);
            }
          ..........
        }
        return response;
    }

上面贴出了缓存拦截器,从注释 28-注释32的逻辑按顺序捋一捋：

• 如果没缓存又不让联网 ，那就抛 504异常
• 如果没网，但有缓存，那就直接返回缓存
• 如果有缓存、有网络，且响应码为 304.那么返回缓存并更新缓存
• 如果没缓存，且网络响应可用，那么返回响应数据，并存入缓存

*连接服务端：ConnectInterceptor

@Override public Response intercept(Chain chain) throws IOException {
    RealInterceptorChain realChain = (RealInterceptorChain) chain;
    Request request = realChain.request();
    StreamAllocation streamAllocation = realChain.streamAllocation();

    // We need the network to satisfy this request. Possibly for validating a conditional GET.
    boolean doExtensiveHealthChecks = !request.method().equals("GET");
    HttpCodec httpCodec = streamAllocation.newStream(client, chain, doExtensiveHealthChecks);
    RealConnection connection = streamAllocation.connection();

    return realChain.proceed(request, streamAllocation, httpCodec, connection);
  }

这个方法比较简洁，就是创建一个连接，然后调用下一个环节的Chain.proceed()方法去读写数据。在这个过程中，会尝试去 RealConnectionPool 中寻找已存在的连接，未找到则会重新创建一个 RealConnection 并开始连接，然后将其存入 RealConnectionPool连接池。

*读写数据：CallServerInterceptor

这一层是最后一个拦截器了，会与服务器进行数据交互。看 CallServerInterceptor源码 intercept(),这个拦截器读写数据大概有以下几个步骤：

• 写入请求头
• 判断请求体是否为空
• 读取 Respose的 Header
• 判断响应码是否为 100 （是则重新读取 Respose）
• 读取 Respose Body
• 判断响应码是否为 204或 205，且响应体内容长度大于 0（是则抛 ProtocolException异常）
• 返回 Respose

应该来说，OkHttp框架处理了大量的细节。很难说一次性阅读就能窥这个框架的全貌，但这不妨碍我们了解框架的大体执行流程和它的设计思想。框架里也涉及到很多网络加载的基础知识，希望每次阅读都能对 OkHttp有更进一步的了解吧。