OkHttp 异步请求 源码分析

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拿到回调。