OkHttp 源码概述
概览
OkHttp是Android开发中一个支持Http协议的高效网络请求框架，支持同步请求和异步请求。
我们通过配置Request的url，okhttp就可以帮我们配置好其它所有关于http协议通讯的所有事情，包括缓存（需要手动开启）、添加请求头、压缩文件（GZIP）、自动重连、重定向、cookie、连接共享等等。
需要注意的是，OkHttp完全没有使用java内置的HttpUrlConnection。而是直接基于传输层的socket，重写了一个Android上的Http请求客户端，更加高效。
源码
OkHttp的源码主要分为两部分：走拦截器之前的部分，和拦截器部分。拦截器是OkHttp最精髓的地方，同时支持扩展，添加自定义拦截器。
Okio
OkHttp对于socket的写入数据和读取数据是基于Okio的，为什么OkHttp不用java提供的IO流而是使用OKio呢？
- 较低的cpu和内存消耗，okio使用segment组成的链表来存储数据，segment的内部实际就是字节数组。segment通过对复制操作共享一个字节数组等操作，来节省内存和存储数据
- API便捷，直接就具有读取字符串、整数等数据。无需IO流的多层包装
- 提供了Gzip、加密操作MD5和SHA-1功能
DiskLruCache
只是一个1000多行的java文件，但功能很强大。内部通过一个LinkedHashMap，来达到删除时先删除不常用的数据的功能。LinkedHashMap类本身就具有这个功能。通过LinkedHashMap的构造函数，将参数accessOrder指定为true，这样每次当我们访问LinkedHashMap的元素时，就会将这个元素移至队尾，当检测到指定大小的空间已满时，DiskLruCache的cleanupRunnable这个清理线程就会启动，从LinkedHashMap的队头（不常用元素的一段）开始清理，直到size < maxSize ;也是就缓存空间小于我们的设定值，就停止清理。
DiskLruCache有一个日志文件，记录我们对缓存的每次操作。这里有一个Dirty和Clean的概念。clean代表可读，dirty代表正在被写入。所以每当一个entry出现dirty的操作时，之后往往伴随着clean操作或者delete操作
每一个entry有valuecount * 2 个文件。OkHttp中valuecount的值默认为2
注意，空间满，清理的时候是按照当次运行程序的排序来清理的，而不是按照磁盘的整个访问次序清理的。
每次应用启动时加载DiskLruCache的时候会根据日志内容初始化LinkedHashMap链表，填充内容。
拦截器之前的部分
这部分的内容很简单，没什么说的，
从Dispatcher的成员变量就可以看出他的作用
/** Executes calls. Created lazily. */
private @Nullable ExecutorService executorService;
/** Ready async calls in the order they'll be run. */
private final Deque readyAsyncCalls = new ArrayDeque<>();
/** Running asynchronous calls. Includes canceled calls that haven't finished yet. */
private final Deque runningAsyncCalls = new ArrayDeque<>();
/** Running synchronous calls. Includes canceled calls that haven't finished yet. */
private final Deque runningSyncCalls = new ArrayDeque<>();
dispatcher内部维护三个队列，一个同步队列。两个异步队列：正准备和正在运行。然后通过一个线程池来执行异步请求。
不管是同步请求还是异步请求，真正的网络请求逻辑就是先加入running的队列，之后通过getResponseWithInterceptorChain()这个方法完成网络请求的，也就是拦截器。（当异步执行时，会先做判断：）
private int maxRequests = 64;
private int maxRequestsPerHost = 5;
synchronized void enqueue(AsyncCall call) {
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
runningAsyncCalls.add(call);
executorService().execute(call);
} else {
readyAsyncCalls.add(call);
}
}
okhttp对异步最多支持64个同时请求，而且对同一个host 的url只支持5个同时请求。
不管是同步还是异步，请求完成之后都会执行dispatcher.finished()方法，finished方法调用promoteCalls()方法：
private void promoteCalls() {
if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity.
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.
}
}
这里的逻辑就是遍历readyAsyncCalls，也就是准备队列，如果当前正在执行的请求小于64个或者对同一个hosturl的请求小于5个，就把这个请求移出准备队列，并加入running队列，调用线程池去执行这个请求。
拦截器部分
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));
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的核心，完整的拦截器流程。从Request向下递，至Reponse向上归
责任链模式
每一个拦截器的intercept方法，被chain.proceed(request)拦截成两部分，chain.proceed(request)上面的第一次发出请求依次往下执行 递 的过程，chain.proceed(request)下方的代码在请求完成执行 归 的过程，就像这张图
拦截器的职责
从上到下一共有五个拦截器，他们的职责简单总结一下，需要注意的是每一次网络请求都会经历每个拦截器两次，请求报文一次，响应报文一次。
-
RetryAndFollowUpInterceptor：根据Http协议的策略、Http请求和响应报文，来自动进行重定向与重连。 -
BridgeInterceptor：“ 这个拦截器的职能相对简单，就是对请求报文添加一些必要的headers，比如gzip,Host,Content-Length，Transfer-Encoding，Connection，User-Agent等等，对回来的响应报文也会删除一些headers。 -
CacheInterceptor： 这一个拦截器如其名，就是缓存策略相关，缓存策略也是根据HTTP协议来制定的。 -
ConnectInterceptor：这个拦截器是真正通过socket与服务器建立连接的地方 -
CallServerInterceptor：通过Okio与上一个拦截器建立起连接的socket向服务器发送请求报文，并且接受响应报文并将之构建成Respose一层一层传递给上层的拦截器。
自定义拦截器
而我们可以自己配置两种拦截器，interceptors和networkInterceptors，OkHttp官方分别叫他们 应用拦截器 和 网络拦截器 。从getResponseWithInterceptorChain方法中可以看到二者的顺序，分别是第一个拦截器和倒数第二个拦截器，具体说一下两个拦截器的区别：
应用拦截器
- 这里得到的请求没有BridgeInterceptor的重定向和BridgeInterceptor给它添加请求头，所以这里得到的请求报文是最原始的。相对应的，这里得到的响应报文也是最终的客户端接收到的响应报文。
- 这个拦截器是第一个执行的，所以在这里有能力去决定是否要执行
Chain.proceed()，让请求向下传递，通过这个特点可以实现一些有趣的功能
网络拦截器
- 这里能够修改最终向服务器发送的响应报文
- 缓存得到的response不会走这个拦截器，因为他在cacheIntercepter那里就返回了
- 可以获得服务器返回的最原始的响应报文
自定义拦截器
可以通过自定义拦截器来完成，动态添加Token，网络信息日志打印等功能
，下面就是一个简单的网络请求信息日志打印拦截器的例子。
public class LoggingInterceptor extends BaseInterceptor {
private static final String TAG = "LoggingInterceptor";
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
long t1 = System.nanoTime();
LogUtils.i(TAG, "intercept: " + String.format("Sending request %s on %s%n%s",
request.url(), chain.connection(), request.headers()));
Response response = chain.proceed(request);
long t2 = System.nanoTime();
LogUtils.i(TAG, "intercept: " + String.format("Received response for %s in %.1fms%n%s",
response.request().url(), (t2 - t1) / 1e6d, response.headers()));
return response;
}
}
自定义拦截器的核心是要理解责任链模式和递归，在chain.proceed(request) 上方的代码是 递 的过程，这个方法return之后是 归 的过程，代码写在 递 过程里，还是写在 归 过程里，是需要根据场景具体分析的