try {
Response response = call.execute();
String s = new String().concat(response.code() + “\n”)
.concat(response.message() + “\n”)
.concat(response.body().string());
Log.d(“sendReqTag”, "onSuccess\n " + s);
} catch (IOException e) {
e.printStackTrace();
}
}
}
OkHttp源码核心类之一：分发器详解
上述，提到Call类，可以选择性执行 同步或者异步请求，但是无论同步异步，都一定会经过一个门户:“分发器” :
索引进源码(okhttp v3.10.0):
虽然用户不需要直接操作分发器，但是 分发器，作为OkHttp架构的一个门户层，是所有请求的必经之路，其中的代码还是有必要了解细节的。
同步请求
进入分发器 Dispatcher之后, 会执行 getResponseWithInterceptorChain() 来执行这个Call任务，得到一个Response,其中的细节分为两步：
同步请求的执行步骤十分简单，将任务加入到 runningSyncCalls列表，并且直接执行核心方法，同步阻塞拿到response。
异步请求
那么问题来了，readyAsyncCalls中的任务什么时候会被执行？
追踪代码：追踪 readyAsyncCalls 的使用代
码，找到遍历这个队列的地方：
继续追踪finish在哪里调用的，找到两处:
文字不够形象，画个图表示。
关于okhttp的分发器Dispatcher用到的线程池
同步请求，没有用到线程池。
但是异步请求的代码中，有这么一句。
我们知道，为什么这里会用到线程池呢？
进一步观察这个线程池的细节：
为什么okhttp偏偏选择了这一种？
详解如下：
既然这里提到了线程池，那么就把线程池的基本机制整理一下：
OkHttp源码核心类之一：拦截器简述
上面讲解分发器的时候，提到了 RealCall类的getResponseWithInterceptorChain() 方法。它是一个网络请求执行的真正核心方法。
进入方法：
首先解释一下责任链模式，它是21种基本设计模式中，行为模式中一种。下面的案例可以很好地解释它：
首先解释一下责任链模式，它是21种基本设计模式中，行为模式中一种。下面的案例可以很好地解释它：
