OKHttp学习(一)—OKHttp的工作原理this.tag = builder.tag != null ? buil

this.tag = builder.tag != null ? builder.tag : this; }

可以看到Request也是通过建造者模式创建的，在这里配置了url、请求头等信息。

OKHttp的请求

在上面OKHttpClient和Request创建好之后，就开始发起HTTP请求了。OkHttp中请求方式分为同步请求（client.newCall(request).execute() ）和异步请求（client.newCall(request).enqueue()）两种，其中同步请求和一部请求的区别就是同步请求会阻塞当前线程，一部请求会放到线程池中执行。

public Call newCall(Request request) { return RealCall.newRealCall(this, request, false /* for web socket */); }

static RealCall newRealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) { // Safely publish the Call instance to the EventListener. RealCall call = new RealCall(client, originalRequest, forWebSocket); call.eventListener = client.eventListenerFactory().create(call); return call; }

可以看到通过newCall()方法创建了RealCall实例，然后通过RealCall发起请求。接下来我们同步OkHttp的异步请求分析。异步请求调用了RealCall的enqueue()方法。

public void enqueue(Callback responseCallback) { synchronized (this) { if (executed) throw new IllegalStateException("Already Executed"); executed = true; } captureCallStackTrace(); eventListener.callStart(this); client.dispatcher().enqueue(new AsyncCall(responseCallback)); }

在这里，OkHttp通过调度器Dispatcher执行请求。

/Dispatcher/ synchronized void enqueue(AsyncCall call) { //这里判断队列是否已满，队列不满怎将请求放到线程池中执行，否则加入到队列中 if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) { runningAsyncCalls.add(call); executorService().execute(call); } else { readyAsyncCalls.add(call); } }

可以看到enqueue()方法是一个同步方法，在这里首先判断了请求队列是否已满，如果不满，则开始在线程池中执行请求AsyncCall。AsyncCall继承了NamedRunnable抽象类，而NamedRunnable继承了Runnable接口，在run方法中调用了execute()方法。

protected void execute() { boolean signalledCallback = false; try { //通过责任链模式执行接下来请求任务 Response response = getResponseWithInterceptorChain(); if (retryAndFollowUpInterceptor.isCanceled()) { signalledCallback = true; //执行失败回调 responseCallback.onFailure(RealCall.this, new IOException("Canceled")); } else { signalledCallback = true; //执行成功回调 responseCallback.onResponse(RealCall.this, response); } } //...... finally { client.dispatcher().finished(this); } }

在这里开始了OkHttp核心的请求部分。在OkHttp中使用了责任链模式处理这一部分的请求。getResponseWithInterceptorChain()开始请求。

Response getResponseWithInterceptorChain() throws IOException { // Build a full stack of interceptors. 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)); //连接拦截器，创建HTTP连接 if (!forWebSocket) { interceptors.addAll(client.networkInterceptors()); } interceptors.add(new CallServerInterceptor(forWebSocket)); //网络请求拦截器，开始网络请求

Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0, originalRequest, this, eventListener, client.connectTimeoutMillis(), client.readTimeoutMillis(), client.writeTimeoutMillis());

return chain.proceed(originalRequest); }

OkHttp的拦截器

在上面的代码中OkHttp通过各种拦截器处理请求。这里简单介绍下OkHttp的拦截器：

自定义拦截器：提供给用户的定制的拦截器。
失败和重定向拦截器（RetryAndFollowUpInterceptor）：请求在失败的时候重新开始已经请求重定向的拦截器。
桥接拦截器（BridgeInterceptor）：主要用来构造请求。
缓存拦截器（CacheInterceptor）：主要处理HTTP缓存。
连接拦截器（ConnectInterceptor）：主要处理HTTP链接。
网络请求拦截器（CallServerInterceptor）：负责发起网络请求。

拦截器是OkHttp发起请求的核心部分，接下来我们针对各种拦截器进行分析。上面的代码中，通过RealInterceptorChain的proceed()方法开始执行拦截器。

public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec, RealConnection connection) throws IOException { calls++; RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec, connection, index + 1, request, call, eventListener, connectTimeout, readTimeout, writeTimeout); Interceptor interceptor = interceptors.get(index); Response response = interceptor.intercept(next); //执行拦截器 //...... return response; }

重试拦截器—RetryAndFollowUpInterceptor

这里我们直接分析RetryAndFollowUpInterceptor的intercept()方法。

public Response intercept(Chain chain) throws IOException { //...... int followUpCount = 0; Response priorResponse = null; //通过一个循环来重新尝试请求 while (true) { if (canceled) { streamAllocation.release(); throw new IOException("Canceled"); } Response response; boolean releaseConnection = true; try { //1.调用下一个拦截器 response = realChain.proceed(request, streamAllocation, null, null); releaseConnection = false; } catch (RouteException e) { // 失败后尝试重新发送请求 if (!recover(e.getLastConnectException(), transmitter, false, request)) { throw e.getFirstConnectException(); } continue; } catch (IOException e) { // 失败后尝试重新发送请求 boolean requestSendStarted = !(e instanceof ConnectionShutdownException); if (!recover(e, transmitter, requestSendStarted, request)) throw e; continue; } //...... //2.检测response是否合法 Request followUp = followUpRequest(response); if (followUp == null) { if (!forWebSocket) { streamAllocation.release(); } //3.返回response，请求完成 return response; } //最多尝试20次 if (++followUpCount > MAX_FOLLOW_UPS) { streamAllocation.release(); throw new ProtocolException("Too many follow-up requests: " + followUpCount); } //4.重新设置请求 request = followUp; priorResponse = response; } }

在RetryAndFollowUpInterceptor中我们可以看到请求的重试是由一个无限循环保持的，同时在代码里还限制了请求的次数，最多尝试20次。RetryAndFollowUpInterceptor的具体逻辑是：

开启循环，继续调用下一个拦截器直到返回结果；
当请求内部抛出异常时，判定是否需要重试;如果符合重试条件，则重新发送请求；
通过followUpRequest()方法检查response是否合法，检查逻辑是根据HTTP返回码检测（具体逻辑可以查看通过followUpRequest()方法）。如果合法followUp为null，则返回结果，否则进行下一步；
重新设置request，设置response(用于接下来重新构造response),执行第1步。

BridgeInterceptor

我们看看BridgeInterceptor做了哪些事。

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) { requestBuilder.header("Content-Type", contentType.toString()); } long contentLength = body.contentLength(); 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)); }

