OkHttp源码分析(一)请求流程

这两天那些事情也弄的差不多了,也就回头又看了看OkHttp源码。它太多地方值得深入和学习。也为了提高自己,于是又从头看了一遍,也希望有更多的收获。目前已在这家公司超过三年,说不出什么感觉,,不知道是不是麻木了。。。。!!!!

源码分析

从发起一个简单的http网络请求开始

//构造OkhttpClient对象
OkHttpClient okHttpClient= new OkHttpClient();
//构造请求体 url ,tag ,header ext...
Request request = new Request.Builder().url("http://www.baidu.com").build()     
 //发起一个异步请求
okHttpClient.newCall(request).enqueue(new Callback() {
@Override
public void onFailure(Call call, IOException e) {
          Log.d(tag,e.toString());
}

@Override
public void onResponse(Call call, Response response) throws IOException {
          //处理响应结果
          int code = response.code();
          ResponseBody body =  response.body();
          Log.d(tag,body.string());
 });

从上面的例子,我们可以知道使用OkHttp发起一个http请求主要有三步:
1,构造一个OkHttpClient对象
2,构造请求体(包含url,tag,header,etc...)
3,发起请求
当然最后一步就是等待服务器响应,根据状态码处理响应体。
可以看出,使用OkHttp发起一个网络请求,是非常简单的,仅需三步就可以拿到我们服务器的响应结果,在这么简单的背后,OkHttp在背后到底为我们做了什么呢?我们提交的请求是怎么被执行的呢?响应是如何拿到的呢?其实我们也可以设想一下,内部一定是开启了一个子线程去帮我们处理请求,必定我们从学Android第一天就知道,耗时任务不能在主线程被执行,可能猜到这里,我们又会抛出疑问,在哪起的线程,任务在哪被执行,又或者是否使用了线程池执行任务等等......
带着这一连串的疑问,我们先看一下请求的提交流程

请求提交流程

从上面的例子,我们看到通过调用OkHttpClient对象的newCall()方法然后调用enqueue提交请求,我们进入OkHttpClient,查看一下newCall()方法的源码:

  /**
   * Prepares the {@code request} to be executed at some point in the future.
   */
  @Override public Call newCall(Request request) {
    return RealCall.newRealCall(this, request, false /* for web socket */);
  }

newCall()方法内部调用了RealCall对象的newRealCall()方法,通过newCall()方法的返回值,我们知道 RealCall.newRealCall()返回了一个Call对象。我们继续跟踪RealCall的源码,发现RealCall是okhttp3.Call接口的实现,okhttp3.Call表示一个等待执行的请求,并且它只能被执行一次,为什么只能被执行一次,我们后面分析原因,暂且放一放,okHttp3.Call中的源码:

public interface Call extends Cloneable {
 //返回请求关联的Request对象,前面例子中构造的Request对象
  Request request();
//立即执行请求,等待并阻塞直到返回请求结果
  Response execute() throws IOException;
//请求入列,异步执行,
  void enqueue(Callback responseCallback);
//取消一个请求,
  void cancel();

  boolean isExecuted();

  boolean isCanceled();


  Timeout timeout();

  Call clone();

  interface Factory {
    Call newCall(Request request);
  }
}

从前面的例子okHttpClient.newCall(request).enqueue(),发起请求,enqueue()这个方法实际是定义在Call中的,我们跟踪发现在整个OkHttp源码中,Call的唯一实现就是RealCall,它表示一个准备好被执行的请求,可以发起请求,取消请求等等...
拿到okHttp3.Call唯一实例,RealCall对象后,我们调用它的enqueue()方法:

  @Override public void enqueue(Callback responseCallback) {
    synchronized (this) {
      if (executed) throw new IllegalStateException("Already Executed");
      executed = true;
    }
    captureCallStackTrace();
    eventListener.callStart(this);
    client.dispatcher().enqueue(new AsyncCall(responseCallback));
  }

前面我们提到okhttp3.Call表示一个等待执行的请求,并且它只能被执行一次,看到这里,问题就解决了,如果第二次执行就会抛出Already Executed异常,原因就在这里。上面最核心的代码就是
client.dispatcher().enqueue(new AsyncCall(responseCallback));,应该是整个请求的核心地方,它帮我们做了两件事:
1,创建一个AsyncCall对象
2,调用Dispatcher中的enqueue方法,将请求入列

AsyncCall是什么,跟进去看一下源码:

  final class AsyncCall extends NamedRunnable {
    private final Callback responseCallback;

    AsyncCall(Callback responseCallback) {
      super("OkHttp %s", redactedUrl());
      this.responseCallback = responseCallback;
    }

    String host() {
      return originalRequest.url().host();
    }

    Request request() {
      return originalRequest;
    }

    RealCall get() {
      return RealCall.this;
    }


    void executeOn(ExecutorService executorService) {
       //...
    }

    @Override protected void execute() {
       //...
    }
  }

我们跟踪发现,AsyncCall 其实就是一个Runnable,用于执行任务。

我们还是回到我们之前提到的 client.dispatcher().enqueue(new AsyncCall(responseCallback));
client.dispatcher()返回了调度器Dispatcher对象,Dispatcher是OkHttp中相当核心的类:

  //同时最多发起64个请求
  private int maxRequests = 64;
  //同一host做多发起5个请求
  private int maxRequestsPerHost = 5;
  private @Nullable Runnable idleCallback;

  /** Executes calls. Created lazily. */
  //将会异步创建的线程池
  private @Nullable ExecutorService executorService;

  /** 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<>();

  public Dispatcher(ExecutorService executorService) {
    this.executorService = executorService;
  }

  public Dispatcher() {
  }

  public synchronized ExecutorService executorService() {
    if (executorService == null) {
      //默认核心线程为0,最多数量不限制,消息队列为SynchronousQueue,有请求时会不断创建线程
      executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
          new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
    }
    return executorService;
  }
//...

最后调用了Dispatcher分发器的enqueue()方法:

  void enqueue(AsyncCall call) {
    synchronized (this) {
      readyAsyncCalls.add(call);
    }
    promoteAndExecute();
  }

上面我们可以得到两个信息:
1,加入等待的readyAsyncCalls队列
2,推进并执行(暂且这样理解,字面翻译)

promoteAndExecute()字面是推进并执行,我们跟进去一探究竟,到底是怎么执行的:

  private boolean promoteAndExecute() {
    assert (!Thread.holdsLock(this));

    List<AsyncCall> executableCalls = new ArrayList<>();
    boolean isRunning;
    synchronized (this) {
      //迭代
      for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {
        //取出当前asyncCall
        AsyncCall asyncCall = i.next();
        //如果当前请求数大于64,直接跳出
        if (runningAsyncCalls.size() >= maxRequests) break; // Max capacity.
        //如果当前主机连接数大于5,继续遍历
        if (runningCallsForHost(asyncCall) >= maxRequestsPerHost) continue; // Host max capacity.

        i.remove();
        //加入executableCalls集合
        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()开始执行请求任务
      asyncCall.executeOn(executorService());
    }

    return isRunning;
  }

我们从promoteAndExecute()中知道:
1,在OkHttp中一般会存在一个Dispather对象,并且一个okHttpClienet能发起的最多请求是Diapatcher中定义的64个
2,同一个主机最多能发起的求请是5个
3,Dispatcher中有三个队列保持同步和异步请求
4,OkHttp中默认的线程核心数为0,最多数量Int的最大值,也就是不限制,消息队列为SynchronousQueue,有请求时会不断创建线程

任务是怎样被执行的呢?在方法的最后,有一个列表executableCalls存入了要执行的任务,然后遍历,调用了 asyncCall.executeOn(executorService());这里面又做了什么:

  void executeOn(ExecutorService executorService) {
      assert (!Thread.holdsLock(client.dispatcher()));
      boolean success = false;
      try {
        executorService.execute(this);
        success = true;
      } catch (RejectedExecutionException e) {
        InterruptedIOException ioException = new InterruptedIOException("executor rejected");
        ioException.initCause(e);
        eventListener.callFailed(RealCall.this, ioException);
        responseCallback.onFailure(RealCall.this, ioException);
      } finally {
        if (!success) {
          client.dispatcher().finished(this); // This call is no longer running!
        }
      }
    }

还记得我们之前提到的AsyncCall,他本质是一个Runnable(),这里我们还是看不出,我们只是知道AsyncCall实现了NamedRunnable,NamedRunnable是个啥:

public abstract class NamedRunnable implements Runnable {
  protected final String name;

  public NamedRunnable(String format, Object... args) {
    this.name = Util.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();
}

是不是恍然大悟,当我们在executeOn()中调用了executorService.execute(this);实质就是把我们的任务加入到了executorService并执行任务,到这里我么们了解了一个请求从提交到执行背后所经历的所有流程,用一张小图总结一下:


请求流程图.png

最后我们还是分析OkHttp线程池配置参数情况,

//核心线程书,最大线程数,闲置时间,SynchronousQueue,线程池工程                             
SynchronousQueue<Runnable> synchronousQueue = new SynchronousQueue(); 
ExecutorService executorService =                                     
        new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECO
                synchronousQueue,                                     
                Util.threadFactory("OkHttp Dispatcher", false));      

1,OkHttp线程池配置:
1,核心线程数为0
2,最大线程数,不限制
3,线程闲置时间为60s
4,队列为SynchronousQueue
5,线程池工厂,无守护线程
这样配置有什么特点呢?答:高并发,最大吞吐量,这也是我们前面提到有请求时不断创建线程的原因。
2,可不可以换成别的队列代替SynchronousQueue?先看下面这个例子:

 //核心线程书,最大线程数,闲置时间,SynchronousQueue,线程池工程                                                                   
//SynchronousQueue<Runnable> synchronousQueue = new SynchronousQueue();                                     
ArrayBlockingQueue<Runnable> arrayBlockingQueue = new ArrayBlockingQueue<>(1);                              
ExecutorService executorService =                                                                           
        new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,                                  
                arrayBlockingQueue,                                                                         
                Util.threadFactory("OkHttp Dispatcher", false));                                            
  executorService.execute(()->{                                                                             
      System.out.println("任务一");                                                                            
      for (;;);                                                                                             
  });                                                                                                       

  executorService.execute(()->{                                                                             
      System.out.println("任务二");                                                                            
  });                                                                                                       
image.png

我们发现任务二,永远无法执行,所以ArrayBlockingQueue不能代替SynchronousQueue,
LinkedBlockingQueue可不可以代替?它的内部实现是使用链表,区别是我们初始化的时候可以不传容量,如果不传容量为默认的Integer.MAX_VALUE,如果我现在往队列里,放了一百个任务,后面的99个永远得不到执行。
从上面分析,就可以知道为什么OkHttp使用了SynchronousQueue并且没有核心线程数的原因。

总结

通过上面的分析,主要弄明白了OkHttp发起一个请求的基本流程,以及线程池为什么要这样配置,总的来说发起请求流程还是非常容易理解的,后续我们继续分析OkHttp的拦截器,也是它的核心。如果有疑问,欢迎留言讨论。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容