OkHttp源码读后感

这次是第二次看OkHttp的源码了，比起上一次，这次总算是理清了其中的脉络，这或许是随着工作经验的增加而发生的改变，说到底还是单身的锅，单身狗的周末只能玩代码消磨时间…….我是用SourceInsight作为工具的(之前装好的)，有说用JetBrains的IDEA效果更好，无奈何用的是长城宽带，坑的一比….下半天没下好…

从平时使用Api的顺序来源码是个不错的选择，下面是OkHttp的一般用法：

OkHttpClient client = new OkHttpClient.Builder().build(); Request request = new Request.Builder() .url(url) .post(body) .build(); Response response = client.newCall(request).execute(); String result = response.body().string(); response.close();

上面是同步的请求，但是异步请求才是OkHttp的精髓所在，异步请求是这样的：

OkHttpClient okHttpClient = new OkHttpClient(); Request request = new Request.Builder() .url("http://www.qq.com") .build(); Call call = okHttpClient.newCall(request); //1.异步请求，通过接口回调告知用户 http 的异步执行结果 call.enqueue(new Callback() { @Override public void onFailure(Call call, IOException e) { System.out.println(e.getMessage()); } @Override public void onResponse(Call call, Response response) throws IOException { if (response.isSuccessful()) { System.out.println(response.body().string()); } } });

异步请求使用了队列进行并发任务的分发(Dispatch)与回调，下面就先来看看OkHttpClient里面的newCall方法：

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

看来OkHttpClient只是一层皮，想知道newCall的具体实现还得去RealCall里面找才行：

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; }

这里实例化了一个RealCall对象，并且给这个RealCall添加一个EventListener，监听RealCall，这样就可以知道每次的网络请求具体进行到哪一步。

说了一大串好戏终于要开始了！在上面的代码中，不难发现execute()也是在RealCall里面的：

@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); } }

事不宜迟，马上来看看getResponseWithInterceptorChain()：

