--- theme: juejin highlight: androidstudio --- ## 前言本人待在一家普通公司很多年了。做着一些非常普通的项目。一直知道IT行业，不是在学习的路上，就是在被淘汰的路上。有一颗进大厂的心，想寻找有梦想的兄弟，一起进阶学习，让我们的孤独少一些。[这是我14-19年的历程](https://mp.weixin.qq.com/s?__biz=MzAwMDA3MzU2Mg==&mid=2247483667&idx=1&sn=1a575ea2c636980e5f4c579d3a73d8ab&chksm=9aefcb26ad98423041c61ad7cbad77f0534495d11fc0a302b9fdd3a3e6b84605cad61d192959&mpshare=1&scene=23&srcid=0916eztl3d9F0cUEh0Vbhve0&sharer_sharetime=1631783632677&sharer_shareid=10d2c36e89d3882cf3b61dcbb9ee6d3c#rd)，也是[开源控件ShadowLayout（star2.2k）](https://github.com/lihangleo2/ShadowLayout)作者 19后我觉得T型发展很重要，期间学会了web开发，后端入门，以及简单学习了unity。但最近收到很多大厂的内推，和一些19年的小伙伴都进大厂了给了我很大触发，为什么！？为什么我差一步要放弃呢。从9月开始，我回头认真收拾Android知识，及用最通俗的白话文去理解他们，并整理一份全面的面试质料。这次我一定不会输。如果你和我有共同目标，一起放手去干吧。这是我的Android交流群：209010674。如果你需要的话。 ## 一、OkHttp简单介绍电视剧里一般能成为大侠，都从一本简单的武功秘籍开始。那我们先来看段简单的代码一个简单OkHttp的get请求。 ```java //创建OkHttpClient对象 OkHttpClient okHttpClient = new OkHttpClient.Builder() .readTimeout(10, TimeUnit.SECONDS) .writeTimeout(10,TimeUnit.SECONDS) //添加一个自定义的网络日志拦截器 .addInterceptor(new HttpLogInterceptor()) .build(); //创建网络请求对象Request对象及配置参数 Request request = new Request.Builder() .url("url") .header("headKey","headValue") .get() .build(); //进行网络请求 Call call = okHttpClient.newCall(request); call.enqueue(new Callback() { @Override public void onFailure(Call call, IOException e) {} @Override public void onResponse(Call call, Response response) throws IOException {} }); ``` 想必这些大家都非常的清楚，那怎么让这些印在脑海里呢，还不用死记硬背呢，接下来看看下面这张图（这里借用了别的博主一张图。觉得他比喻成快递行业很形象，接下来会以我的思路去讲解）： ![75ac96d529294fb79f825abe4e22aea4_tplv-k3u1fbpfcp-watermark.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6d20565d770c44709ea4b4468e7181d9~tplv-k3u1fbpfcp-watermark.image?) 这里用退货的比喻加上快递员形容的很形象。从这里再加上OkHttp的简单请求，我们很容知道有哪些类： - OkHttpClient：进入快递点，构建OkHttpClient对象 - Request：网络请求参数配置，就像寄快递填快递单号，才知道用什么快递，寄送到哪里去 - Call：快递小哥的角色 - Callback：网络回调，相当于，你告诉了他电话号码，等发货成功或丢失都会回调告诉你 - enqueue：使用异步方法进行网络请求。则相当于，快递小哥进行了货物运送 ## 二、OkHttpClient 看到OkHttpClient.Builder就知道是建筑者模式，也有人称之为是生成器模式。看下源码就知道了，我知道大家都不喜欢看代码，那就来张图片吧（参数太多，就截前面几个。反正我也知道大家不想看） ![1.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/473331d3045340ab90a707039f44775c~tplv-k3u1fbpfcp-watermark.image?) 参数实在太多，这也是为什么用建造者模式的原因。比如我们定义一个方法，方法有10个参数，那么我们调用这个方法时，要严格按照方法里参数的类型和顺序去调用，真的比较麻烦。使用建造者模式，要传参只需要点一下，不点的话就使用默认值。\ 这里介绍几个参数： - Dispatcher：调度器 - List interceptors：拦截器 - List networkInterceptors：网络拦截器 - int readTimeout：读取的超时时间先别管他们是干嘛的，后面会介绍。这里只要有个概念就行了。 ## 三、Request 看到 Request.Builder也是建筑者模式，从上面简单的get请求，就知道他是用来网络请求的配置参数，那么接下来介绍几个主要参数： - .url("url")：请求的网络url - .header("key","value")：头部参数，一般登录者的token都会放在这里 - .get()：确定是get请求 **题外话:** 当你想自己封装一个OkHttp网络请求，你越把细节搞清楚，越能封装的好用，这里稍微提下header - 我们经常会提到断点续传和下载，其实就是利用了header ```java // 通过以下设置，这里currentLength就是你已经下载的文件length .header("RANGE", "bytes=" + currentLength + "-"); // 然后在下载文件流里使用true，就能达到断点下载了。不使用true就是从新下载。 fos = new FileOutputStream(file, true); ``` - 网络缓存 ```java //1、 // 有网络的时候的在线缓存 // temp 在线缓存时间， // 场景：比如并发量大的项目，而且是首页banner不长换的，那么获取banner这个接口的数据 // 会被缓存下来。比如temp = 3600，那么在接下1小时都会读取缓存数据 .header("Cache-Control", "public, max-age=" + temp) //2、 // 无网络时的离线缓存 // 场景：很多新闻类的app，当没有网络打开时，还是会显示上一次打开的数据 .header("Cache-Control", "public, only-if-cached, max-stale=" + temp) ``` 这里提到这吧，毕竟是源码分析，跑题了。 ## 四、Call call 就是我们之前讲的“快递小哥”，看源码Call是个接口，我们从newCall点进去，其实是生成了Call接口的实现类RealCall ```java public Call newCall(Request request) { return new RealCall(this, request, false); } ``` 看看Call接口，我们就知道它的具体作用，老样子，上图片。看到图片后，我们就知道，它其实就是处理网络请求的方法和网络请求的一些状态。 ![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a2c5ee7b6af24c93a60613009b254fb7~tplv-k3u1fbpfcp-watermark.image?) ## 五、异步发送请求 RealCall.enqueue ### 5.1、call.enqueue 这里就是异步请求，相信大家都知道这段代码啥意思 ```java call.enqueue(new Callback() { @Override public void onFailure(Call call, IOException e) { } @Override public void onResponse(Call call, Response response) throws IOException { } }); ``` 点进**enqueue**，咋一看，并不复杂 ```java public void enqueue(Callback responseCallback) { synchronized(this) { //executed：中文翻译为已执行的。从代码可以看出这里是防止一次调用进行多次请求 if (this.executed) { throw new IllegalStateException("Already Executed"); } this.executed = true; } this.captureCallStackTrace(); this.client.dispatcher().enqueue(new RealCall.AsyncCall(responseCallback)); } ``` **this.captureCallStackTrace();** capture：捕捉\ StackTrace：堆栈踪迹\ 从字面上大概能猜想到这个方法是捕捉请求的堆栈踪迹的继续点进去 ```java private void captureCallStackTrace() { Object callStackTrace = Platform.get().getStackTraceForCloseable("response.body().close()"); this.retryAndFollowUpInterceptor.setCallStackTrace(callStackTrace); } ``` 从代码可以看到，他获取当前接口的堆栈踪迹对象放进了**retryAndFollowUpInterceptor**，拦截器里。那么接下来我们看看retryAndFollowUpInterceptor拦截器。 ### 5.2、RetryAndFollowUpInterceptor 我们都知道okHttp有拦截器，这里则是使用设计模式里的责任链模式。**责任链模式**：是一种处理请求的模式，让多个处理器都有机会处理该请求。在这里拦截器只处理与自己相关的业务逻辑。 **题外话：** 要实现拦截器只要继承Interceptor类，并重写intercept(Chain chain)拦截方法就行了，最后在okHttpClient.addInterceptor()下就好了。比如开发中，登录成功后，会有登录者token,此时就可以使用拦截器，为以后每个接口头部参数添加token。再比如，开发测试中，我们可以打印每一个网络请求的详细情况。比如实现一个网络日志打印拦截器，伪代码如下： ```java @Override public synchronized okhttp3.Response intercept(Chain chain) throws IOException { Request request = chain.request(); long startTime = SystemClock.elapsedRealtime(); okhttp3.Response response = chain.proceed(chain.request()); long endTime = SystemClock.elapsedRealtime(); long duration = endTime - startTime; //url String url = request.url().toString(); log("┌───────Request Start────────────────────────────"); log("请求方式 -->>" + request.method() + ": " + url); log("请求方式 -->>"+"Time:" + duration + " ms"); //headers Headers headers = request.headers(); if (null != headers) { for (int i = 0, count = headers.size(); i < count; i++) { if (!headerIgnoreMap.containsKey(headers.name(i))) { log("请求头部 -->>" + headers.name(i) + ": " + headers.value(i)); } } } //param RequestBody requestBody = request.body(); String paramString = readRequestParamString(requestBody); if (!TextUtils.isEmpty(paramString)) { log("请求参数 -->>" + paramString); } //response ResponseBody responseBody = response.body(); String responseString = ""; if (null != responseBody) { if (isPlainText(responseBody.contentType())) { responseString = readContent(response); } else { responseString = "other-type=" + responseBody.contentType(); } } log("请求返回 -->>" + responseString); log("└───────Request End─────────────────────────────" + "\n" + "-"); return response; } ``` 以上拦截器无需看太仔细，你只要知道在拦截方法里，你可以获得Request和ResponseBody，那还有什么不能做的呢。哎呀，又啰嗦了。跑题了。回到我们的主题上。 RetryAndFollowUpInterceptor就是负责重试，和请求重定向的的拦截器，在这里用到StreamAllocation，主要是获取网络连接的RealConnection，如果需要重定向就release，关闭套接字等资源，开启重试和重定向的“新”的请求。我们继续往里看其重写的intercept方法: ```java public Response intercept(Chain chain) throws IOException { //获取请求体 Request request = chain.request(); //这个StreamAllocation是个核心类。这里简单介绍，后面会讲 //参数1：OkHttpClient 的连接池 //参数2：请求地址 //参数3：堆栈追踪的对象 //StreamAllocation的作用： //1、处理不同Connection的复用功能，协议流的可复用性和ConnectionPool连接池的处理 //2、给请求HttpCodec流处理输入输出 //3、StreamAllocation关联了一个Call请求的所有周期，判断Call请求的Connection是否被占用，其他Call能不能使用该Connection this.streamAllocation = new StreamAllocation(this.client.connectionPool(), this.createAddress(request.url()), this.callStackTrace); //重定向次数 int followUpCount = 0; Response priorResponse = null; //这里的条件一直为true，除非调用 //call.cancle()，此方法里调用了-->retryAndFollowUpInterceptor.cancel()-->canceled = true（进而条件为false,不会往下进行）。这里还调用了streamAllocation.cancel();代码继续追踪下去，最终是调用了-->codecToCancel.cancel();其实就是调用了RealConnection的取消方法 while(!this.canceled) { Response response = null; boolean releaseConnection = true; try { //把网络返回响应体Response拦截下来 response = ((RealInterceptorChain)chain).proceed(request, this.streamAllocation, (HttpCodec)null, (RealConnection)null); //释放Connection的标识，在try catch后面的finally里，在这里是不释放 releaseConnection = false; } catch (RouteException var13) { //recover的其实就是判断是否需要重定向，比如你把接口都写错了，就不需要了。可以理解为里面是判断这个错造成的原因 if (!this.recover(var13.getLastConnectException(), false, request)) { throw var13.getLastConnectException(); } releaseConnection = false; continue; } catch (IOException var14) { boolean requestSendStarted = !(var14 instanceof ConnectionShutdownException); if (!this.recover(var14, requestSendStarted, request)) { throw var14; } releaseConnection = false; continue; } finally { if (releaseConnection) { this.streamAllocation.streamFailed((IOException)null); this.streamAllocation.release(); } } //第一次循环priorResponse 必定为空。那么response则是try{}里获取的放入了streamAllocation的response if (priorResponse != null) { //如果是第2次及以后到达这里的，则是以先前的priorResponse生成新的response。这里可以理解为就是要重定向的response。其实在这个方法的最后，是赋值了的priorResponse = response;所以还是第一次放入streamAllocation的response，也就是说这里只要条件达到，那么重定向会一直循环下去 response = response.newBuilder().priorResponse(priorResponse.newBuilder().body((ResponseBody)null).build()).build(); } //followUpRequest下方特别拎出来展示了源码；其实就是判断是否有重连或者重定向条件的response，比如这里获取code码等条件进行判断 Request followUp = this.followUpRequest(response); //对返回需要重试或重定向的Request 进行判断，如果为空，说明这次请求是成功的，那么返回当前的response if (followUp == null) { if (!this.forWebSocket) { this.streamAllocation.release(); } return response; } //关闭当前response资源，内部其实调用的是Util.closeQuietly(this.source());source其实就是BufferedSource，看到这些我们就可以联想到流和字节资源 Util.closeQuietly(response.body()); //每一次进行重试或重定向都++ ++followUpCount; //当次数超过20次时，失败 if (followUpCount > 20) { this.streamAllocation.release(); throw new ProtocolException("Too many follow-up requests: " + followUpCount); } //以下都是达不到重试或重定向的条件，那么我们把错误抛出去 if (followUp.body() instanceof UnrepeatableRequestBody) { this.streamAllocation.release(); throw new HttpRetryException("Cannot retry streamed HTTP body", response.code()); } if (!this.sameConnection(response, followUp.url())) { this.streamAllocation.release(); this.streamAllocation = new StreamAllocation(this.client.connectionPool(), this.createAddress(followUp.url()), this.callStackTrace); } else if (this.streamAllocation.codec() != null) { throw new IllegalStateException("Closing the body of " + response + " didn't close its backing stream. Bad interceptor?"); } request = followUp; priorResponse = response; } this.streamAllocation.release(); throw new IOException("Canceled"); } ``` **followUpRequest方法伪代码：** ```java private Request followUpRequest(Response userResponse) throws IOException { if (userResponse == null) { throw new IllegalStateException(); } else { ... switch(responseCode) { case 307: case 308: ... return null; case 300: case 301: case 302: case 303: if (!this.client.followRedirects()) { return null; } else { String location = userResponse.header("Location"); if (location == null) { return null; } else { ... return requestBuilder.url(url).build(); } } } case 401: return this.client.authenticator().authenticate(route, userResponse); case 407: ... return this.client.proxyAuthenticator().authenticate(route, userResponse); case 408: if (userResponse.request().body() instanceof UnrepeatableRequestBody) { return null; } return userResponse.request(); default: return null; } } } ``` ### 5.3、StreamAllocation StreamAllocation是在重试和重定向拦截器RetryAndFollowUpInterceptor里初始化的。其实这个类主要是在拦截器ConnectInterceptor发起真正网络请求时用到，大致我们可以看成网络请求优化，先在这里了解这个类更容易理解全文。在了解这个类的时候，我们来看看题外话（兄弟们，这是我查阅大量资料找来的题外话）。这个可是划重点的知识点，（指黑板） - http2.0 使用多路复用的技术，多个 stream 可以共用一个 socket 连接。每个 tcp连接都是通过一个 socket 来完成的，socket 对应一个 host 和 port，如果有多个stream(即多个 Request) 都是连接在一个 host 和 port上，那么它们就可以共同使用同一个 socket ,这样做的好处就是可以减少TCP的一个三次握手的时间。 ``` 在OkHttp里负责连接的就是RealConnection，上文也说道了，我们取消请求可以用call.cancle()。其实最终就是调用了StreamAllocation里的cancle()，也就是调用了realConnection.cancle() ``` - Http通信执行网络**请求Call**，需要在连接上建立新的**流Stream**（OkHttp里面的流是HttpCodec)执行，我们将**StreamAllocation看做是桥梁**，作用是为一次请求寻找**连接**并建立**流**，进而完成通信那么接下来我们来看看StreamAllocation的伪代码。 ```java public final class StreamAllocation { public final Address address; private Route route; private final ConnectionPool connectionPool; private final Object callStackTrace; private final RouteSelector routeSelector; private int refusedStreamCount; private RealConnection connection; private boolean released; private boolean canceled; private HttpCodec codec; public HttpCodec newStream(OkHttpClient client, boolean doExtensiveHealthChecks) { ... RealConnection resultConnection = this.findHealthyConnection(connectTimeout, readTimeout, writeTimeout, connectionRetryEnabled, doExtensiveHealthChecks); //建立OkHttp连接流，点进去其实new的是一个Http2Codec HttpCodec resultCodec = resultConnection.newCodec(client, this); } //寻找一个健康的RealConnection, private RealConnection findHealthyConnection(int connectTimeout, int readTimeout, int writeTimeout, boolean connectionRetryEnabled, boolean doExtensiveHealthChecks) throws IOException { while(true) { ... //findHealthyConnection其实调用了findConnection，只不过判断了是否健康 //判断RealConnection candidate是否健康.isHealthy点进去也就是判断当前socket是否自愿关闭，等健康因素 if (candidate.isHealthy(doExtensiveHealthChecks)) { return candidate; } //如果RealConnection是不健康的，那么把它当前的socket关闭资源 this.noNewStreams(); } } private RealConnection findConnection(int connectTimeout, int readTimeout, int writeTimeout, boolean connectionRetryEnabled) throws IOException { Route selectedRoute; synchronized(this.connectionPool) { if (this.released) { throw new IllegalStateException("released"); } if (this.codec != null) { throw new IllegalStateException("codec != null"); } if (this.canceled) { throw new IOException("Canceled"); } RealConnection allocatedConnection = this.connection; //如果当前赋值的this.connection不为null；且安全的话，那么返回当前RealConnection //this.connection是全局变量，第一次这里肯定为空。 if (allocatedConnection != null && !allocatedConnection.noNewStreams) { return allocatedConnection; } //1、第一次获取Connection //从连接池中获取一个可用连接。这里的路由Route传的是null,表示从当前已解析过的连接池中寻找。 Internal.instance.get(this.connectionPool, this.address, this, (Route)null); //Internal.instance.get()最终调用的是OkHttpClient的pool.get()，即连接池ConnectionPool里的get(),代码如下： // @Nullable RealConnection get(Address address, okhttp3.internal.connection.StreamAllocation streamAllocation, Route route) { // ... // for (RealConnection connection : connections) { // if (connection.isEligible(address, route)) { // 这里把connection传给了streamAllocation，我们可以当成就是赋值给我们的this.connection // streamAllocation.acquire(connection); // return connection; // } // } // return null; // } if (this.connection != null) { return this.connection; } selectedRoute = this.route; } if (selectedRoute == null) { selectedRoute = this.routeSelector.next(); } RealConnection result; synchronized(this.connectionPool) { if (this.canceled) { throw new IOException("Canceled"); } //2、第二次获取Connection //这里传入了Router,先看下Router的概念 //Router路由：来确定具体要怎么连接。一个Router包含proxy代理，ip地址和端口port。而同样的端口和同样的代理类型下有不同ip的多个Router组合 //才结合http2.0的多路复用的概念。这里一直循环this.routeSelector.next()寻找一个可复用的Connection Internal.instance.get(this.connectionPool, this.address, this, selectedRoute); if (this.connection != null) { return this.connection; } this.route = selectedRoute; this.refusedStreamCount = 0; //3、第三次获取Connection //上面2种方式都获取不到，说明当前连接池没有可复用的，多路路由里也找不到复用的，那么我们创建新的Connection result = new RealConnection(this.connectionPool, selectedRoute); this.acquire(result); } result.connect(connectTimeout, readTimeout, writeTimeout, connectionRetryEnabled); this.routeDatabase().connected(result.route()); Socket socket = null; synchronized(this.connectionPool) { //把新建的Connecttion放入到连接池中 Internal.instance.put(this.connectionPool, result); if (result.isMultiplexed()) { socket = Internal.instance.deduplicate(this.connectionPool, this.address, this); result = this.connection; } } Util.closeQuietly(socket); return result; } ... public void noNewStreams() { Socket socket; synchronized(this.connectionPool) { socket = this.deallocate(true, false, false); } //这里就是之前如果不是健康连接，找到连接套接字，并关闭资源 Util.closeQuietly(socket); } ... } ``` ### 5.4、dispatcher 说完了 this.captureCallStackTrace();再来看看this.client.dispatcher().enqueue(new RealCall.AsyncCall(responseCallback));还记得那些简单代码吗？如下： ```java public void enqueue(Callback responseCallback) { synchronized(this) { if (this.executed) { throw new IllegalStateException("Already Executed"); } this.executed = true; } this.captureCallStackTrace(); this.client.dispatcher().enqueue(new RealCall.AsyncCall(responseCallback)); } ``` 首先this.client.dispatcher()获取的是Dispatcher调度器的对象。用来调度，管理这些请求的。来看看Dispatcher，伪代码如下： ```java public final class Dispatcher { //最大请求数，意思一家快递公司有64辆车，如果还需要车，就只能等待其他车空闲了 private int maxRequests = 64; //一个主机最大允许请求数。意思前往同一城市运送快递的车辆为5量，如果还有快递要运往，只能等5量中有空闲 private int maxRequestsPerHost = 5; //线程池，懒加载即被调用时才创建 private @Nullable ExecutorService executorService; //准备队列，也就是超过了maxRequests 和 maxRequestsPerHost 的请求将被添加到这里 private final Deque readyAsyncCalls = new ArrayDeque<>(); //异步队列，也就是没超过最大请求数，将放在这里 private final Deque runningAsyncCalls = new ArrayDeque<>(); //同步队列，没超过最大请求数，将添加在这里 private final Deque runningSyncCalls = new ArrayDeque<>(); public Dispatcher(ExecutorService executorService) { this.executorService = executorService; } public Dispatcher() { } public synchronized ExecutorService executorService() { if (executorService == null) { //创建一个线程池，60秒是keepAliveTime。即线程干完活不会立即消失，有活干的时候会复用还存活的线程，性能优化 executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS, new SynchronousQueue(), Util.threadFactory("OkHttp Dispatcher", false)); } return executorService; } ... } ``` ### 5.5、this.client.dispatcher().enqueue() ```java synchronized void enqueue(AsyncCall call) { //可以看到在比较了最大请求数之后，如果超过最大请求数，加入到readyAsyncCalls里等待请求，否则加入到runningAsyncCalls进行请求。 if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) { runningAsyncCalls.add(call); executorService().execute(call); } else { readyAsyncCalls.add(call); } } ``` 接下来看看readyAsyncCalls在什么地方被执行呢？点开源码： ```java private void promoteCalls() { //如果请求数大于等于最大请求数，说明没有空闲。那readyAsyncCalls必须继续等待 if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity. //如果readyAsyncCalls自身为空，那么不需要执行，直接返回 if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote. for (Iterator i = readyAsyncCalls.iterator(); i.hasNext(); ) { AsyncCall call = i.next(); if (runningCallsForHost(call) < maxRequestsPerHost) { i.remove(); runningAsyncCalls.add(call); //最终在这里被请求。 executorService().execute(call); } if (runningAsyncCalls.size() >= maxRequests) return; // Reached max capacity. } } ``` 那么看到这里你会想promoteCalls()方法在什么时候去执行呢？让我们试想一下在什么条件下会触发他请求呢。那肯定得满足条件的时候啊，哈哈哈 - 条件1：请求数不超过最大请求数。那我们很容易想到修改最大请求数maxRequests或maxRequestsPerHost - 条件2：等到了空闲的请求路线，即runningAsyncCalls里有请求被执行完毕了点开源码也确实是在3个方法里被执行了，分别是setMaxRequests()、setMaxRequestsPerHost()和finished(AsyncCall call) ### 5.6、executorService().execute(call) 从5.5的源码我们知道，这里的call是AsyncCall，是RealCall里的内部类，初始化属性也都是RealCall里的属性，代码如下，他其实是个被命名的Runnable(意思会给这个线程setThreadName)： ```java final class AsyncCall extends NamedRunnable { //请求结果的Callback回调 private final Callback responseCallback; ... //请求地址 String host() { return originalRequest.url().host(); } //请求体 Request request() { return originalRequest; } RealCall get() { return RealCall.this; } } ``` 从5.4可以看到executorService()生成的是ThreadPoolExecutor线程池，并通过execute方法加入到workQueue工作队列中，并执行。这里是线程池的概念就略过了。直接看execute()方法 ```java public void execute(Runnable command) { if (command == null) throw new NullPointerException(); int c = ctl.get(); if (workerCountOf(c) < corePoolSize) { if (addWorker(command, true)) return; c = ctl.get(); } if (isRunning(c) && workQueue.offer(command)) { int recheck = ctl.get(); if (! isRunning(recheck) && remove(command)) reject(command); else if (workerCountOf(recheck) == 0) addWorker(null, false); } else if (!addWorker(command, false)) reject(command); } ``` 因为我们知道AsyncCall 就是runnable，其实执行的就是他里面的run方法。通过父类NamedRunnable我们知道。其实现的是NamedRunnable里定义的抽象方法execute()，并由AsyncCall 去实现，如下： ```java final class AsyncCall extends NamedRunnable { ... @Override protected void execute() { boolean signalledCallback = false; try { //通过getResponseWithInterceptorChain()获得了最终请求返回的Response Response response = getResponseWithInterceptorChain(); if (retryAndFollowUpInterceptor.isCanceled()) { signalledCallback = true; responseCallback.onFailure(RealCall.this, new IOException("Canceled")); } else { signalledCallback = true; responseCallback.onResponse(RealCall.this, response); } } catch (IOException e) { if (signalledCallback) { // Do not signal the callback twice! Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e); } else { responseCallback.onFailure(RealCall.this, e); } } finally { //不管接口成功或失败，都会将这个请求Call移除 client.dispatcher().finished(this); } } } ``` 我们看到这里都是通过getResponseWithInterceptorChain()得到Response的。那么我们看看这个方法都做了什么。 ```java Response getResponseWithInterceptorChain() throws IOException { // 可以看到这里加里很多拦截器 List interceptors = new ArrayList<>(); //添加用户自定义的拦截器 interceptors.addAll(client.interceptors()); //添加失败重试或重定向拦截器 interceptors.add(retryAndFollowUpInterceptor); //桥梁数据转换拦截器 interceptors.add(new BridgeInterceptor(client.cookieJar())); //添加缓存拦截器 interceptors.add(new CacheInterceptor(client.internalCache())); //添加连接拦截器 interceptors.add(new ConnectInterceptor(client)); if (!forWebSocket) { interceptors.addAll(client.networkInterceptors()); } interceptors.add(new CallServerInterceptor(forWebSocket)); //最后带上请求数据，通过RealInterceptorChain以及这些拦截器的作用，最终网络请求返回了我们的Response Interceptor.Chain chain = new RealInterceptorChain( interceptors, null, null, null, 0, originalRequest); return chain.proceed(originalRequest); } ``` 致此，异步请求就将完了。以上讲解的是异步请求。用的方法是call.enqueue()。同步请求是怎么样的呢？我相信你看懂了上面写的我只要放2段代码，你就焕然大悟了 ``` //同步请求够简单吧。再看看RealCall Response execute = call.execute(); ``` RealCall的execute();同步的实现方法基本和异步的AsyncCall里的实现方法一模一样 ```java @Override public Response execute() throws IOException { synchronized (this) { if (executed) throw new IllegalStateException("Already Executed"); executed = true; } captureCallStackTrace(); try { client.dispatcher().executed(this); Response result = getResponseWithInterceptorChain(); if (result == null) throw new IOException("Canceled"); return result; } finally { client.dispatcher().finished(this); } } ``` 题外话又如约而至了，**题外话：** 看到了调度器的知识，如果我们自己封装一个OkHttp该怎么取消网络请求呢？\ 这里放上一段我之前封装的取消网络请求方法： ```java //tag取消网络请求 public void cancleOkhttpTag(String tag) { //封装，当然okHttpClient要使用单例咯，获取调度器。 Dispatcher dispatcher = okHttpClient.dispatcher(); synchronized (dispatcher) { //dispatcher.queuedCalls()获得的就是readyAsyncCalls for (Call call : dispatcher.queuedCalls()) { //获取到Request，当然在请求网络的时候，okHttp带了个点tag的参数。这个时候传入的tag也就和那个tag对比 if (tag.equals(call.request().tag())) { call.cancel(); } } //看runningCalls也知道获取到什么了吧 for (Call call : dispatcher.runningCalls()) { if (tag.equals(call.request().tag())) { call.cancel(); } } } } ``` ## 六、拦截器前面为了源码分析更清楚已经把RetryAndFollowUpInterceptor放在5.2小结讲过了。这里我们看到了getResponseWithInterceptorChain()方法里，有那么多拦截器。接下来我们一个一个看吧： ### 6.1、BridgeInterceptor 其实我们运用OkHttp进行网络请求，是作者在内部高度封装，简化我们的操作。实现了真正的网络请求。先来简单说下桥接拦截器的概念和作用： - 把应用请求转换成网络请求（就是添加网络请求必要的响应头，在web上按F12，选中network监听网络可以看到网络请求带很多头部信息） - 把网络响应转换成应用响应（就是转换成对用户友好的响应，支持gzip压缩也有提高性能的意思） - 因为Cookie也在头部信息里，系统是个空实现，如果自定义cookieJar，这里也算成一个作用吧分辨用户信息 ```java //为什么说他是空实现呢，首先BridgeInterceptor里有段代码是： List cookies = cookieJar.loadForRequest(userRequest.url()); //我们看看系统的cookies得到的是什么呢？首先OkHttpClient里的默认值是cookieJar = CookieJar.NO_COOKIES; //再来看CookieJar接口loadForRequest默认实现是 CookieJar NO_COOKIES = new CookieJar() { @Override public void saveFromResponse(HttpUrl url, List cookies) { } @Override public List loadForRequest(HttpUrl url) { //没看错这里就是一个空数组 return Collections.emptyList(); } }; ``` 现在来看看我们的BridgeInterceptor的源码： ```java public final class BridgeInterceptor implements Interceptor { private final CookieJar cookieJar; public BridgeInterceptor(CookieJar cookieJar) { this.cookieJar = cookieJar; } @Override public Response intercept(Chain chain) throws IOException { Request userRequest = chain.request(); Request.Builder requestBuilder = userRequest.newBuilder(); //首先获取到用户应用请求的请求体 RequestBody body = userRequest.body(); if (body != null) { MediaType contentType = body.contentType(); if (contentType != null) { //添加头部信息Content-Type，请求类型 requestBuilder.header("Content-Type", contentType.toString()); } long contentLength = body.contentLength(); //对contentLength进行判断用哪种请求解析方式，Content-Length或Transfer-Encoding if (contentLength != -1) { requestBuilder.header("Content-Length", Long.toString(contentLength)); requestBuilder.removeHeader("Transfer-Encoding"); } else { requestBuilder.header("Transfer-Encoding", "chunked"); requestBuilder.removeHeader("Content-Length"); } } //如果头部没有添加请求的主机站点，添加上 if (userRequest.header("Host") == null) { requestBuilder.header("Host", hostHeader(userRequest.url(), false)); } //保持请求长连接。这里的意思是tcp连接要经过三次握手，四次挥手。长连接可以理解为多次网络请求可以减少握手和挥手的次数。不但能减少耗时而且还能提高性能 if (userRequest.header("Connection") == null) { requestBuilder.header("Connection", "Keep-Alive"); } //接收gzip压缩。就像我们传大型文件，压缩完是不是传递快些，占用的资源少 boolean transparentGzip = false; if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) { transparentGzip = true; requestBuilder.header("Accept-Encoding", "gzip"); } List cookies = cookieJar.loadForRequest(userRequest.url()); if (!cookies.isEmpty()) { //Cookie：分辨用户信息 requestBuilder.header("Cookie", cookieHeader(cookies)); } //请求的用户信息，在什么操作系统，或什么浏览器等用户平台上 if (userRequest.header("User-Agent") == null) { requestBuilder.header("User-Agent", Version.userAgent()); } //经过以上这些操作，将用户请求转换成我们的网络请求 Response networkResponse = chain.proceed(requestBuilder.build()); HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers()); Response.Builder responseBuilder = networkResponse.newBuilder() .request(userRequest); if (transparentGzip && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding")) && HttpHeaders.hasBody(networkResponse)) { GzipSource responseBody = new GzipSource(networkResponse.body().source()); Headers strippedHeaders = networkResponse.headers().newBuilder() .removeAll("Content-Encoding") .removeAll("Content-Length") .build(); responseBuilder.headers(strippedHeaders); responseBuilder.body(new RealResponseBody(strippedHeaders, Okio.buffer(responseBody))); } //经过以上操作最终生成对用户友好的请求响应 return responseBuilder.build(); } ... } ``` ### 6.2、ConnectInterceptor 这个拦截器非常简洁，主要是调用StreamAllocation，这个类我们已经在“5.3、StreamAllocation”讲过了，而大部分工作都让StreamAllocation给做了 ```java public final class ConnectInterceptor implements Interceptor { public final OkHttpClient client; public ConnectInterceptor(OkHttpClient client) { this.client = client; } @Override public Response intercept(Chain chain) throws IOException { RealInterceptorChain realChain = (RealInterceptorChain) chain; //获取网络请求的请求体 Request request = realChain.request(); //获取我们核心的网络请求类StreamAllocation，也是在RetryAndFollowUpInterceptor中初始化的 StreamAllocation streamAllocation = realChain.streamAllocation(); boolean doExtensiveHealthChecks = !request.method().equals("GET"); //调用streamAllocation的newStream()方法。大家可以去看下5.3的StreamAllocation，这个方法就是找findHealthConnect, //就是多路复用，3次寻找，有复用的Connection就复用，没有的话就新建，并且把新建的加入连接池ConnectionPool中 HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks); RealConnection connection = streamAllocation.connection(); //交给下个拦截器使用 return realChain.proceed(request, streamAllocation, httpCodec, connection); } } ``` **题外话(重点)：** 可能这里大家会有点懵逼，包括我自己，为什么RetryAndFollowUpInterceptor中已经进行了网络请求，ConnectInterceptor怎么还来一遍，为什么RetryAndFollowUpInterceptor里的网络请求不多路复用呢？别急，我们直接看一张网络请求拦截器的图： ![1.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8692efff8cbd45dfb3d1b9ac1b9670df~tplv-k3u1fbpfcp-watermark.image?) 从这张图看，我们来总结下：\ 首先是从左边开始**进行网络请求的方向** - 首先是进入到RetryAndFollowUpInterceptor拦截器，但是我们看源码，知道这个拦截器是等Response回来之后才知道是重试还是重定向，在请求的时候是不会走这里的拦截的 - 其次进入BridgeInterceptor拦截器，把我们的用户请求，添加头部信息，变成真正的网络请求 - CacheInterceptor拦截器后面会讲，这里先理清这个逻辑 - 最后进入到ConnectInterceptor拦截器里，调用StreamAllocation的newstream，寻找健康的RealConnection。进行真正的网络请求到这里网络请求就结束了，来看看右边的**网络响应Response返回的方向** - 首先是在ConnectInterceptor返回网络请求的Response给下一级拦截器，这里说的下一级，肯定就是CacheInterceptor了。 - 如果配置了缓存走完后就到了BridgeInterceptor里，将网络返回的Response处理后返回友好的用户Response给用户。 - 最后到了Response到了RetryAndFollowUpInterceptor拦截器里，如果请求是成功的，那么就会直接返回Response，无限循环停止。否知就会判断是否要重试或者重定向，满足条件后，再次进行网络请求。大概就是这样的流程了。本小节的题外话到此为止了，是不是有种没听够的感觉 ### 6.3、CacheInterceptor 之前在"三、Request"部分讲了我们通过配置头部参数head可以达到在线缓存和离线缓存2种方式，接下来来看看我们的缓存拦截器，伪代码如下： ```java public final class CacheInterceptor implements Interceptor { //使用DisLruCache封装的一个Cache.Cache在OkHttp源码的okhttp3包下，不在cache包下 final InternalCache cache; public CacheInterceptor(InternalCache cache) { this.cache = cache; } @Override public Response intercept(Chain chain) throws IOException { //用当前请求去获取缓存的Response,点进去可以发现其实用的是request.url作为key获取的 Response cacheCandidate = cache != null ? cache.get(chain.request()) : null; long now = System.currentTimeMillis(); //缓存策略，它将确定是使用网络还是缓存，还是两者都使用 CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get(); Request networkRequest = strategy.networkRequest; Response cacheResponse = strategy.cacheResponse; if (cache != null) { cache.trackResponse(strategy); } //如果缓存Response不为null，但是缓存策略的结果是缓存不适用，那么关闭缓存 if (cacheCandidate != null && cacheResponse == null) { closeQuietly(cacheCandidate.body()); } //如果网络和缓存都为null，那么我们直接返回code504，超时 if (networkRequest == null && cacheResponse == null) { return new Response.Builder() .request(chain.request()) .protocol(Protocol.HTTP_1_1) .code(504) .message("Unsatisfiable Request (only-if-cached)") .body(Util.EMPTY_RESPONSE) .sentRequestAtMillis(-1L) .receivedResponseAtMillis(System.currentTimeMillis()) .build(); } //如果网络为null，缓存有效的话，那使用缓存 if (networkRequest == null) { return cacheResponse.newBuilder() .cacheResponse(stripBody(cacheResponse)) .build(); } Response networkResponse = null; try { networkResponse = chain.proceed(networkRequest); } finally { //如果我们在I/O其他地方崩溃不要泄露缓存，及时关闭它 if (networkResponse == null && cacheCandidate != null) { closeQuietly(cacheCandidate.body()); } } if (cacheResponse != null) { //返回HTTP_NOT_MODIFIED304的意思是服务器判断此接口数据是否更新过，没更新过的话，那么使用缓存 //否则关闭缓存 if (networkResponse.code() == HTTP_NOT_MODIFIED) { Response response = cacheResponse.newBuilder() .headers(combine(cacheResponse.headers(), networkResponse.headers())) .sentRequestAtMillis(networkResponse.sentRequestAtMillis()) .receivedResponseAtMillis(networkResponse.receivedResponseAtMillis()) .cacheResponse(stripBody(cacheResponse)) .networkResponse(stripBody(networkResponse)) .build(); networkResponse.body().close(); // Update the cache after combining headers but before stripping the // Content-Encoding header (as performed by initContentStream()). cache.trackConditionalCacheHit(); cache.update(cacheResponse, response); return response; } else { closeQuietly(cacheResponse.body()); } } //使用网络响应 Response response = networkResponse.newBuilder() .cacheResponse(stripBody(cacheResponse)) .networkResponse(stripBody(networkResponse)) .build(); if (cache != null) { if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) { // 将数据缓存到本地缓存到本地 CacheRequest cacheRequest = cache.put(response); return cacheWritingResponse(cacheRequest, response); } if (HttpMethod.invalidatesCache(networkRequest.method())) { try { cache.remove(networkRequest); } catch (IOException ignored) { // The cache cannot be written. } } } return response; } ... } ``` 这里大致总结以下： - 读取候选缓存。 - 根据候选缓存创建缓存策略。 - 根据缓存策略，如果不进行网络请求，而且没有缓存数据时，报错返回错误码 504。 - 根据缓存策略，如果不进行网络请求，缓存数据可用，则直接返回缓存数据。 - 缓存无效，则继续执行网络请求。 - 通过服务端校验后，缓存数据可以使用（返回 304），则直接返回缓存数据，并且更新缓存。 - 读取网络结果，构造 response，对数据进行缓存。这里其实有很多知识点，不懂的地方我们可以去好好学习下；[DiskLruCache完全解析，可以看这篇文章](https://blog.csdn.net/guolin_blog/article/details/28863651)。说了缓存拦截器这么多，为什么我们在使用OkHttp的时候都没有使用过缓存呢，因为这里和CookieJar也是个空实现，看下面代码： ```java //首先在RealCall里，添加了 interceptors.add(new CacheInterceptor(client.internalCache())); //然后来到OkHttpClient里： InternalCache internalCache() { //这个cache是在new OkHttpClient().cache() 传入的，显然，用的时候大家都没定义过 //cache为空的话，最终就会用internalCache，其实这个变量就是Builder里传入的。没传默认为空 return cache != null ? cache.internalCache : internalCache; } //都为空的情况下，来看看缓存拦截器的一段代码，client.internalCache()为null，那么下方的cache就是null Response cacheCandidate = cache != null ? cache.get(chain.request()) : null; ``` 又到了**题外话**的环节了：\ 还记得我们之前提过的在线缓存和离线缓存吗？代码如下 ```java //在设置之前我们还要提供一个缓存文件就是初始化我们的OkHttpClient的时候使用.cache() //这是我封装EasyOk时的代码 //设置缓存文件路径，和文件大小 .cache(new Cache(new File(Environment.getExternalStorageDirectory() + "/okhttp_cache/"), 50 * 1024 * 1024)) //1、 // 有网络的时候的在线缓存 // temp 在线缓存时间， // 场景：比如并发量大的项目，而且是首页banner不长换的，那么获取banner这个接口的数据 // 会被缓存下来。比如temp = 3600，那么在接下1小时都会读取缓存数据 .header("Cache-Control", "public, max-age=" + temp) //2、 // 无网络时的离线缓存 // 场景：很多新闻类的app，当没有网络打开时，还是会显示上一次打开的数据 .header("Cache-Control", "public, only-if-cached, max-stale=" + temp) ``` 注意我们使用头部文件去设置了缓存，其实不管是Request还是Response都使用了一个类，CacheControl。这个类里有一个方法，是获取头部信息Cache-Control里的设置的 ```java //代码还是比较长，还是伪代码吧 public static CacheControl parse(Headers headers) {} ``` 知道这些以后，除了在头部信息设置之外，我们还可以利用拦截器，获取到Request进行设置，看段代码就明白了了 ```java Request request = new Request.Builder() .cacheControl(new CacheControl.Builder() .onlyIfCached() .build()) .url("http://publicobject.com/helloworld.txt") .build(); ``` 还记得CacheIntereptor里的CacheStrategy吗，即是缓存策略。OkHttp有2种缓存策略： **强制缓存：** 需要服务器参与，服务器返回时间标识，如果时间不失效，则利用缓存。强制缓存有2个标识 - Expires：Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。到期时间是服务端生成的，客户端和服务端的时间可能有误差。 - Cache-Control：Expires有个时间校验的问题，所有HTTP1.1采用Cache-Control替代Expires。 **对比缓存：** 需要服务器参与，服务器返回资源是否被修改，未修改返回code304使用缓存，否则不使用。对比缓存也有2个标识 - Last-Modified：表示资源上次修改的时间。 - ETag：是资源文件的一种标识码，当客户端发送第一次请求时，服务端会返回当前资源的标识码。如果再次请求，不同标识资源被修改在这里我们大致对缓存策略有个了解吧 ## 七、ConnectionPool连接池我们都知道网络请求要经过3次握手和4次挥手，为了加快网络请求访问速度和提高性能，这个时候就要用到Http2.0的多路复用了。我们可以在一个请求head里添加keepalive，从而这次请求的RealConnection可以被复用并加入到ConnectionPool连接池中。 ```java //ConnectionPool是用Deque保存RealConnection的 private final Deque connections = new ArrayDeque<>(); //Okhttp支持5个并发KeepAlive，默认链路生命为5分钟(链路空闲后，保持存活的时间)，连接池有ConectionPool实现，对连接进行回收和管理。 public ConnectionPool() { this(5, 5, TimeUnit.MINUTES); } ``` 我们来看下他是怎么加入到Deque里的 ```java void put(RealConnection connection) { assert (Thread.holdsLock(this)); if (!cleanupRunning) { cleanupRunning = true; //如果清除闲置的线程还没走完则不运行这段代码，否则主动调用一次清除闲置线程 executor.execute(cleanupRunnable); } //加入到Deque里 connections.add(connection); } ``` 好了到这里大概就完结了。不会再有题外话了。相信，你从头看下来会跟我有同样的感觉，不再害怕面试官问你OkHttp源码了。感谢你的浏览，和我一起并肩作战吧！