一般的,我们都这样使用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