使用了好久的okhttp，都没有对其源码进行学习拆解，今天开始，有时间就写一些学习笔记，对okhttp进行分析。
基本请求流程
源码地址：https://github.com/square/okhttp
如何使用的？
以一个 Post同步 请求为例：
OkHttpClient client = new OkHttpClient();
RequestBody body = RequestBody.create(JSON, json);
Request request = new Request.Builder()
.url(url)
.post(body)
.build();
Response response = client.newCall(request).execute());
根据上面的代码，使用okhttp，基本就是四步：
第一步，建立一个OkHttpClient 类，这个类包含了一系列的协议路由，拦截器等等，都是后面请求必不可少的变量。（具体解析留在后面）
第二步，创建 RequestBody ，请求的实体，可以指定对应的contentType ，还有具体是实体内容。
第三步，创建请求，指定url, 还有body。Request类使用的是Bulder模式，在okhttp里面比较大面积的使用此模式。
第四步，通过第一步的client 调用 newCall 创建一个Call ，然后execute()，发起一个同步的请求。
如果我们只是使用，拿到结果，请求就已经可以结束了。但是我们需要了解它的内部实现，现在才刚刚开始。
具体流程：
接下来就是从这个OkHttpClient 的 newCall 还有 execute()，开始向下了剖析。
@Override public Call newCall(Request request) {
return new RealCall(this, request, false /* for web socket */);
}
原来这个Call只是一个接口，这里真正是创建了一个实现Call接口的 RealCall对象。可以看看这个RealCall里面的 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);
}
}
这个RealCall 里面的执行的方法，首先会把这个Call 加入到 dispatcher 这个调度器里面（Dispatcher这个类也需要好好研究一下，主要是Call请求线程相关的控制）。
由于我们分析的是同步请求，这里的dispatcher作用是可以方便对这个Call进行统一控制，如取消等 。
接下来就是调用了 getResponseWithInterceptorChain();
那我们继续向下这个方法进发了：
Response getResponseWithInterceptorChain() throws IOException {
// Build a full stack of interceptors.
List 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);
}
哇，这里好多这个Interceptor ，意为拦截器的意思。其实就是对将要发出去的请求，或者接收到的结果的进行拦截，然后进行一些需要的修改，然后在做下一步操作。例如在发出去前，添加必要的信息，或者回来之后把结果进行统一的处理。
这里把自定义的拦截器，还有内置的必要的拦截器都添加到一个List里面了，最后用List的拦截器创建一个拦截器的链—— RealInterceptorChain。而这个RealInterceptorChain 其实是实现了Interceptor 里面的一个Chain 接口。
这里最后调用 chain.proceed(originalRequest); 这里就是返回一个Response 对象了，但是这中间这么多的拦截器，都干了些什么了？ 是如何拦截的？如果连接起来的？带着问题，我们继续向这里面剖析。
我们先了解一下RealInterceptorChain 这个类是如何进行工作的。
首先RealInterceptorChain，是实现了Interceptor.Chain 接口的一个类，这个接口有是三个方法，后面会介绍到，其中一个就是前面调用的proceed方法。
那么在它的 proceed中做了什么？
@Override
public Response proceed(Request request) throws IOException {
return proceed(request, streamAllocation, httpCodec, connection);
}
public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
RealConnection connection) throws IOException {
//省略一些前置校验的代码
、、、
// Call the next interceptor in the chain.
RealInterceptorChain next = new RealInterceptorChain(
interceptors, streamAllocation, httpCodec, connection, index + 1, request);
Interceptor interceptor = interceptors.get(index);
Response response = interceptor.intercept(next);
//省略一些后续处理代码
、、、
return response;
}
省略了前后的一些代码，发现，其实这里又新建一个 RealInterceptorChain，然后调用了这个拦截器的 intercept 的方法。那么在每个拦截器里面做了什么，这个拦截的方法又是做了什么呢？
首先看一下拦截器这个接口：
public interface Interceptor {
Response intercept(Chain chain) throws IOException;
interface Chain {
Request request();
Response proceed(Request request) throws IOException;
Connection connection();
}
}
很明显，每个实现Interceptor的拦截器。都会实现了intercept，这样一个拦截的方法。而传入的就是一个Chain。符合前面RealInterceptorChain的调用。
以一个拦截器的代码为例：BridgeInterceptor，这个类实现的intercept方法，而这个方法里面，除了那些前置或后续的操作之外，在中间你会发现 下面一句代码：
Response networkResponse = chain.proceed(requestBuilder.build());
又通过传进来的Chain ，重新调用了proceed的方法。好吧，到这里应该可以了解到这些拦截器，是如何一个个调用被调用的了，原理都是通过了中间的一个RealInterceptorChain，一个接一个的向下调用。然后得到的结果又一个一个向上传。
总结一下，这些拦截器的调用：
刚开始getResponseWithInterceptorChain的最后开始调用了 chain.proceed，然后在RealInterceptorChain的里面，又新建一个 RealInterceptorChain，并且调用当前的拦截器的 intercept，并且把新建的Chain传递进去，然后拦截器的 intercept方法里面，除了一些自身的操作外，又调用Chain的proceed方法。就这样一直调用新建Chian, 一直调用到最后一个拦截器。
这里的调用其实是一个迭代，递归的结构。请求做了前一步的处理才能到下一级，一级级下去，到最后真正发出去请求，相对做了拦截。而得到结果，只有当最后一个拦截器完全了请求，拿到结果之后，才会把结果往上一级，上一级拿到结果，做了相应的处理之后，再到上一级，这就是对结果的拦截处理。
这么看来，流程最后一个拦截器就是最终拿到结果的一个地方了。
而每个拦截器都有每个的作用，这里只做简单的按顺序进行介绍，后面再对其深入的剖析。
- RetryAndFollowUpInterceptor
这拦截器主要是做重试，网络错误，以及请求重定向的一些操作。 - BridgeInterceptor
这个拦截器，主要把用户的请求转换为网络的请求，添加一些头部信息等。 - CacheInterceptor
缓存拦截器 - ConnectInterceptor
连接拦截器，主要是处理连接服务器，以及http , https的包装 - CallServerInterceptor
服务拦截器，主要是发送（write、input）、读取（read、output）数据。也是拦截器的最后一个环节，这里就真正拿到了网络的结果了。
最后是一个图示例来展示一下，发出请求到收到结果的整个流程，是如果进行的：
结束：
到这里为止，其实整个okhttp, 发出请求，到接收请求的流程已经清晰了，但是这仅仅是最基本的流程，你会发现很多有疑问的地方，如：OkHttpClient整个类到底做了些什么？RequestBody，是一个怎么样的类？每一个Request的结构是如何的？每一个RealCall , 是怎么分配线程的？每一个拦截器都干了什么？等等。带着问题，继续剖析下去。
系列：
OKhttp源码学习（二）—— OkHttpClient
OKhttp源码学习（三）—— Request, RealCall
OKhttp源码学习（四）——RetryAndFollowUpInterceptor拦截器分析
OKhttp源码学习（五）—— BridgeInterceptor拦截器
OKhttp源码学习（六）—— CacheInterceptor拦截器
OKhttp源码学习（七）—— ConnectInterceptor拦截器
OKhttp源码学习（八）——CallServerInterceptor拦截器
OKhttp源码学习（九）—— 任务管理（Dispatcher）