OkHttp源码探索

之前一直在使用volley作为网络请求模块，但发现volley已经过时（源码还是很值得反复品味的），现在基本是Retrofit和OkHttp的天下了，于是把OkHttp拿来学习一下。
首先，看一个OkHttp的简单示例：

        Request.Builder builder = new Request.Builder().url(url).get();        Request okRequest = builder.build();        Call call = mOkHttpClient.newCall(okRequest);        call.enqueue(new Callback() {            @Override            public void onFailure(Call call, IOException e) {                e.printStackTrace();            }            @Override            public void onResponse(Call call, final Response response) throws IOException {                mHandler.post(new Runnable() {                    @Override                    public void run() {                        listener.onFetchFinished(response.body().string());                    }                });            }        });

该类框架都比较类似，创建一个请求及回调，然后加入请求队列，后面就由框架来进行任务调度，和结果回调。具体的细节，后面使用时再慢慢看，现在先探索一下OkHttp的主路线。

首先， 把请求加入到任务队列：

//okhttp3.RealCall.java  @Override public void enqueue(Callback responseCallback) {    synchronized (this) {      if (executed) throw new IllegalStateException("Already Executed");      executed = true;    }    client.dispatcher().enqueue(new AsyncCall(responseCallback));  }

此方法就为避免单个请求多次添加，

// Dispatcher.java  synchronized void enqueue(AsyncCall call) {    if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {      runningAsyncCalls.add(call);      executorService().execute(call);    } else {      readyAsyncCalls.add(call);    }  }  /** Returns the number of running calls that share a host with {@code call}. */  private int runningCallsForHost(AsyncCall call) {    int result = 0;    for (AsyncCall c : runningAsyncCalls) {      if (c.host().equals(call.host())) result++;    }    return result;  }  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;  }

这个方法比较有意思，很明显有两个任务队列，一个是正在执行的队列（runningAsyncCalls）和一个等待队列（readyAsyncCalls）；不仅限制了最大并发请求的数量，还对同一个域名的并发请求做了限制，当然单个应用可能请求的域名都是一样的，所以这个就得看实际情况了。
当前并发请求数量小于限制时，就把请求直接丢到线程池中执行；否则就把请求加入到等待队列。在代码中搜索readyAsyncCalls，看看等待队列中的任务是什么时候被执行的。看到下面的方法：

// Dispatcher.java  private void promoteCalls() {    if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity.    if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote.    for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {      AsyncCall call = i.next();      if (runningCallsForHost(call) < maxRequestsPerHost) {        i.remove();        runningAsyncCalls.add(call);        executorService().execute(call);      }      if (runningAsyncCalls.size() >= maxRequests) return; // Reached max capacity.    }  }

搜索这个方法是在哪里被调用的：

可以看到，在任务结束、改变最大并发请求和改变域名最大并发请求时会调用该方法，这些肯定是在意料之中的。

接下来就跟踪一下任务是如何执行的，我们就从队列中的请求任务入手。
AsyncCall的继承关系如下：

abstract class NamedRunnable implements Runnablefinal class AsyncCall extends NamedRunnable

/** * Runnable implementation which always sets its thread name. */public abstract class NamedRunnable implements Runnable {  protected final String name;  public NamedRunnable(String format, Object... args) {    this.name = Util.format(format, args);  }  @Override public final void run() {    String oldName = Thread.currentThread().getName();    Thread.currentThread().setName(name);    try {      execute();    } finally {      Thread.currentThread().setName(oldName);    }  }  protected abstract void execute();}

任务的执行放在了execute()中执行。我们来看看AsyncCall的execute()方法：

    @Override protected void execute() {      boolean signalledCallback = false;      try {        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 {          responseCallback.onFailure(RealCall.this, e);        }      } finally {        client.dispatcher().finished(this);      }    }

可以看出来，主要的内容是在getResponseWithInterceptorChain()里面，因为这个方法直接返回了Response，也就是请求结果。

  private Response getResponseWithInterceptorChain() throws IOException {    // Build a full stack of interceptors.    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 (!retryAndFollowUpInterceptor.isForWebSocket()) {      interceptors.addAll(client.networkInterceptors());    }    interceptors.add(new CallServerInterceptor(        retryAndFollowUpInterceptor.isForWebSocket()));    Interceptor.Chain chain = new RealInterceptorChain(        interceptors, null, null, null, 0, originalRequest);    return chain.proceed(originalRequest);  }

这个方法的主要内容是得到一个列表interceptors，从字面上看，这个列表是用于请求拦截。通过断点跟踪后发现，这个列表确实重要，并且顺序也是非常的重要，从下面的代码慢慢分析。

//RealInterceptorChain.java  @Override public Response proceed(Request request) throws IOException {    return proceed(request, streamAllocation, httpStream, connection);  }  public Response proceed(Request request, StreamAllocation streamAllocation, HttpStream httpStream, Connection connection) throws IOException {    if (index >= interceptors.size()) throw new AssertionError();    、、、    // Call the next interceptor in the chain.     //注意这里的index+1了    RealInterceptorChain next = new RealInterceptorChain(        interceptors, streamAllocation, httpStream, connection, index + 1, request);    Interceptor interceptor = interceptors.get(index);    Response response = interceptor.intercept(next);    、、、    return response;  }

省略一些异常情况处理后，很清晰的看到，从interceptors列表的第一项（index初始化为0）开始执行interceptor.intercept(next)，并且参数是RealInterceptorChain链条的下一个节点。

  @Override public Response intercept(Chain chain) throws IOException {    Request request = chain.request();    streamAllocation = new StreamAllocation(        client.connectionPool(), createAddress(request.url()));    int followUpCount = 0;    Response priorResponse = null;    while (true) {      if (canceled) {        streamAllocation.release();        throw new IOException("Canceled");      }      Response response = null;      boolean releaseConnection = true;      try {        response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);        releaseConnection = false;      } catch (RouteException e) {        、、、      } finally {        // We're throwing an unchecked exception. Release any resources.        if (releaseConnection) {          streamAllocation.streamFailed(null);          streamAllocation.release();        }      }      // Attach the prior response if it exists. Such responses never have a body.      if (priorResponse != null) {        response = response.newBuilder()            .priorResponse(priorResponse.newBuilder().body(null).build())            .build();      }      Request followUp = followUpRequest(response);      if (followUp == null) {        if (!forWebSocket) {          streamAllocation.release();        }        return response;      }      closeQuietly(response.body());      、、、      request = followUp;      priorResponse = response;    } // end while  }

这个方法的主体是一个死循环，有两种方式退出循环：一个是throw new IOException(“Canceled”)，另一个是return response。也就是说，当请求被取消，或者得到结果了就结束返回了。再看看response是什么时候被赋值的：

response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);

又回到刚才的proceed(request)里面了，而proceed(request)里面用到了index+1，也就是这时会使用interceptors列表中的第二个interceptor来进行intercept(next)，酱紫看来，这是一个递归的过程。只有当进行到chain中的某一个节点，能够得response而不是继续向下传递时，递归开始反转退栈。
跟踪代码看到interceptor的顺序为RetryAndFollowUpInterceptor——>BridgeInterceptor——>CacheInterceptor——>ConnectInterceptor——>CallServerInterceptor. 至于为何需要这么几层，还不是很清楚，还需要继续学习。

至此，okhttp的请求主流程基本介绍完毕，后面还有大量的东西需要去学习。