OKHttp源码分析
1，OKHttp工作流程
在使用OKHttp请求调用call.enqueue(responseCallback)的时候，就是将call加入到Dispatcher中，交给Diapatcher来分发，下面是call.enqueue()的代码：
@Override public void enqueue(Callback responseCallback) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
client.dispatcher().enqueue(new AsyncCall(responseCallback));
}
然后我们看一下dispatcher().enqueue(new AsyncCall(responseCallback))是怎么写的：
synchronized void enqueue(AsyncCall call) {
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
runningAsyncCalls.add(call);
executorService().execute(call);
} else {
readyAsyncCalls.add(call);
}
}
很简单，就是判断如果当前正在运行的request小于64并且和call相同的这个端口的请求数小于5的时候，就直接把这个call加入到当前运行的请求队列中，并且用线程池启动这个call，否则就加入到等待的请求队列中，下面是call的execute()代码：
@Override public Response execute() throws IOException {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
try {
client.dispatcher().executed(this);
Response result = getResponseWithInterceptorChain();
if (result == null) throw new IOException("Canceled");
return result;
} finally {
client.dispatcher().finished(this);
}
}
可以看到，真正请求获得response的部分是在getResponseWithInterceptorChain()；先不看这个，看一下再最后finally运行的dispatcher.finished()，看看这个做了什么：
private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
int runningCallsCount;
Runnable idleCallback;
synchronized (this) {
if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
if (promoteCalls) promoteCalls();
runningCallsCount = runningCallsCount();
idleCallback = this.idleCallback;
}
if (runningCallsCount == 0 && idleCallback != null) {
idleCallback.run();
}
}
这段代码先是将call从正在运行的请求队列里移除，然后在调用了promoteCalls从等待的请求队列里移动请求到运行队列里，
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.
}
}
可以看出，最后finally运行的代码就是手动的移动等待的请求队列。
现在来看一看具体是怎么样取得response的，也就是上面提到的getResponseWithInterceptorChain()，
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 (!forWebSocket) {
interceptors.addAll(client.networkInterceptors());
}
interceptors.add(new CallServerInterceptor(forWebSocket));
Interceptor.Chain chain = new RealInterceptorChain(
interceptors, null, null, null, 0, originalRequest);
return chain.proceed(originalRequest);
}
Socket连接的部分在ConnectInterceptor中，而在ConnectInterceptor中，我们主要看一下StreamAllocation的代码，
public HttpCodec newStream(OkHttpClient client, boolean doExtensiveHealthChecks) {
int connectTimeout = client.connectTimeoutMillis();
int readTimeout = client.readTimeoutMillis();
int writeTimeout = client.writeTimeoutMillis();
boolean connectionRetryEnabled = client.retryOnConnectionFailure();
try {
RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout,
writeTimeout, connectionRetryEnabled, doExtensiveHealthChecks);
HttpCodec resultCodec = resultConnection.newCodec(client, this);
synchronized (connectionPool) {
codec = resultCodec;
return resultCodec;
}
} catch (IOException e) {
throw new RouteException(e);
}
}
在findHealthyConnection()函数中，真正连接的代码如下：
RealConnection candidate = findConnection(connectTimeout, readTimeout, writeTimeout,
connectionRetryEnabled);
这部分代码很长，主要做了如下三个部分的工作：
1， 选择路线与自动重连(RouteSelector)
在RouteSelector的next()函数中，
如果Proxy为null，
（1）在构造函数中设置代理为Proxy.NO_PROXY
（2）如果缓存中的lastInetSocketAddress为空，就通过DNS（默认是Dns.SYSTEM，包装了jdk自带的lookup函数）查询，并保存结果，注意结果是数组，即一个域名有多个IP，这就是自动重连的来源。
（3）如果还没有查询到就递归调用next查询，直到查到为止
（4）一切next都没有枚举到，抛出NoSuchElementException，退出(这个几乎见不到)。
如果Proxy为HTTP
（1）设置socket的ip为代理地址的ip
（2）设置socket的端口为代理地址的端口
（3）一切next都没有枚举到，抛出NoSuchElementException，退出
2，连接socket
连接socket这部分的工作主要是由RealConnection完成的，在经过RouteSelector选择完端口之后，就可以进行TCP连接了，这部分的工作主要分为如下5各部分：
（1）如果连接池中已经存在连接，就从中取出(get)RealConnection，如果没有就进行下一步。
（2）根据选择的路线(Route)，调用Platform.get().connectSocket选择当前平台Runtime下最好的socket库进行握手
（3）将建立成功的RealConnection放入(put)连接池缓存
（4）如果存在TLS，就根据SSL版本与证书进行安全握手
（5） 构造HttpStream并维护刚刚的socket连接，管道建立完成
3，release Socket
这部分主要有两部分工作：
（1）尝试从缓存的连接池中删除(remove)
（2）如果没有命中缓存,就直接调用jdk的socket关闭
在socket连接完成之后，接下来进行的就是http请求的序列化/response的反序列化。在connect中有很重要的一步：
source = Okio.buffer(Okio.source(rawSocket));
sink = Okio.buffer(Okio.sink(rawSocket));
source简单理解就是 inputstream，sink类似于outputstream，在OKHttp中拦截器是非常重要的部分，request.builder.build()出来的是一般的请求，如果要添加其他的装饰，就需要用到拦截器interceptor，拦截器可以用来修改/消费请求，修改结果。
