前言

在面试中，OkHttp作为我们基本属于必用的第三方库来说，也是一个非常重要的考点，所以对其原理的掌握也会让我们的能力得到一定的提升。

一般进OkHttp的官网是需要翻墙的。

基本使用

先一段引入关于OkHttp的使用，这是直接拉取了官网挂着的使用方法。
因为在一般的使用过程中，后台可能会通过比较带有的session或者cookie来判断当前用户是否和缓存的用户相同，所以一般一个项目整体使用单个OkHttpClient的对象。

OkHttpClient client = new OkHttpClient();

String run(String url) throws IOException {
  Request request = new Request.Builder()
      .url(url)
      .build();

  try (Response response = client.newCall(request).execute()) {
    return response.body().string();
  }
}

TCP/IP模型

因为OkHttp实现的基础是对一个网络整体模型的一个理解，所以知道TCP/IP模型中的一些知识是必要的。

源码解析

OkHttpClient client = new OkHttpClient.Builder().build();
Request request = new Request.Builder()
                .url(url)
                .build();

Call call = client.newCall(request);
call.enqueue(new Callback() {
        @Override
        public void onFailure(Call call, IOException e) {

        }

        @Override
        public void onResponse(Call call, Response response) throws IOException {

        }
});

这是我们的在okhttp中使用的方法，整个项目的解析将围绕下面5个类进行。

• OkHttpClient
• Request
• Call
• Callback
• Response

首先是OkHttpClient和Request。
为什么这两个一起讲解呢？因为两个构造方式相同OkHttpClient是一个全局掌控者，Request是一个请求体的封装。

public final class Request {
  final HttpUrl url; // 路径
  final String method; // 请求方式
  final Headers headers; // 请求头
  final @Nullable RequestBody body; // 请求体
  final Object tag;
}

public class OkHttpClient implements Cloneable, Call.Factory, WebSocket.Factory {
  final Dispatcher dispatcher;
  final @Nullable Proxy proxy;
  final List<Protocol> protocols;
  final List<ConnectionSpec> connectionSpecs;
  final List<Interceptor> interceptors; // 拦截器
  final List<Interceptor> networkInterceptors; // 网络拦截器
  final EventListener.Factory eventListenerFactory;
  final ProxySelector proxySelector;
  final CookieJar cookieJar;
  final @Nullable Cache cache;
  final @Nullable InternalCache internalCache;
  final SocketFactory socketFactory;
  final @Nullable SSLSocketFactory sslSocketFactory;
  final @Nullable CertificateChainCleaner certificateChainCleaner;
  final HostnameVerifier hostnameVerifier;
  final CertificatePinner certificatePinner;
  final Authenticator proxyAuthenticator;
  final Authenticator authenticator;
  final ConnectionPool connectionPool;
  final Dns dns;
  final boolean followSslRedirects;
  final boolean followRedirects;
  final boolean retryOnConnectionFailure;
  final int connectTimeout;
  final int readTimeout;
  final int writeTimeout;
  final int pingInterval;
}

能看到OkHttpClient的内部元素很多，但是我们很多时间并不会进行使用，是因为他自己已经做了很多层的封装，另外他们这种创建对象的模式又称为构建型设计模式。

接下来就是Call这个类，根据模版写法，我们知道需要将封装好的Request请求体数据塞入OkHttpClient中返回的就是一个Call。

@Override public Call newCall(Request request) {
    return RealCall.newRealCall(this, request, false /* for web socket */);
}

通过进入newCall()方法，我们知道返回的数据其实是实现Call的接口一个具体类RealCall，具体操作我们不用知道，我们只用知道返回的一个具体类是什么就可以了，因为往后的操作都是围绕一个具体的东西展开的。
在看模版的下一句话call.enqueue(...)，进入函数，我们可以看到下述的函数。

@Override public void enqueue(Callback responseCallback) {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      // 是一个以private修饰的变量，调用一次这个函数就变为true
      // 说明一个call只能调用一次enqueue函数
      executed = true;
    }
    captureCallStackTrace();
    eventListener.callStart(this);
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
}

其他都还好，直接看到上述最后一行代码，因为我们需要将任务发布出去，并且拿到数据。

  synchronized void enqueue(AsyncCall call) {
    // 正在运行的数量不能超过maxRequests=64
    // 向同一主机发出的请求不能超过maxRequestsPerHost=5
    if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
      runningAsyncCalls.add(call);
      executorService().execute(call); // 1
    } else {
      readyAsyncCalls.add(call);
    }
  }

注释1处其实就是一个线程池，enqueue()的作用就是将整一个请求放入，并置为异步，而使用的线程池类型就是CachedThreadPool。
但是我们虽然知道了这是一个异步处理，但是我们并没有看到我们要看的数据呀。。。。
所以我们只能暂时停下，思考一个问题了。线程池运行的是什么？是线程啊！！！！！但是我们只看到了一个什么东西，是一个AsyncCall的变量，这是啥，这只可能是一个Runnable呗，还能是啥。。。当我们点进去之后，我们就能够发现他的执行函数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 {
          eventListener.callFailed(RealCall.this, e);
          responseCallback.onFailure(RealCall.this, e);
        }
      } finally {
        client.dispatcher().finished(this);
      }
    }
  }

在这里我们能够惊奇的发现下述的几段代码。

responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
responseCallback.onResponse(RealCall.this, response);
responseCallback.onFailure(RealCall.this, e);

而他们对应就是我们的Callback了，但是很糟心的是他们非要改的样貌出现。又有读者问了，就算我们找到了，我们知道一般继承自Runnable的都是重写run()方法不是？？
那我们只好继续溯源这个AsyncCall类了，他继承自一个NamedRunnable抽象类，我们进去看看好了。

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();
}

代码也不长，就直接看全貌了，原来这是一个已经经过一步封装的Runnable，那这里基本已经揭晓了数据的来源了。

最后解释一个response的来源了，我们已经看到了这样一句话。

Response response = getResponseWithInterceptorChain();
// 通过点击可得下述的函数。
Response getResponseWithInterceptorChain() throws IOException {
    // 一堆的拦截器配置
    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));

    Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0,
        originalRequest, this, eventListener, client.connectTimeoutMillis(),
        client.readTimeoutMillis(), client.writeTimeoutMillis());

    return chain.proceed(originalRequest);
  }

其实他就是通过一堆的拦截器来获取数据的，但是显然这里不是终点站，因为我们看到的return中就还是一个函数，说明答案还在这个函数中。通过观察我们很容易得知，这个的操作的具体类是一个叫做RealInterceptorChain的类。

public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
      RealConnection connection) throws IOException {
    。。。。。
    // 一个很简单的逻辑，就是通过遍历拦截器，检查谁拿得到
    RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec,
        connection, index + 1, request, call, eventListener, connectTimeout, readTimeout,
        writeTimeout);
    Interceptor interceptor = interceptors.get(index);
    Response response = interceptor.intercept(next);

    。。。。
    return response;
  }

总结

接下来我们通过一张图来完成对整个OkHttp的工作流程梳理。

以上就是我的学习成果，如果有什么我没有思考到的地方或是文章内存在错误，欢迎与我分享。

相关文章推荐：
手撕AsyncTask
手撕ButterKnife
HandlerThread那些事儿
手撕Handler