okhttp源码大解析

一般的，我们都这样使用okhttp：

一步步来解析：

构造者模式就不说了，okhttp最帅的实现应该就是Interceptor了。

又是一个list添加，估计着跟retrofit的思想是一样的，肯定是到时候一个个进行解析，经过顺藤摸瓜，最后找到这么个地方：

眼前一亮，看名字是获取网络请求的返回值调用链！

果不其然！execute就是我们执行同步请求的时候所调用的方法！那么简单分析下同步执行的步骤：

captureCallStackTrace，看名字是暴力夺取栈信息，

这里没啥用，等到后面看看retryInterceptor干了啥再分析

Timeout是超时相关设置，

可以看到，当超时的时候，直接取消请求

从ScheduleTimeout可以看到是设置超时时间，最后是用AsyncTimeout进行锁的唤醒，从WatchDog可以看到，在等待超时后，就取消请求

那么接着进行同步请求的分析，接下来看okhttp重要的一个类：Dispatcher

将正在进行的请求放入到runningSyncCalls，可以看出来，这个是线程安全的。

这里，第一个是在后面排队的异步请求队列，第二个是正在进行异步请求的队列，第三个是正在进行同步请求的队列。

在该类的成员变量中看到，默认的最大请求数是64，每个host最大请求数是5。

那么逻辑清晰了，在请求的时候，okhttp会将我们正在进行的网络请求放到队列中，然后一个个拿出来进行请求。

再看执行网络请求的这个方法：

真正执行的就是这个RealInterceptorChain了，然后这里需要注意下，index的地方，它变成了index+1，而我们一开始执行的时候，这个地方的值是0，不妨大胆假设一下，这里是不是一个递归调用？

随意打开一个Interceptor的实现类，可以看到：

果然，这里再次执行了proceed方法，也就是说，会遍历执行所有的interceptor，然后根据所有的返回值组成response，怪不得叫chain。。。

从同步请求的执行中，可以看到，在finally中，执行了dispatcher.finish，

可以看到，最后又执行promoteAndExecute，目的是确定下还有没有未执行的网络请求，将其完成掉。

我们看到在运行代码的过程中，不断得有eventlistener冒出来，看看这个是啥？

EventListener：在执行网络请求时，可以在各个步骤执行的时候进行回调，帮助我们分析网络请求的执行情况：

具体像这样继承EventListener即可：

第一个请求执行过程如下：

由日志可见，第二次再执行请求时省掉了连接的过程，大大提升了速度

 

同步请求完了再看异步请求代码

还是执行的dispatcher的enqueue

不出所料，一个个将异步请求拿出来用AsyncCall进行包装，然后进行访问，

那么为什么要用AsyncCall进行壳包装呢？

Async其实就是一个个Runnable，具体这里的run方法在哪里执行需要继续往下

执行的是addWorker这个方法，继续深入：

从这里我们可以看到，将Async包装成一个Worker，并且新建一个线程去执行Async的execute方法（也就是run方法），那么最终执行的还是execute方法，也就是同步请求所执行的方法，只不过将结果以onresponse的方法回调给了我们调用端而已。

那么整个流程至此就结束了，下面一篇着重解析各大interceptor