if (userRequest.header("Connection") == null) { requestBuilder.header("Connection", "Keep-Alive"); } 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()) { 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); String contentType = networkResponse.header("Content-Type"); responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody))); } return responseBuilder.build(); }

从代码里可以看到，在BridgeInterceptor中出了HTTP的请求头，设置了请求头的各种参数，比如：Content-Type、Connection、User-Agent、GZIP等。

CacheInterceptor

缓存拦截器主要是处理HTTP请求缓存的，通过缓存拦截器可以有效的使用缓存减少网络请求。

public Response intercept(Chain chain) throws IOException { Response cacheCandidate = cache != null? cache.get(chain.request()): null;//1.取缓存 long now = System.currentTimeMillis(); CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get(); //2.验证缓存 Request networkRequest = strategy.networkRequest; Response cacheResponse = strategy.cacheResponse; //获取缓存

if (cache != null) { cache.trackResponse(strategy); } // If we're forbidden from using the network and the cache is insufficient, fail. //这里表示禁止使用缓存 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(); }

// If we don't need the network, we're done. //3.直接返回缓存 if (networkRequest == null) { return cacheResponse.newBuilder() .cacheResponse(stripBody(cacheResponse)) .build(); } Response networkResponse = null; try { //4.没有缓存，执行下一个拦截器 networkResponse = chain.proceed(networkRequest); }

// If we have a cache response too, then we're doing a conditional get. if (cacheResponse != null) { 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(); //5.更新缓存 cache.update(cacheResponse, response); return response; } else { closeQuietly(cacheResponse.body()); } } //...... if (cache != null) { if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) { // Offer this request to the cache. //6.保存缓存 CacheRequest cacheRequest = cache.put(response); return cacheWritingResponse(cacheRequest, response); } } return response; }

在上面的代码中可以看到，OkHttp首先会取出缓存，然后经过验证处理判断缓存是否可用。流程如下：

根据请求（以Request为键值）取出缓存；
验证缓存是否可用？可用，则直接返回缓存，否则进行下一步；
继续执行下一个拦截器，直到但会结果；
如果之前有缓存，则更新缓存，否则新增缓存。

缓存拦截器主要的工作就是处理缓存，知道了大致流程后，我们接下来分析一下OkHttp是如何管理缓存的。首先我们分析缓存如何获取，在代码中可以看到通过cache.get()得到，我们直接跟代码看。

final InternalCache internalCache = new InternalCache() { @Override public Response get(Request request) throws IOException { return Cache.this.get(request); }

@Override public CacheRequest put(Response response) throws IOException { return Cache.this.put(response); }

@Override public void remove(Request request) throws IOException { Cache.this.remove(request); }

@Override public void update(Response cached, Response network) { Cache.this.update(cached, network); }

@Override public void trackConditionalCacheHit() { Cache.this.trackConditionalCacheHit(); }

@Override public void trackResponse(CacheStrategy cacheStrategy) { Cache.this.trackResponse(cacheStrategy); } };

可以看到，缓存是通过InternalCache管理的，而InternalCache是Cache的内部了类，InternalCache又调用了Cache的方法。我们这里只分析一个get()方法。

@Nullable Response get(Request request) { String key = key(request.url()); DiskLruCache.Snapshot snapshot; Entry entry; try { snapshot = cache.get(key); if (snapshot == null) { return null; } } catch (IOException e) { return null; } try { entry = new Entry(snapshot.getSource(ENTRY_METADATA)); } catch (IOException e) { Util.closeQuietly(snapshot); return null; } Response response = entry.response(snapshot); //...... return response; }

可以看到，缓存是通过DiskLruCache管理，那么不难看出OkHttp的缓存使用了LRU算法管理缓存。接下来，我们分析下OkHttp如何验证缓存。

在上面的代码中，缓存最终来自于CacheStrategy。我们直接分析下那里的代码。

private CacheStrategy getCandidate() { // No cached response. if (cacheResponse == null) { //1.没有缓存，直接返回没有缓存 return new CacheStrategy(request, null); }

if (request.isHttps() && cacheResponse.handshake() == null) { //2.没有进行TLS握手，直接返回没有缓存 return new CacheStrategy(request, null); }

if (!isCacheable(cacheResponse, request)) { //3.判断是否是可用缓存。这里是根据cache-control的属性配置来判断的 return new CacheStrategy(request, null); }

CacheControl requestCaching = request.cacheControl(); if (requestCaching.noCache() || hasConditions(request)) { //4.cache-control：no-cache不接受缓存的资源；根据请求头的"If-Modified-Since"或者"If-None-Match"判断，这两个属性需要到服务端验证后才能判断是否使用缓存，所以这里先不使用缓存 return new CacheStrategy(request, null); }

CacheControl responseCaching = cacheResponse.cacheControl(); if (responseCaching.immutable()) { //5.cache-control:imutable 表示响应正文不会随时间而改变，这里直接使用缓存 return new CacheStrategy(null, cacheResponse); }

long ageMillis = cacheResponseAge(); long freshMillis = computeFreshnessLifetime();

if (requestCaching.maxAgeSeconds() != -1) { freshMillis = Math.min(freshMillis, SECONDS.toMillis(requestCaching.maxAgeSeconds())); }

long minFreshMillis = 0; if (requestCaching.minFreshSeconds() != -1) { minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds()); }

long maxStaleMillis = 0; if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) { maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds()); }

if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) { Response.Builder builder = cacheResponse.newBuilder(); if (ageMillis + minFreshMillis >= freshMillis) { builder.addHeader("Warning", "110 HttpURLConnection "Response is stale""); } long oneDayMillis = 24 * 60 * 60 * 1000L; if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) { builder.addHeader("Warning", "113 HttpURLConnection "Heuristic expiration""); } //6.这里根据时间计算缓存是否过期，如果不过期就使用缓存 return new CacheStrategy(null, builder.build()); }

String conditionName; String conditionValue; if (etag != null) { conditionName = "If-None-Match"; conditionValue = etag; } else if (lastModified != null) { conditionName = "If-Modified-Since"; conditionValue = lastModifiedString; } else if (servedDate != null) { conditionName = "If-Modified-Since"; conditionValue = servedDateString; } else { //7.没有缓存验证条件，需要请求服务端 return new CacheStrategy(request, null); // No condition! Make a regular request. }

Headers.Builder conditionalRequestHeaders = request.headers().newBuilder(); Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue);

Request conditionalRequest = request.newBuilder() .headers(conditionalRequestHeaders.build()) .build(); //8.这里将上面的验证条件加入请求头，继续向服务端发起请求 return new CacheStrategy(conditionalRequest, cacheResponse); }

从上面的代码可以看到，OkHttp经过很多判断才能确定是否使用缓存。判断过程可以总结为：

没有缓存，直接返回没有缓存.
HTTPS没有进行TLS握手，直接返回没有缓存.
判断是否是可用缓存。这里是根据cache-control的属性配置来判断的.
cache-control：no-cache不接受缓存的资源；根据请求头的"If-Modified-Since"或者"If-None-Match"判断，这两个属性需要到服务端验证后才能判断是否使用缓存，所以这里先不使用缓存.
cache-control:imutable 表示响应正文不会随时间而改变，这里直接使用缓存
这里根据时间计算缓存是否过期，如果不过期就使用缓存
没有缓存验证条件，需要请求服务端
将上面的验证条件（"If-None-Match"，"If-Modified-Since"）加入请求头，继续向服务端发起请求

在上面的验证过程中主要通过Cache-Control中的属性判断缓存是否可用，如果可用则直接返回缓存，否则像服务端继续发送请求判断缓存是否过期。

ConnectInterceptor

ConnectInterceptor的作用就是建立一个与服务端的连接。

public Response intercept(Chain chain) throws IOException { RealInterceptorChain realChain = (RealInterceptorChain) chain; Request request = realChain.request(); StreamAllocation streamAllocation = realChain.streamAllocation(); boolean doExtensiveHealthChecks = !request.method().equals("GET"); HttpCodec httpCodec = streamAllocation.newStream(client, chain, doExtensiveHealthChecks); RealConnection connection = streamAllocation.connection();

return realChain.proceed(request, streamAllocation, httpCodec, connection); }

在上面的代码中，可以看到连接来自于StreamAllocation的newStream()方法。

public HttpCodec newStream( OkHttpClient client, Interceptor.Chain chain, boolean doExtensiveHealthChecks) { int connectTimeout = chain.connectTimeoutMillis(); int readTimeout = chain.readTimeoutMillis(); int writeTimeout = chain.writeTimeoutMillis(); boolean connectionRetryEnabled = client.retryOnConnectionFailure();

try { RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout, writeTimeout, connectionRetryEnabled, doExtensiveHealthChecks); HttpCodec resultCodec = resultConnection.newCodec(client, chain, this);

synchronized (connectionPool) { codec = resultCodec; return resultCodec; } } catch (IOException e) { throw new RouteException(e); } }

可以看到在newStream()方法中会继续寻找连接。我们继续分析代码可以看到，OkHttp的连接是维护在一个连接池中的。

private RealConnection findConnection(int connectTimeout, int readTimeout, int writeTimeout, boolean connectionRetryEnabled) throws IOException { boolean foundPooledConnection = false; RealConnection result = null; Route selectedRoute = null; Connection releasedConnection; Socket toClose; synchronized (connectionPool) { if (released) throw new IllegalStateException("released"); if (codec != null) throw new IllegalStateException("codec != null"); if (canceled) throw new IOException("Canceled");

// Attempt to use an already-allocated connection. We need to be careful here because our // already-allocated connection may have been restricted from creating new streams. releasedConnection = this.connection; toClose = releaseIfNoNewStreams(); if (this.connection != null) { // We had an already-allocated connection and it's good.

最后相关架构及资料领取方式：

点击我的GitHub免费领取获取往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。