image
由于异步请求和同步请求的前三步是一样的，唯一产生分歧的是最后异步 call 调用请求方法的不同。同步是调用的 execute() 方法，然而异步是调用的 enqueue() 方法，这里就不对前三步再做解释了，如果不清楚前三步明细可以查看这篇文章OkHttp同步请求 源码分析的前三步分析。然后这里直接做异步请求第四步 call.enqueue() 的源码分析。
//第四步 call对象调用enqueue()方法，通过Callback()回调拿到响应体Response
call.enqueue(new Callback() {
@Override
public void onFailure(Call call, IOException e) {
//异步请求失败之后的回调
}
@Override
public void onResponse(Call call, Response response) throws IOException {
//异步请求成功之后的回调
}
});
上面代码可以看清调用异步方法 enqueue() 方法传入了 Callback 回调对象，===>然后我们去查看 enqueue() 方法的源码，由于 Call 是一个接口，所以我们得到 Call 接口的实现类 RealCall 中去查看 enqueue() 方法。
image.png
enqueue()方法总结
1 判断当前Call对象是否执行过
2 将Callback对象封装成一个AsyncCall对象
3 client.dispatchet().enqueue() —— 调用Dispatcher中的enqueue()方法
在源码图片的最后一行代码可以知道又调用 dispatcher 分发器的 enqueue() 方法，并且传入了一个 AsyncCall 对象。
那我们先看源码 AsyncCall 又是一个什么对象呢？===>
image.png
image.png
通过源码可以知道了 AsyncCall 是一个 Runnable 对象。
我们接下来看 dispatcher 分发器的 enqueue() 方法 ===>
image.png
我们先看看源码的这些常量：
image.png
看到这些常量全是在 Dispatcher 分发器对象里。我们再来看 dispatcher 分发器的 enqueue() 方法 ===>
image.png
经过上面的代码分析。是通过线程池去执行这个 Call 的。我们再去 executorService() 线程池的源码去看看是这么一个执行流程的？ ===>
image.png
可以知道 executorService() 只是得到了线程池对象，然后调用 execute() 这个方法去执行这个异步请求线程，由于它是一个线程池，所以就会调用每个子线程的 run() 方法
image.png
也就是调用 AsyncCall 的 run() 方法。接下来就去看看 AsyncCall 的 run() 方法 ===>
image.png
发现 AsyncCall 中并没有 run() 方法。接下去看看它的夫类 NamedRunnable 中有没有 run() 方法？===>
image.png
在 NamedRunnable 有 run() 方法，只不过只是调用了本身的抽象方法 execute() ，具体还得到他的实现类 AsyncCall 中的 execute() 方法去查看 ===>
image.png
通过上面源码我们终于知道 Callback 回调对象的两个回调方法 onFailure()和onResponse() 为什么是在子线程中执行的了。最后我们就该看看最后一句代码了,我们到源码中去 ===>
image.png
这样我们就完整的执行了一个异步请求了。
最后我们再总结下异步请求：
1 创建OkHttpClient对象
2 创建Request对象
3 通过OkHttpClient对象和Request对向构出Call对象
4 执行Call对象的enqueue()方法=>通过Callback拿到回调。