Response getResponseWithInterceptorChain() throws IOException { // Build a full stack of interceptors. List<Interceptor> 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)); Interceptor.Chain chain = new RealInterceptorChain( interceptors, null, null, null, 0, originalRequest, this, eventListener); return chain.proceed(originalRequest); } }

嗯，OkHttp的主要精髓之一就在这里了！这里有一个类型为Interceptor的List，这个List里面，有负责失败重试以及重定向的 RetryAndFollowUpInterceptor；负责把用户构造的请求转换为发送到服务器的请求、把服务器返回的响应转换为用户友好的响应的 BridgeInterceptor；负责读取缓存直接返回、更新缓存的 CacheInterceptor；负责和服务器建立连接的 ConnectInterceptor；配置 OkHttpClient 时设置的 networkInterceptors；负责向服务器发送请求数据、从服务器读取响应数据的 CallServerInterceptor。

OkHttp把所有这些负责不同工作的拦截，用责任链的模式把它们串起来，让它们各自完成各自的工作，这样就很好的实现了类似Http协议的分层的思想，每个拦截都实现了Interceptor接口，重写intercept()方法，返回各自对应的Response。

到这里，要理清OkHttp的各种策略只需要去看对应的Interceptor就可以了，我只看了其中的复用连接池策略、缓存策略这两种….下面就逐一的来看看是怎样实现的吧。

复用连接池：

创建一个TCP连接需要3次握手，而释放连接则需要2次或4次握手，如果每个请求都重新走一遍创建和销毁的流程，那是很费时和很费资源的事情，所以OkHttp通过复用连接池的方式实现了Socket连接的重用。说到这，还得补充一下，OkHttp还支持SPDY黑科技，什么是SPDY呢？引述《图解HTTP》的原文：

使用SPDY后，HTTP协议额外获得以下功能： 多路复用流 通过单一的TCP连接，可以无限制处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。 赋予请求优先级 SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发生多个请求时，解决因带宽低而导致响应变慢的问题。 压缩HTTP首部 压缩HTTP请求和响应的首部，这样一来，通信产生的数据包数量和发送的字节数就更少了。 推送功能 支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。 服务器提示功能 服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存的情况下，可以避免发送不必要的请求。

还是说回复用连接池的实现，具体的实现是在ConnectionPool中：

public final class ConnectionPool { /** * Background threads are used to cleanup expired connections. There will be at most a single * thread running per connection pool. The thread pool executor permits the pool itself to be * garbage collected. */ //这个executor就是复用连接池（其实就是线程池） private static final Executor executor = new ThreadPoolExecutor(0 /* corePoolSize */, Integer.MAX_VALUE /* maximumPoolSize */, 60L /* keepAliveTime */, TimeUnit.SECONDS, new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp ConnectionPool", true)); /**这个Runnable就是专门用来淘汰末位的socket，当满足以下条件时，就会进行末位淘汰，非常像GC 1. 并发socket空闲连接超过5个 2. 某个socket的keepalive时间大于5分钟 **/ private final Runnable cleanupRunnable = new Runnable() { @Override public void run() { while (true) { long waitNanos = cleanup(System.nanoTime()); if (waitNanos == -1) return; if (waitNanos > 0) { long waitMillis = waitNanos / 1000000L; waitNanos -= (waitMillis * 1000000L); synchronized (ConnectionPool.this) { try { ConnectionPool.this.wait(waitMillis, (int) waitNanos); } catch (InterruptedException ignored) { } } } } } };

可以看到具体的实现是在cleanup()里面：

long cleanup(long now) { int inUseConnectionCount = 0; int idleConnectionCount = 0; RealConnection longestIdleConnection = null; long longestIdleDurationNs = Long.MIN_VALUE; // Find either a connection to evict, or the time that the next eviction is due. synchronized (this) { for (Iterator<RealConnection> i = connections.iterator(); i.hasNext(); ) { RealConnection connection = i.next(); //找到每个连接的引用数 // If the connection is in use, keep searching. if (pruneAndGetAllocationCount(connection, now) > 0) { inUseConnectionCount++; continue; } idleConnectionCount++; // If the connection is ready to be evicted, we're done. long idleDurationNs = now - connection.idleAtNanos; if (idleDurationNs > longestIdleDurationNs) { longestIdleDurationNs = idleDurationNs; longestIdleConnection = connection; } } //最大并发连接大于5，或者keepalive时间超过5分钟 if (longestIdleDurationNs >= this.keepAliveDurationNs || idleConnectionCount > this.maxIdleConnections) { // We've found a connection to evict. Remove it from the list, then close it below (outside // of the synchronized block). connections.remove(longestIdleConnection); } else if (idleConnectionCount > 0) { // A connection will be ready to evict soon. return keepAliveDurationNs - longestIdleDurationNs; } else if (inUseConnectionCount > 0) { // All connections are in use. It'll be at least the keep alive duration 'til we run again. return keepAliveDurationNs; } else { // No connections, idle or in use. cleanupRunning = false; return -1; } } closeQuietly(longestIdleConnection.socket()); // Cleanup again immediately. return 0; }

复用连接池对于Socket的清理就类似于Java的引用计数法。

缓存策略：

先来说一下HTTP协议中的Cache-Control，服务器跟客户端的缓存都是通过这个HTTP的首部字段Cache-Control来实现的，下面引述《图解HTTP》原文：

举个栗子-> Cache-Control:private,max-age=0,no-cache 这是Cache-Control的一般用法，就是通过在Cache-Control中设定一些参数达到控制缓存的效果. 上面三个参数代表的意思分别是： private:响应只以特定的用户作为对象，缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发过来的请求，代理服务器则不会返回缓存；public则反之。 max-age:当客户端发送的请求中包含max-age指令时，如果判定缓存资源的缓存时间数值没有比指定时间的数值更小，那么客户端就接收缓存的资源，否则代理服务器向源服务器发送该请求；当max-age的值为0时，那么缓存服务器通常需要将请求转发给源服务器。 no-cache:使用no-cache指令的目的是为了防止从缓存中返回过期的资源。 除了上面三个还有下面几个常用的指令....... no-store:与no-cache容易混淆，当使用no-store指令时，暗示请求或响应中包含机密信息，所以该指令规定缓存不能在本地存储请求或响应的任一部分，no-store才是真正的不进行缓存。 max-stale:表示即使缓存过期也照常接收，max-stale后面是具体数值单位为秒 min-fresh:指令要求缓存服务器返回至少还未过指定时间的缓存资源。比如min-fresh=60(单位：秒)，在这60秒以内如果有超过有效期的资源都无法作为响应返回了 .....还有几个指令就不介绍了，感兴趣的同学可以买本《图解HTTP》看看哦

好了，说了那么多，回到OkHttp的缓存实现中来，OkHttp的缓存是通过CacheControl来实现的：

private CacheControl(boolean noCache, boolean noStore, int maxAgeSeconds, int sMaxAgeSeconds, boolean isPrivate, boolean isPublic, boolean mustRevalidate, int maxStaleSeconds, int minFreshSeconds, boolean onlyIfCached, boolean noTransform, boolean immutable, @Nullable String headerValue) { this.noCache = noCache; this.noStore = noStore; this.maxAgeSeconds = maxAgeSeconds; this.sMaxAgeSeconds = sMaxAgeSeconds; this.isPrivate = isPrivate; this.isPublic = isPublic; this.mustRevalidate = mustRevalidate; this.maxStaleSeconds = maxStaleSeconds; this.minFreshSeconds = minFreshSeconds; this.onlyIfCached = onlyIfCached; this.noTransform = noTransform; this.immutable = immutable; this.headerValue = headerValue; } CacheControl(Builder builder) { this.noCache = builder.noCache; this.noStore = builder.noStore; this.maxAgeSeconds = builder.maxAgeSeconds; this.sMaxAgeSeconds = -1; this.isPrivate = false; this.isPublic = false; this.mustRevalidate = false; this.maxStaleSeconds = builder.maxStaleSeconds; this.minFreshSeconds = builder.minFreshSeconds; this.onlyIfCached = builder.onlyIfCached; this.noTransform = builder.noTransform; this.immutable = builder.immutable; }

在CacheControl的构造方法里，可以看到刚才上面介绍的几个cache-control指令的身影。通过构建一个CacheControl的Builder，然后再把这个CacheControl加入CacheInterceptor拦截中，就可以轻松的对缓存进行控制(至于具体怎么添加拦截就请自行百度或google了，细心的同学会发现CacheInterceptor也就是责任链的其中一环，所以在构建Request的时候加上自定义的CacheControl就可以了。 )

其实一般情况下我们都不会去给Request加自定义的CacheControl，但是如果服务器端是外包给别人的，而你却又找不到那些服务端开发的人，那么这时候就只能靠自己了……

其实只要抓住责任链这一主要的设计，看OkHttp的源码也就轻松很多了，因为每个Interceptor拦截都对应着一个Control，Control是具体实现这些拦截的地方，而每个Interceptor则是拦截各自负责的请求并返回处理结果，读后感就写这么多了。

参考文章： 《图解HTTP》这是一本好书！ 感谢这位大神 感谢另一位大神