而对于同步任务，Dispatcher只是简单记录当前运行的任务实体（RealCall），并且是由RealCall主动注册和注销。

Dispatcher是final类，不提供扩展接口，但是Dispatcher存在两个构造方法：Dispatcher()和Dispatcher(ExecutorService)。OkHttpClient默认会使用无参构造函数创建一个全局的单例对象，该对象使用内置的线程池来执行异步任务，如果用户想使用自定义线程池，那么可以通过使用有参构造函数创建一个新的Dispatcher对象，并且通过OkHttpClient.Builder设置进去。

Call

OkHttp一次用户请求任务的接口定义，有两个实现：RealCall和AsyncCall，前者是同步任务，后者是异步任务。

这里我之所以把Call称作为“一次用户请求”，是因为一次OkHttp请求和响应，中间可能夹着多个请求和响应，比如代理服务的认证、失败重试、重定向等等，但是这些对于OkHttp的使用者来说都是透明的，他们很多时候只需要感知最初的请求和最后的结果即可，而Call是包含中间这些所有的过程的，因此我把Call称为“一次用户请求”。

Interceptor调用链

Interceptor接口在OKHttp包下有5个内置实现，也就是上图中最大的那一个框。它们通过责任链的方式调用，实现了Http协议的整个流程，当然这个流程指的是应用层协议的流程，不包括底下传输层的实现。

Interceptor是可扩展可配置的，用户可以自定义实现Interceptor接口，并且通过OkHttpClient添加到Http流程的实现中去。

OKHttpClient有两个可配置的Interceptor集合（它们默认都是空的）：interceptors和networkInterceptors。interceptors会被添加到调用链的最前面；而networkInterceptors则会被添加到Socket连接之后，Socket读写数据之前。但是如果是WebSocket请求，networkInterceptors集合则不会被添加到调用链中去。

Response getResponseWithInterceptorChain() throws IOException {

// Build a full stack of interceptors.

List interceptors = new ArrayList<>();

//用户自定义的拦截器会在请求最开始被调用，也就是递归的最上层

interceptors.addAll(client.interceptors());

//失败重试，代理认证、重定向等

interceptors.add(new RetryAndFollowUpInterceptor(client));

//重写请求和响应头，Cookie存储

interceptors.add(new BridgeInterceptor(client.cookieJar()));

//Http缓存流程实现

interceptors.add(new CacheInterceptor(client.internalCache()));

//发起Socket连接

interceptors.add(new ConnectInterceptor(client));

//Socket连接和数据读写之间，但是WebSocket请求不会添加这个拦截器集合

//可能WebSocket，数据通信走的是传输层，而Interceptor是应用层协议的接口？

if (!forWebSocket) {

interceptors.addAll(client.networkInterceptors());

}

//数据的读写，真正的网络I/O

interceptors.add(new CallServerInterceptor(fo
rWebSocket));

…

}

Transmitter

Transmitter翻译过来有“传输者、传播者”的意思，所以在这里我还是用上下文来称呼它，作用域是整个Call任务。

Transmitter会在Interceptor调用链中相互传递，Interceptor会通过Transmitter对象的属性或者方法对底下的传输层进行操作，Transmitter对调用者屏蔽了传输层的实现细节，让Interceptor调用链专注于应用层协议的实现。

Transmitter管理着Call任务的很多状态（比如请求开始、请求结束、失败、取消等等），调用者随时可以获取Call的状态从而实现相应的逻辑处理，也可以根据处理的结果更新其状态。

Transmitter还持有用户配置，实现了超时回调机制等等。

Transmitter往下的代码耦合性挺强的，层次之间其实没有上面那图那么清晰，它直接会存在一些交叉，彼此之间相互调用，个人觉得这部分代码可读性是挺差的 - -！。同时多数类都是final类，并不向上提供接口，也就是这部分代码是不可扩展的，只是留有一些可配置的参数属性（比如：连接池最大空闲连接数），我不知道这是OkHttp历史版本迭代的原因，还是作者有意这样设计，如果有小伙伴对这方面有了解的话，希望可以留言跟大家分享一下。

Exchange层

这个名字是我直接根据它几个主要实现类的名称前缀来取的，可能不能很好表明这一层的具体功能。总的来说这一层主要负责连接应用层和传输层，例如：Http协议作为应用层协议，它的主要流程由上面的Interceptor调用链来实现，但是Interceptor不会直接和传输层的实现类打交道，而是通过Exchange提供的API去实现数据的读写。

Exchange层主要有三个类：Exchange、ExchangeFinder和ExchangeCodec，前两个都是Transmitter的属性，第三个有ExchangeFinder创建。

• Exchange：Exchange代表着一次Request和Response，里面封装了应用层的读写方法，Interceptor调用链就是通过Transmitter获取的Exchange对象来进行读写操作。一次Request和Response，也即是上面的Interceptor调用链从RetryAndFollowUpInterceptor到CallServerInterceptor绕了一圈，但是一个Call任务并不代表仅仅只会绕一圈，比如你访问百度之前需要通过你公司的代理服务器，那么就可能在发送请求到百度之前，先发送一次Http请求到代理服务认证，认证通过了才会继续发送请求到百度，这样就绕了两圈了，也就是发送了两次Http请求，同理还有重定向也是一样。简单来说一次用户请求是一个Call，一个Call可能会发生多次Exchange，但是对于用户来说Exchange是透明的，只需要感知Call即可。

• ExchangeCodec：OkHttp的编解码器，这是一个接口，具体实现有Http1ExchangeCodec和Http2ExchangeCodec。下面这图展示的是Exchange、ExchangeCodec、Okio和网络I/O，在读写操作上的层次关系。

• ExchangeFinder：ExchangeFinder类似一个工厂类，对外只提供一个方法，就是返回一个ExchangeCodec对象，下面这段代码能比较清楚展示Exchange、ExchangeCodec和ExchangeFinder三者之间的关系。

/** Returns a new exchange to carry a new request and response. */

Exchange newExchange(Interceptor.Chain chain, boolean doExtensiveHealthChecks) {

…

ExchangeCodec codec = exchangeFinder.find(client, chain, doExtensiveHealthChecks);

ean doExtensiveHealthChecks) {

…

ExchangeCodec codec = exchangeFinder.find(client, chain, doExtensiveHealthChecks);