来看一下这个finish()方法；
private void finished(Deque calls, T call) {
Runnable idleCallback;
synchronized (this) {
// 移除队列的请求
if (!calls.remove(call)) throw new AssertionError(“Call wasn’t in-flight!”);
idleCallback = this.idleCallback;
}
// 执行请求
boolean isRunning = promoteAndExecute();
if (!isRunning && idleCallback != null) {
// 触发空闲线程执行
idleCallback.run();
}
}
这个方法的逻辑很简单，先移除队列里的call，然后再调用promoteAndExecute()执行已经准备好执行的请求，这个逻辑我们下面再讲；
（3）异步请求的执行：
void enqueue(AsyncCall call) {
synchronized (this) {
// 添加请求到异步队列；
readyAsyncCalls.add(call);
if (!call.get().forWebSocket) {
// 判断当前请求是否已经存在
AsyncCall existingCall = findExistingCallWithHost(call.host());
// 如果当前请求已经存在，则复用之前的线程计数，不进行递增；
if (existingCall != null) call.reuseCallsPerHostFrom(existingCall);
}
}
// 执行请求
promoteAndExecute();
}
这个方法里面，先将请求添加到异步队列readyAsyncCalls里面，然后再调用promoteAndExecute()方法来触发请求，下面我们来看看promoteAndExecute()的逻辑；
private boolean promoteAndExecute() {
assert (!Thread.holdsLock(this));
List executableCalls = new ArrayList<>();
boolean isRunning;
synchronized (this) {
// 1、遍历准备要执行的请求队列
for (Iterator i = readyAsyncCalls.iterator(); i.hasNext(); ) {
AsyncCall asyncCall = i.next();
// 2、判断当前正在执行的请求个数大于最大请求个数时，则取消请求
if (runningAsyncCalls.size() >= maxRequests) break; // Max capacity.
// 3、判断当前主机的连接数超过5个时，则跳过当前请求；
if (asyncCall.callsPerHost().get() >= maxRequestsPerHost) continue; // Host max capacity.
i.remove();
asyncCall.callsPerHost().incrementAndGet();
executableCalls.add(asyncCall);
// 添加请求到正在执行的队列中
runningAsyncCalls.add(asyncCall);
}
isRunning = runningCallsCount() > 0;
}
for (int i = 0, size = executableCalls.size(); i < size; i++) {
AsyncCall asyncCall = executableCalls.get(i);
// 执行请求；
asyncCall.executeOn(executorService());
}
return isRunning;
}
这个promoteAndExecute()方法的主要逻辑是执行readyAsyncCalls队列里的请求，而maxRequests和maxRequestsPerHost也是在这里处理的；
除此之后，这个类里面还有一些查询的方法，比如queuedCalls()，runningCalls()等，不过这些不是重点，了解即可；
拦截器，可以说是OkHttp最重要的部分了，这一部分通过一个很巧妙的设计，将复杂的网络请求逻辑分散到每个拦截器中，这种设计模式就叫做责任链；
责任链模式的优点：降低耦合度，简化对象，增强对象的灵活性；
缺点：性能会受到一定的影响；
那么对于网络请求，最简单的实现就是从0到1，也就是我直接请求，不考虑异常因素，保证每次请求都能成功，那么这个实现就很简单，只需要调用请求网络的api进行请求数据即可；
但是现实往往是残酷的，网络的环境极其复杂，而每一次的请求也不一定能返回，所以我们需要使用各种策略来保证网络请求可以正常完成，比如重试，缓存等操作来保证网络请求的正常使用；
而OkHttp的网络请求通过责任链设计了几个拦截器，巧妙的通过责任链模式来处理复杂的网络请求，避免了类的臃肿并且提供了很好的扩展性，缺点就是当责任链上的对象过多时，可能会出现性能的问题；
那么接下来我们来看看OkHttp的拦截器的实现吧；
OkHttp的拦截器有：
-
RetryAndFollowUpInterceptor：失败和重定向拦截器；
-
BridgeInterceptor：封装Response的拦截器；
-
CacheInterceptor：缓存处理相关的拦截器；
-
ConnectInterceptor：连接服务的拦截器，真正的网络请求在这里实现；
-
CallServerInterceptor：负责写请求和读响应的拦截器；
下面我们来一个个具体分析；
6.1、RetryAndFollowUpInterceptor
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
RealInterceptorChain realChain = (RealInterceptorChain) chain;
Transmitter transmitter = realChain.transmitter();
int followUpCount = 0;
Response priorResponse = null;
while (true) {
// 准备连接请求
transmitter.prepareToConnect(request);
…
Response response;
boolean success = false;
// 执行其他拦截器的功能，获取Response；
response = realChain.proceed(request, transmitter, null);
// 根据Response的返回码来判断要执行重试还是重定向；
Request followUp = followUpRequest(response, route);
…
if (followUp == null) {
// 如果followUpRequest返回的Request为空，那边就表示不需要执行重试或者重定向，直接返回数据；
return response;
}
RequestBody followUpBody = followUp.body();
if (followUpBody != null && followUpBody.isOneShot()) {
// 如果followUp为null，请求体不为空，并且只需要请求一次时，那么就返回response；
return response;
}
// 判断重试或者重定向的次数是否超过最大的次数，是的话则抛出异常；
if (++followUpCount > MAX_FOLLOW_UPS) {
throw new ProtocolException("Too many follow-up requests: " + followUpCount);
}
// 将需要重试或者重定向的请求赋值给新的请求；
request = followUp;
}
}
followUpRequest方法的逻辑我们大概瞄一眼，就是根据返回码来做一下操作；
6.2、BridgeInterceptor
桥接拦截器，这里主要做网络请求的封装，用于简化应用层的逻辑，比如网络请求需要传"Transfer-Encoding"，“Accept-Encoding”，“User-Agent”，"Cookie"这些参数，但是应用层不需要关心这些，那么就由这个拦截器来做这些封装；
当请求完成之后，也会对Response的header做一下封装处理，返回给应用层，这样应用层就不需要关心这个header的细节，简化操作；
public Response intercept(Chain chain) throws IOException {
if (body != null) {
MediaType contentType = body.contentType();
if (contentType != null) {
requestBuilder.header(“Content-Type”, contentType.toString());
}
// 处理封装"Content-Length",“Transfer-Encoding”,“Host”,“Connection”,“Accept-Encoding”,“Cookie”,"User-Agent"等请求头；
// 执行后续的拦截器的逻辑
Response networkResponse = chain.proceed(requestBuilder.build());
// 获取返回体的Builder
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
…
//处理返回的Response的"Content-Encoding"、“Content-Length”、"Content-Type"等返回头；
…
return responseBuilder.build();
}
6.3、CacheInterceptor
CacheInterceptor是缓存处理的拦截器，我们先来看一下这个拦截器的逻辑；
public Response intercept(Chain chain) throws IOException {
// 先获取候选缓存，前提是有配置缓存，也就是cache不为空；
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;
// 如果被禁止使用网络数据且缓存数据为空，那么返回一个504的Response，并且body为空；
if (networkRequest == null && cacheResponse == null) {
return new Response.Builder()
…
.build();
}
// 如果不需要使用网络数据，那么就直接返回缓存的数据；
if (networkRequest == null) {
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
// 执行后续的拦截器逻辑；
Response networkResponse = null;
try {
networkResponse = chain.proceed(networkRequest);
} finally {
…
}
if (cacheResponse != null) {
// 如果缓存数据不为空并且code为304，表示数据没有变化，继续使用缓存数据；
if (networkResponse.code() == HTTP_NOT_MODIFIED) {
Response response = cacheResponse.newBuilder().xx.build();
…
// 更新缓存数据
cache.update(cacheResponse, response);
return response;
}
}
// 获取网络返回的response
Response response = networkResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
// 将网络数据保存到缓存中；
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;
}
在这个获取缓存策略这一步，会生成一个CacheStrategy对象，用于管理缓存策略，那么在将缓存策略之前，我们先来了解几个概念；
强缓存：在请求数据的时候，查看请求头expires和cache-control是否命中缓存，如果是的话，那么久就会从缓存中获取数据，不会走网络请求；
协商缓存：而协商缓存是在没有命中强缓存的情况下才会走的逻辑，必会走一次网络请求，通过last-modified和etag返回头判断是否命中缓存，如果没有命中，那么就走网络重新获取到数据，协商缓存需要服务器支持才能实现；
那么接下来我们来看一下OkHttp是怎么实现缓存策略逻辑的；
如果对于缓存逻辑不是很清楚的话，可以看一下这篇文章：Android 你不得不学的HTTP相关知识
从上面那个方法，我们来看看new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get()的逻辑；
private CacheStrategy getCandidate() {
// 如果不使用缓存，那么就返回一个空的Response的CacheStrategy；
if (!isCacheable(cacheResponse, request)) {
return new CacheStrategy(request, null);
}
// 强缓存
long ageMillis = cacheResponseAge();
long freshMillis = computeFreshnessLifetime();
// 判断强缓存是否有效，是的话就返回缓存数据；
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””);
}
return new CacheStrategy(null, builder.build());
}
// 协商缓存
String conditionName;
String conditionValue;
if (etag != null) {
// etag协商缓存
conditionName = “If-None-Match”;
conditionValue = etag;
} else if (lastModified != null) {
// Last-Modified协商缓存
conditionName = “If-Modified-Since”;
// 最后修改时间
conditionValue = lastModifiedString;
} else if (servedDate != null) {
// Last-Modified协商缓存
conditionName = “If-Modified-Since”;
// 服务器最后修改时间
conditionValue = servedDateString;
} else {
// 没有协商缓存，返回一个空的Response的CacheStrategy；
return new CacheStrategy(request, null); // No condition! Make a regular request.
}
// 设置header
Headers.Builder conditionalRequestHeaders = request.headers().newBuilder();
Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue);
Request conditionalRequest = request.newBuilder()
.headers(conditionalRequestHeaders.build())
.build();
return new CacheStrategy(conditionalRequest, cacheResponse);
}
6.4、ConnectInterceptor
这个拦截器比较重要，网络的最底层实现都是通过这个类，这里面封装了socket连接和TLS握手等逻辑，接下来我们来看看具体是怎么实现的；
public Response intercept(Chain chain) throws IOException {
…
// 这简单的一行代码，却实现了无比复杂的网络请求，Exchange用于下一个拦截器CallServerInterceptor进行网络请求使用；
Exchange exchange = transmitter.newExchange(chain, doExtensiveHealthChecks);
// 执行后续的拦截器逻辑
return realChain.proceed(request, transmitter, exchange);
}
这个类主要实现了以下几个步骤的逻辑：
-
1：调用transmitter.newExchange方法；
-
2：通过Transmitter的ExchangeFinder调用了find方法；
-
3：ExchangeFinder里调用了findHealthyConnection方法；
-
4：ExchangeFinder里调用了findConnection方法创建了RealConnection；
-
5：调用了RealConnection的connect方法，实现了TCP + TLS 握手，底层通过socket来实现的；
-
6: 通过RealConnection的newCodec方法创建了两个协议类，一个是Http1ExchangeCodec，对应着HTTP1.1，一个是Http2ExchangeCodec，对应着HTTP2.0；
这个拦截器主要是实现网络连接的逻辑，而网络请求的逻辑是放在CallServerInterceptor这个拦截器中实现的；
那么上面我们讲完这个拦截器的基本逻辑，下面我们来看看更深层次的知识；
对于连接来说，最简单的实现就是每次需要的时候都进行创建并连接，不需要考虑网络环境，以及资源等等因素，但是现实情况我们不可能这样做，因为如果要追求极致的体验，我们就必须得做优化；
而这里的优化就是连接复用；
下面我们来看看源码是怎么实现复用逻辑的，上面我们了解到创建RealConnection是通过ExchangeFinder的findConnection方法，那么我们来看看这个方法里的具体逻辑；
private RealConnection findConnection(int connectTimeout, int readTimeout, int writeTimeout,
int pingIntervalMillis, boolean connectionRetryEnabled) throws IOException {
…
synchronized (connectionPool) {
…
if (result == null) {
// 尝试从缓存池中获取可用的连接
if (connectionPool.transmitterAcquirePooledConnection(address, transmitter, null, false)) {
foundPooledConnection = true;
result = transmitter.connection;
} else if (nextRouteToTry != null) {
// 如果获取不到，那么久从Route里面获取
selectedRoute = nextRouteToTry;
nextRouteToTry = null;
} else if (retryCurrentRoute()) {
// 如果当前的路由是重试的路由，那么就从路由里面获取
selectedRoute = transmitter.connection.route();
}
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
最后
针对Android程序员，我这边给大家整理了一些资料，包括不限于高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter等全方面的Android进阶实践技术；希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！
往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、混合式开发（ReactNative+Weex）全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
g-blog.csdnimg.cn/13f2cb2e05a14868a3f0fd6ac81d625c.png)
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-pbfcfKPR-1712608395216)]
最后
针对Android程序员，我这边给大家整理了一些资料，包括不限于高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter等全方面的Android进阶实践技术；希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！
往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、混合式开发（ReactNative+Weex）全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
[外链图片转存中…(img-NHIRelAN-1712608395216)]
[外链图片转存中…(img-uYiLRokm-1712608395216)]
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-fACSechM-1712608395217)]
1142
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
