OkHttp完全解析
网上关于OkHttp的使用教程已经有很多了，先来贴一片网上的使用教程： http://blog.csdn.net/chenzujie/article/details/46994073
然后直接进入正题。
看完上面这篇文章，主要理解的几个点：
- 外部通过构造Request，初始化OkHttpClient，并由两者共同构造出Call。
- 访问网络通过Call，Call支持两种模式：同步和异步。同步使用execute，该方法会立即返回一个response，该response中包含结果。异步使用enqueue，也要传入callback来接受请求结果。
- OkHttp还支持拦截器，拦截器分两种，请求前拦截和网络返回前拦截。
- OkHttp还支持host检查、证书检查等等。并且还支持http1.0、http1.1、http2.0、SPDY协议。
先给一张关系图，呕心沥血之作。（这图请放大看）
接下来代码的讲解都是同步请求的情况（其实同步异步没区别啦），根据这张图来讲解一个请求的流程。
先来看下Request，这个类里面很简单，只是记录了一些基本的参数，例如url、method、header、requestBody等信息。
再看下OkHttpClient这个类，这个里面也很简单，没有什么复杂的逻辑，只是一个中转站。在这个里面记录了一些全局的东西（当然OkHttpClient这个也是全局唯一的，但不是单例，你可以创建多个OkHttpClient，不同的请求在不同的OkHttpClient中，共享的资源也不一样，例如下面提到的一些资源），例如List（包括请求前和返回前的拦截），Cache相关的一些类、ConnectionPool，还有一些安全方面的类，例如SocketFactory、SocketSSLFactory、TrustRootIndex（验证书）、HostnameVerifier、CertificatePinner等，这些概念不懂可以参考这篇文章HTTP、HTTPS、SSL的关系。ConnectionPool这个很重要，看名字就知道这是连接池，主要用来存放当前处于连接状态的各个connection，和线程池是一个概念。当需要网络连接时，会先从该pool中取得一个connection，这个稍后会继续解释，暂时先这么理解。ConnectionPool只有在OkHttpClient里面初始化，并且全局引用到connectionPool都从OkHttpClient中引用。
基本了解完这个类之后，来看下如何构造出call，调用的是OkHttpClient.newCall(..)方法：
@Override public Call newCall(Request request) {
return new RealCall(this, request);
}该方法返回的是RealCall对象，RealCall是接下来需要介绍的一个类，这个类是继承自Call。该类记录了初始传进来的request，还有HttpEngine（这里暂时理解为网络访问的入口，通过HttpEngine来建立连接并返回数据）。刚刚提到了RealCall同步执行execute会立即返回一个response：
@Override public Response execute() throws IOException {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
try {
client.dispatcher().executed(this);
Response result = getResponseWithInterceptorChain(false);
if (result == null) throw new IOException("Canceled");
return result;
} finally {
client.dispatcher().finished(this);
}
}看Response result = getResponseWithInterceptorChain(false);这句，这里需要说明下刚刚提到的拦截器，拦截器分为请求前和返回前拦截，所以这里是请求前拦截。看下getResponseWithInterceptorChain(..)这个函数：
private Response getResponseWithInterceptorChain(boolean forWebSocket) throws IOException {
Interceptor.Chain chain = new ApplicationInterceptorChain(0, originalRequest, forWebSocket);
return chain.proceed(originalRequest);
}这个函数很简单，创建了一个拦截器链，来处理这个请求。
这里先解释下拦截器Interceptor和拦截器链Chain:
public interface Interceptor {
Response intercept(Chain chain) throws IOException;
interface Chain {
Request request();
Response proceed(Request request) throws IOException;
Connection connection();
}
}拦截器的接口很简单，只有一个intercept方法，用来处理该拦截器想要如何处理请求。Chain的接口也很简单，request方法该链中被处理的请求。proceed也很简单，返回当前被处理后的response。至于最后个方法，暂时不清楚。所以Chain的作用就是让request从头至尾经历拦截器的Intercept方法。
在上面方法中，创建的是ApplicationInterceptorChain这个链，让我们看下这个链proceed的具体实现：
@Override public Response proceed(Request request) throws IOException {
// If there's another interceptor in the chain, call that.
if (index < client.interceptors().size()) {
Interceptor.Chain chain = new ApplicationInterceptorChain(index + 1, request, forWebSocket);
Interceptor interceptor = client.interceptors().get(index);
Response interceptedResponse = interceptor.intercept(chain);
if (interceptedResponse == null) {
throw new NullPointerException("application interceptor " + interceptor
+ " returned null");
}
return interceptedResponse;
}
// No more interceptors. Do HTTP.
return getResponse(request, forWebSocket);
}这个方法中就是遍历client中所有的intercepts（请求前拦截），这里要注意的是client中的拦截器是每个request都要经历的。当走完所有的拦截器后，就去调用getResponse访问网络。看下getResponse中具体的实现：
Response getResponse(Request request, boolean forWebSocket) throws IOException {
// Copy body metadata to the appropriate request headers.
RequestBody body = request.body();
if (body != null) {
Request.Builder requestBuilder = request.newBuilder();
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");
}
request = requestBuilder.build();
}
// Create the initial HTTP engine. Retries and redirects need new engine for each attempt.
engine = new HttpEngine(client, request, false, false, forWebSocket, null, null, null);
int followUpCount = 0;
while (true) {
if (canceled) {
engine.releaseStreamAllocation();
throw new IOException("Canceled");
}
boolean releaseConnection = true;
try {
engine.sendRequest();
engine.readResponse();
releaseConnection = false;
} catch (RequestException e) {
// The attempt to interpret the request failed. Give up.
throw e.getCause();
} catch (RouteException e) {
// The attempt to connect via a route failed. The request will not have been sent.
HttpEngine retryEngine = engine.recover(e.getLastConnectException(), null);
if (retryEngine != null) {
releaseConnection = false;
engine = retryEngine;
continue;
}
// Give up; recovery is not possible.
throw e.getLastConnectException();
} catch (IOException e) {
// An attempt to communicate with a server failed. The request may have been sent.
HttpEngine retryEngine = engine.recover(e, null);
if (retryEngine != null) {
releaseConnection = false;
engine = retryEngine;
continue;
}
// Give up; recovery is not possible.
throw e;
} finally {
// We're throwing an unchecked exception. Release any resources.
if (releaseConnection) {
StreamAllocation streamAllocation = engine.close();
streamAllocation.release();
}
}
Response response = engine.getResponse();
Request followUp = engine.followUpRequest();
if (followUp == null) {
if (!forWebSocket) {
engine.releaseStreamAllocation();
}
return response;
}
StreamAllocation streamAllocation = engine.close();
if (++followUpCount > MAX_FOLLOW_UPS) {
streamAllocation.release();
throw new ProtocolException("Too many follow-up requests: " + followUpCount);
}
if (!engine.sameConnection(followUp.url())) {
streamAllocation.release();
streamAllocation = null;
}
request = followUp;
engine = new HttpEngine(client, request, false, false, forWebSocket, streamAllocation, null,
response);
}
}该方法中首先是根据request中的参数重新构建一个request，在request的头部中加入了一些参数。然后就根据HttpEngine来访问网络了。
首先根据request和OkHttpClient创建了一个HttpEngine（当然还有其他的参数，稍后解释），然后就进入了一个while(true)的循环。这个循环中先判断该request是不是被cancel了。然后就调用了HttpEngine的sendRequest方法（后面讲解，这理解为就是发送请求），然后在调用HttpEngine的readResponse方法来读取访问结果。如果访问时发生了错误，例如RouteException、IOException，则会尝试重连，调用HttpEngine的recover方法，重新生成一个HttpEngine来访问，然后重新进入刚刚的循环。如果访问成功，则调用getResponse方法来获取访问结果，调用followUpRequest来获取重定向请求，这里需要了解下重定向的概念。
一个简单的重定向例子就是一个网站，登陆的用户分为两种：管理员和游客，同一个url，对于不同身份的人来说访问到的页面可能不一样，这里就是用了重定向功能，例如该网站的某个页面，如果管理员访问是长某某样子（网页A），游客访问是长某某样子（网页B），这两个网页对应的url也不同，但是初始访问的url都是一样的，这是通过服务器对url和用户解析，返回一个新的url让用户去访问。不知道这么讲大家懂了没。。。一个简单的请求，重定向可以多次，不同的浏览器支持不同的次数。OkHttp框架中重定向最大次数由HttpEngine.MAX_FOLLOW_UPS决定：
回到正题，刚刚讲到如果访问成功，则调用getResponse方法来获取访问结果，调用followUpRequest来获取重定向请求。这里要了解的是，如果服务器发现要重定向，此次response返回3XX（http网络结果结果码详情），在response中还会包含下个重定向的url等信息。所以拿到response前需要检测是否需要重定向，如果要重定向还要检测是否超过最大值，因为刚刚说到这是在一个while(true)的循环里，重定向可能多次。如果发现followUpRequest为空，则说明response已拿到，直接返回。若不为空，则先检测是否超过最大值，若不超过，则新生成一个httpEngine来访问。
上面这段代码基本讲解完毕，但是在代码中，还看到一个概念StreamAllocation，将这个词分开来看，stream和allocation。解释下stream，是流的概念，和我们平时用InputStream和outputStream是一样的概念，我不知道该怎么解释http中的stream，就暂且把stream看成是一个请求在http中输入输出的流，一个stream代表一个请求。allocation比较简单，就是分配的概念，合起来看的话就是记录一个stream分配。StreamAllocation是一个比较重要的概念，首先先要了解下http版本。
http版本从最初的1.0版本，到后续的1.1版本，再到后续Google推出了SPDY，后来在推出了2.0版本，http协议越来越完善，下面几篇资料是讲述http协议的一个发展以及优化的过程。
HTTP1.0和HTTP1.1的区别 ———- http://blog.csdn.net/elifefly/article/details/3964766/
HTTP2.0的讲解 ———- http://www.open-open.com/lib/view/open1455796649605.html
HOL排头阻塞（head of line blocking） – http://baike.baidu.com/link?url=o2BnfuFRd-5jaIlcfAPMolg8nU-U4FUcjlK3jBA9PqI8iffnw3Q7nqx4EzNnjp9BKQDrTWuHFhLGquwxCH1DIa
socket讲解————–http://blog.csdn.net/semillon/article/details/7515926
上面这几篇文章一定要看，特别是http2.0的讲解和socket讲解这篇文章，阅读完该篇文章才能理解后续的讲解以及OkHttp设计的一个思想。
看完上述几篇文章，主要的一个核心思想就是http2.0和http1.0/1.1的主要区别，而OkHttp也是根据2.0和1.0/1.1作为区分，实现了两种连接机制。2.0解决了老版本（后续成1.0和1.1为老版本）最重要的两个问题：连接无法复用和head of line blocking问题。2.0使用了多路复用的技术，多个stream可以共用一个tcp连接，每个tcp连接都是通过一个socket来完成的，socket对应一个host和一个port，如果有多个stream（也就是多个request）都是连接到同一个host和port上，那么他们就可以共同使用一个socket。这样做的好处是减少TCP的一个三次握手的时间。 那在OkHttp里，记录一次连接的是RealConnection，这个就是负责连接的，在这个类中用socket来连接，还有HandShake来处理握手。
这里要说明下，OkHttp和HttpUrlConnection以及Volley的区别。虽然这三个都是可以用来访问网络的，但是还是不同的。我们最熟悉的肯定是HttpUrlConnection，这是google官方提供的用来访问网络，但是HttpUrlConnection实现的比较简单，只支持1.0/1.1，并没有上面讲的多路复用，如果碰到app大量网络请求的时候，性能比较差，而且HttpUrlConnection底层也是用Socket来实现的。而Volley是一个开源库，它只是封装了访问网络的一些操作，但是底层还是使用HttpUrlConnection。但是OkHttp不同，在看源码之前，一直以为OkHttp和Volley一样，是用HttpUrlConnection，但是找了半天代码，都没看到HttpUrlConnection和InputStream（OutputStream），倒是反而看到socket和sink(source)这些，后来才搞明白，原来OkHttp像HttpUrlConnection一样，实现了一个网络连接的过程。所以按照层级来说，OkHttp和HttpUrlConnection是一级的，用socket实现了网络连接，只是OkHttp更强大，而Volley只是一个引用了HttpUrlConnection，它并不关心网络连接过程，只是封装了请求的过程而已。刚刚提到HttpUrlConnection在IO方面用到的是InputStream和OutputStream，但是OkHttp用的是sink和source，这两个是在Okio这个开源库里的，sink相当于outputStream，source相当于是inputStream。sink和source比InputStream和OutputStream更加强大，单拿sink举例，他的子类有BufferedSink(支持缓冲)、GzipSink（支持Gzip压缩）、ForwardingSink和InflaterSink（后面这两者服务于GzipSink），source对应的也有，具体的可以自行上网查找。
刚刚我们讲到多个相同host和port的stream可以共同使用一个socket，而RealConnection就是处理连接的，那也就是说一个RealConnection上可能有很多个Stream，所以在RealConnection上记录了List 而StreamAllocation就是记录当前这个Stream是被分配到哪个RealConnection上，所以在StreamAllocation里也有一个变量记录了哪个RealConnection上。当然，每次生成一个RealConnection都要放入ConnectionPool里面，方便新的请求到达后，若能复用则复用池里的connection。
再回到刚刚那个函数的最后一点代码：
if (!engine.sameConnection(followUp.url())) {
streamAllocation.release();
streamAllocation = null;
}
request = followUp;
engine = new HttpEngine(client, request, false, false, forWebSocket, streamAllocation, null,response);当发现需要重定向的时候，就会执行这段代码，首先先检测重定向的url和刚刚的请求是不是同一个Connection，看下sameConnection函数：
public boolean sameConnection(HttpUrl followUp){
HttpUrl url = userRequest.url();
return url.host().equals(followUp.host())
&& url.port() == followUp.port()
&& url.scheme().equals(followUp.scheme());
}这函数很简单，只是看下这两个url的host、port、scheme是不是一样。如果发现不一样，就释放HttpEngine原来的streamAllocation，并置空，如果发现一样，则重用刚刚的stream。HttpEngine的构造函数里面会判断传入的StreamAllocation是不是为空，若为空则创建一个根据request，并传入ConnectionPool，创建一个streamAllocation，并且从ConnectionPool中取出Connection，并将该Connection记录到StreamAllocation中，如果没有可用的RealConnection，就创建个新的，然后再放到ConnectionPool中。
讲到这里，应该还是比较清楚的，目前已经讲清楚几个类了：OkHttpClient、RealCall、StreamAllocation、RealConnection、ConnectionPool。
接下来看下HttpEngine。这个类还是比较复杂的，刚刚在RealCall中只是看到调用了HttpEngine的一些函数，大致明白这些函数的意义，那现在继续看看这些函数内部实现。
先看下sendRequest函数：
public void sendRequest() throws RequestException, RouteException, IOException {
if (cacheStrategy != null) return; // Already sent.
if (httpStream != null) throw new IllegalStateException();
Request request = networkRequest(userRequest);
InternalCache responseCache = Internal.instance.internalCache(client);
Response cacheCandidate = responseCache != null
? responseCache.get(request)
: null;
long now = System.currentTimeMillis();
cacheStrategy = new CacheStrategy.Factory(now, request, cacheCandidate).get();
networkRequest = cacheStrategy.networkRequest;
cacheResponse = cacheStrategy.cacheResponse;
if (responseCache != null) {
responseCache.trackResponse(cacheStrategy);
}
if (cacheCandidate != null && cacheResponse == null) {
closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
}
// If we're forbidden from using the network and the cache is insufficient, fail.
if (networkRequest == null && cacheResponse == null) {
userResponse = new Response.Builder()
.request(userRequest)
.priorResponse(stripBody(priorResponse))
.protocol(Protocol.HTTP_1_1)
.code(504)
.message("Unsatisfiable Request (only-if-cached)")
.body(EMPTY_BODY)
.build();
return;
}
// If we don't need the network, we're done.
if (networkRequest == null) {
userResponse = cacheResponse.newBuilder()
.request(userRequest)
.priorResponse(stripBody(priorResponse))
.cacheResponse(stripBody(cacheResponse))
.build();
userResponse = unzip(userResponse);
return;
}
// We need the network to satisfy this request. Possibly for validating a conditional GET.
boolean success = false;
try {
httpStream = connect();
httpStream.setHttpEngine(this);
if (writeRequestHeadersEagerly()) {
long contentLength = OkHeaders.contentLength(request);
if (bufferRequestBody) {
if (contentLength > Integer.MAX_VALUE) {
throw new IllegalStateException("Use setFixedLengthStreamingMode() or "
+ "setChunkedStreamingMode() for requests larger than 2 GiB.");
}
if (contentLength != -1) {
// Buffer a request body of a known length.
httpStream.writeRequestHeaders(networkRequest);
requestBodyOut = new RetryableSink((int) contentLength);
} else {
// Buffer a request body of an unknown length. Don't write request headers until the
// entire body is ready; otherwise we can't set the Content-Length header correctly.
requestBodyOut = new RetryableSink();
}
} else {
httpStream.writeRequestHeaders(networkRequest);
requestBodyOut = httpStream.createRequestBody(networkRequest, contentLength);
}
}
success = true;
} finally {
// If we're crashing on I/O or otherwise, don't leak the cache body.
if (!success && cacheCandidate != null) {
closeQuietly(cacheCandidate.body());
}
}
}代码还是很长的，先来看下第五行，先是调用了一个networkRequest返回了一个request，这个函数就是对原来我们外部传进去的request做了一个封装，封装成一个真正访问网络请求的request。在HttpEngine中有两个request，一个叫userRequest，一个是networkRequest，第一个是外部传入的，未经OkHttp修改的，第二个是根据userRequest封装的一个request，用来访问网络。接下来就是获取InternalCache，Internal.instance是一个单例，该单例初始化是在OkHttpClient里面，可以看到调用Internal.instance.internalCache(client)函数只是调用了client(OkHttpClient)的internalCache，这个函数是返回了我们传入OkHttpClient的cache，如果你创建OkHttpClient的时候，没有传入，那么这里就会返回空。
得到了InternalCache后，尝试根据request去获取response，当然可能为空。接下来就到CacheStrategy了，CacheStrategy是一个决定访问网络还是访问缓存的类。CacheStrategy.Factory是工厂类，通过传入request和刚刚internalCache中获取到的response，去get一个CacheStrategy，Factory.get函数主要是对request和response做了一个检查，会根据response合不合法、是否过期、request的参数来判断，最后返回一个CacheStrategy。CacheStrategy很简单，里面有两个变量，一个是networkRequest，一个是cacheResponse（这个变量和传入Factory的response可能是不一样的哦！）。返回到刚刚的HttpEngine.sendRequest函数中看第17行，如果InternalCache不为空，就调用trackResponse，这个函数很简单，就是记录下缓存读取命中率这些数据。然后如果从InternalCache中response不为空，但是cacheStrategy的response为空，则说明刚刚InternalCache取出来的response无效，则需要关掉。如果CacheStrategy的networkRequest不为空，则说明需要进行网络访问，如果cacheResponse不为空，则说明访问缓存足以。根据这个理论，下面一直到第47行的代码不成问题，就不解释了。接下来看网络访问的部分。
网络访问主要是通过HttpStream来实现，HttpStream这是一个接口，里面定义了一些函数，这些函数是负责读取网络数据、输出数据等。实现该接口的有两个类，一个是Http2xStream，一个是Http1xStream。第一个是专门负责Http2.0版本的，第二个是负责Http1.x版本的，两者内部实现机制不一样。Http2xStream是通过一个FramedConnection，至于对FramedConnection的理解，可以看前面关于Http2.0讲解的文章，看完那个你应该比较能够大概清楚的理解他了，我就不解释了，这里我也没深入去看。而Http1xStream则是通过sink和source来实现的，这个前面讲过了，具体自己看吧，不解释了。
再次返回代码，connect函数返回了一个HttpStream，看下具体实现：
private HttpStream connect() throws RouteException, RequestException, IOException {
boolean doExtensiveHealthChecks = !networkRequest.method().equals("GET");
return streamAllocation.newStream(client.connectTimeoutMillis(),
client.readTimeoutMillis(), client.writeTimeoutMillis(),
client.retryOnConnectionFailure(), doExtensiveHealthChecks);
}主要还是调用了stream.newStream，接下来的源码就不看了，实在太多，感觉这篇文章可以绕地球三圈了。
newStream的函数里面，首先就是去创建一个RealConnection，然后根据返回的RealConnection里的参数去判断，如果RealConnection.framedConnection不为空，则返回Http2xStream（这里面包含connection的framedConnection），如果为空，则返回Http1xStream（这里包含connection的sink和source），所以这和我前面讲到的一样，RealConnection只是负责连接到服务器，具体的数据传输读取还是通过HttpStream。
那streamAllocation如何创建一个RealConnection呢，这个前面讲过，先看看StreamAllocation自己是否已经有一个connection，如果有则返回，若没有继续。根据StreamAllocation里面的address去connectionPool里面去取Connection，如果发现有则返回，如果没有就新创建一个，创建之后放入connectionPool中，并连接！！这点很重要，放入连接池的或者已经记录在StreamAllocation中的都是已连接的。
创建完HttpStream后就是数据流的进行了，后面应该就可以自己看懂了，不解释了。
如果一个stream结束了，需要release，并且关闭sink和source、framedConnection，还要释放RealConnection的list的一个，总之就是收尾工作要做好。然后HttpEngine的readResponse也就不解释了，对了在这里还有结果返回前的一个拦截，和之前拦截差不多一个原理，也不解释了。
还有就是Route和RouteDatabase，这两个类的意思就是记住当前已经走过的弯路，后续不要再走了。
最后还要讲一个东西，就是线程。 讲到网络访问，线程可是很重要的东西，因为android是不允许在主线程访问网络的，否则会抛出android.os.NetworkOnMainThreadException。刚刚在OkHttp外部使用的时候，并没有处理线程，而是直接调用，那么看来OkHTTP应该是在内部做了线程调度。
那看下异步情况下是如何进行线程调度的。先看下enqueue函数：
void enqueue(Callback responseCallback, boolean forWebSocket) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
client.dispatcher().enqueue(new AsyncCall(responseCallback, forWebSocket));
}就是封装了一个asyncCall传给了client下的dispatcher。看下Dispatcher的类说明：
/**
* Policy on when async requests are executed.
*
* Each dispatcher uses an {@link ExecutorService} to run calls internally. If you supply your
* own executor, it should be able to run {@linkplain #getMaxRequests the configured maximum} number
* of calls concurrently.
*/
看到了吧，这里说明dispatcher主要是用来给异步的请求做线程调度的，和同步没什么关系。那我们再看下Dispatcher中的enqueue函数
synchronized void enqueue(AsyncCall call) {
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
runningAsyncCalls.add(call);
executorService().execute(call);
} else {
readyAsyncCalls.add(call);
}
}在Dispatcher中记录了三个变量
/** 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中同时进行的call有数量要求，不能超过maxRequests。再返回看下enqueue函数，第一步先检测当前运行的request是不是超过maxRequest。部分call可能是连接到同一个host去的，检查加入的call连接到同个host的数量是不是超过maxRequestsPerHost，如果这两者都未超过，则加入runningAsyncCalls，并用executorService来运行它。否则就先加入readyAsyncCall去等待。ExecutorService是一个创建新线程运行runnable的地方，这就是保证了异步请求使用子线程请求的重要地方，刚刚传入的AsyncCall其实是实现了Runnable接口。看下AsyncCall的具体实现。
final class AsyncCall extends NamedRunnable {
private final Callback responseCallback;
private final boolean forWebSocket;
private AsyncCall(Callback responseCallback, boolean forWebSocket) {
super("OkHttp %s", originalRequest.url().toString());
this.responseCallback = responseCallback;
this.forWebSocket = forWebSocket;
}
//中间的函数都忽略
@Override protected void execute() {
boolean signalledCallback = false;
try {
Response response = getResponseWithInterceptorChain(forWebSocket);
if (canceled) {
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!
logger.log(Level.INFO, "Callback failure for " + toLoggableString(), e);
} else {
responseCallback.onFailure(RealCall.this, e);
}
} finally {
client.dispatcher().finished(this);
}
}
}
public abstract class NamedRunnable implements Runnable {
protected final String name;
public NamedRunnable(String format, Object... args) {
this.name = String.format(format, args);
}
@Override public final void run() {
String oldName = Thread.currentThread().getName();
Thread.currentThread().setName(name);
try {
execute();
} finally {
Thread.currentThread().setName(oldName);
}
}
protected abstract void execute();
}看asyncCall中的Execute函数其实和RealCall的execute函数几乎一样，当executorService.execute(asyncCall)的时候，就会调用AsyncCall的execute函数，然后就执行网络请求。
但是注意的是，同步情况下调用execute是不会有新线程的，就在外部调用realcall.execute的地方用一个线程，所以如果你在主线程上，调用execute的话，会抛出android.os.NetworkOnMainThreadException，这是需要注意的。