您现在的位置是:首页 > 正文

OkHttp完全解析

2024-02-01 06:37:13阅读 2

网上关于OkHttp的使用教程已经有很多了,先来贴一片网上的使用教程: http://blog.csdn.net/chenzujie/article/details/46994073

然后直接进入正题。
看完上面这篇文章,主要理解的几个点:

  1. 外部通过构造Request,初始化OkHttpClient,并由两者共同构造出Call。
  2. 访问网络通过Call,Call支持两种模式:同步和异步。同步使用execute,该方法会立即返回一个response,该response中包含结果。异步使用enqueue,也要传入callback来接受请求结果。
  3. OkHttp还支持拦截器,拦截器分两种,请求前拦截和网络返回前拦截。
  4. OkHttp还支持host检查、证书检查等等。并且还支持http1.0、http1.1、http2.0、SPDY协议。

先给一张关系图,呕心沥血之作。(这图请放大看)
这里写图片描述
接下来代码的讲解都是同步请求的情况(其实同步异步没区别啦),根据这张图来讲解一个请求的流程。

先来看下Request,这个类里面很简单,只是记录了一些基本的参数,例如url、method、header、requestBody等信息。

再看下OkHttpClient这个类,这个里面也很简单,没有什么复杂的逻辑,只是一个中转站。在这个里面记录了一些全局的东西(当然OkHttpClient这个也是全局唯一的,但不是单例,你可以创建多个OkHttpClient,不同的请求在不同的OkHttpClient中,共享的资源也不一样,例如下面提到的一些资源),例如List<Interceptor>(包括请求前和返回前的拦截),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<Reference<StreamAllocation>> allocations = new ArrayList<>(); 而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.
 *
 * <p>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<AsyncCall> readyAsyncCalls = new ArrayDeque<>();

  /** Running asynchronous calls. Includes canceled calls that haven't finished yet. */
  private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();

  /** Running synchronous calls. Includes canceled calls that haven't finished yet. */
  private final Deque<RealCall> 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,这是需要注意的。

网站文章