本篇文章主要介紹OkHttp執行同步和非同步請求的大體流程。主要流程如下圖：
主要分析到getResponseWidthInterceptorChain方法，該方法為具體的根據請求獲取響應部分，留著後面的部落格再介紹。
Dispatcher類
Dispatcher類負責非同步任務的請求策略。首先看它的部分定義：
public final class Dispatcher {
private int maxRequests = 64;
private int maxRequestsPerHost = 5;
private Runnable idleCallback;
/** Executes calls. Created lazily. */
private 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) {
executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
}
return executorService;
}
...
}
內部有一個執行緒池，三個佇列，分別是readyAsyncCalls、runningAsyncCalls和runningSyncCalls佇列，其中runningSyncCalls用於儲存同步請求RealCall物件，runningAsyncCalls佇列用於儲存進入佇列的非同步請求AsyncCall物件，而readyAsyncCalls佇列用於當runningAsyncCalls的尺寸達到maxRequests引數時(預設64)儲存新加的非同步請求。至於為什麼要什麼做呢？
我的理解是為了避免一時間創造大量的執行緒浪費資源，那麼為什麼有執行緒池，還要用到這樣一個控制策略呢？這是因為建立預設執行緒池的引數導致的。預設的executorService的建立類似於Executors.newCachedThreadPool，該執行緒池的問題在於不會限制執行緒數量，如果一下子需要開啟1000乃至更多的執行緒，依然會開啟，而OkHttp這兒在Dispacther中做了控制。待會兒在下面的分析中可以看到這種控制策略。
其餘的引數maxRequestsPerHost表示每個主機的最大請求數，，預設為5，比如說如果這時好多個非同步請求都是請求百度上面的圖片，如果達到了5，那麼新的請求就會被放入到readyAsyncCalls佇列中，等該主機的請求數降下去後才會再次執行。
而引數idleCallback是Dispatcher中請求數量為0時的回撥，這兒的請求包含同步請求和非同步請求，該引數預設為null。
在Dispatcher中，需要明白一點，儘管同步請求自己負責執行請求，但是依然會先加入到Dispatcher的同步佇列，完成後從佇列中移除，而非同步請求則完全屬於Dispatcher控制，但是有些方法是對所有請求操作的，有些則是對非同步請求操作的，需要特別注意。
一般地，我們會將OkHttpClient作為單例，而Dispatcher是其一個成員，自然也是單例，所以一般整個應用的所有請求都會經過Dispatcher，不論是同步請求還是非同步請求。
同步請求的執行流程
在使用OkHttp進行網路同步非同步操作中知道了如何進行同步請求，建立一個Request物件，然後再建立一個Call物件，呼叫Call物件的execute方法即可。那麼就從execute方法看起。Call是一個介面，具體實現是RealCall，下面是RealCall的execute方法實現：
@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();
if (result == null) throw new IOException("Canceled");
return result;
} finally {
client.dispatcher().finished(this);
}
}首先是設定executed標誌為true，同一個Call只允許執行一次，執行多次就會丟擲異常。接下來是呼叫OkHttpClient的dispatcher()方法獲得Dispatcher物件，然後呼叫其executed(RealCall)方法，然後就是呼叫getResponseWithInterceptorChain方法同步獲取響應，最後呼叫Dispatcher的finished方法，下面先看executed方法：
/** Used by {@code Call#execute} to signal it is in-flight. */
synchronized void executed(RealCall call) {
runningSyncCalls.add(call);
}從程式碼中可以看出，Dispatcher的executed方法只是將同步請求加入到了runningSyncCalls佇列中。下面再看finished方法：
/** Used by {@code Call#execute} to signal completion. */
void finished(RealCall call) {
finished(runningSyncCalls, call, false);
}從上面程式碼中，可以看到finished方法再呼叫另一個finished方法，並將runningSyncCalls佇列傳入，具體實現如下：
private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
int runningCallsCount;
Runnable idleCallback;
synchronized (this) {
if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
if (promoteCalls) promoteCalls();
runningCallsCount = runningCallsCount();
idleCallback = this.idleCallback;
}
if (runningCallsCount == 0 && idleCallback != null) {
idleCallback.run();
}
}
首先是從佇列中移除請求，如果不能移除，則丟擲異常；在上面finished方法呼叫中看出傳入第三個引數為false，所以不會呼叫promoteCalls方法，該引數用於非同步請求時為true，這個下面分析非同步請求時再講。然後呼叫runningCallsCount統計目前還在執行的請求，最後，如果正在執行的請求數為0表示Dispatcher中沒有可執行的請求了，進入Idle狀態，此時如果idleCallback不為null，則呼叫其run方法。下面是runningCallsCount()方法的實現：
public synchronized int runningCallsCount() {
return runningAsyncCalls.size() + runningSyncCalls.size();
}可以看到這個方法返回的請求包括同步請求和非同步請求。
至此，同步請求的執行流程分析完成，可以看到Dispatcher只是儲存了一下同步請求和移除同步請求，而對於非同步請求，Dispatcher的工作就不只是這麼簡單了。
非同步請求的執行流程
我們知道如果要發起非同步請求，那麼就呼叫Call的enqueue方法並傳入回撥，依然從RealCall的enqueue方法看起：
@Override public void enqueue(Callback responseCallback) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
client.dispatcher().enqueue(new AsyncCall(responseCallback));
}可以看到，依然是首先將executed引數設為true，同樣地，非同步請求也不可以被執行兩次，然後呼叫Dispatcher的enqueue方法，但是這兒涉及到了一個新的類，AsyncCall。AsyncCall是RealCall的一個內部類並且繼承NamedRunnable，那麼首先看NamedRunnable類是什麼樣的，如下：
/**
* Runnable implementation which always sets its thread name.
*/
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();
}可以看到NamedRunnable實現了Runnbale介面並且是個抽象類，其抽象方法是execute()，該方法是在run方法中被呼叫的，這也就意味著NamedRunnable是一個任務，並且其子類應該實現execute方法。下面再看AsyncCall的實現：
final class AsyncCall extends NamedRunnable {
private final Callback responseCallback;
private AsyncCall(Callback responseCallback) {
super("OkHttp %s", redactedUrl().toString());
this.responseCallback = responseCallback;
}
String host() {
return originalRequest.url().host();
}
Request request() {
return originalRequest;
}
RealCall get() {
return RealCall.this;
}
@Override protected void execute() {
boolean signalledCallback = false;
try {
Response response = getResponseWithInterceptorChain();
if (retryAndFollowUpInterceptor.isCanceled()) {
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!
Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e);
} else {
responseCallback.onFailure(RealCall.this, e);
}
} finally {
client.dispatcher().finished(this);
}
}
}AsyncCall實現了execute方法，首先是呼叫getResponseWithInterceptorChain()方法獲取響應，然後獲取成功後，就呼叫回撥的onReponse方法，如果失敗，就呼叫回撥的onFailure方法。最後，呼叫Dispatcher的finished方法。
由於AsyncCall的execute()方法是在run中被呼叫的，所以getResponseWithInterceptorChain是在非呼叫執行緒中被呼叫的，然後得到響應後再交給Callback。
從上面的流程看出，與Dispatcher的互動主要涉及enqueue方法和finished方法，與同步請求類似。下面先看enqueue方法：
synchronized void enqueue(AsyncCall call) {
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
runningAsyncCalls.add(call);
executorService().execute(call);
} else {
readyAsyncCalls.add(call);
}
}首先如果正在執行的非同步請求的數量小於maxRequests並且與該請求相同的主機數量小於maxRequestsPerHost，也就是說符合放入runningAsyncCalls佇列的要求，那麼放入佇列，然後將AsyncCall交給執行緒池；如果不符合，那麼就放入到readyAsyncCalls佇列中。
當執行緒池執行AsyncCall任務時，它的execute方法會被呼叫，getResponseWithInterceptorChain()會去獲取響應，最後呼叫Dispatcher的finished方法，下面看finished方法：
/** Used by {@code AsyncCall#run} to signal completion. */
void finished(AsyncCall call) {
finished(runningAsyncCalls, call, true);
}從上面的程式碼可以看出，與同步請求的finished方法不同的是第一個引數傳入的是正在執行的非同步佇列，第三個引數為true，下面再看有是三個引數的finished方法：
private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
int runningCallsCount;
Runnable idleCallback;
synchronized (this) {
if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
if (promoteCalls) promoteCalls();
runningCallsCount = runningCallsCount();
idleCallback = this.idleCallback;
}
if (runningCallsCount == 0 && idleCallback != null) {
idleCallback.run();
}
}與同步請求相同的是，移除請求，獲取執行數量判斷是否進入了Idle狀態，不同的是會呼叫promoteCalls()方法，下面是promoteCalls()方法：
private void promoteCalls() {
if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity.
if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote.
for (Iterator<AsyncCall> 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.
}
}
promoteCalls方法主要負責從非同步等待佇列中將請求移步到非同步執行佇列中。主要就是遍歷等待佇列，並且需要滿足同一主機的請求小於maxRequestsPerHost時，就移到執行佇列中並交給執行緒池執行。
至此，分析完了同步請求和非同步請求的提交流程，Dispatcher負責非同步請求是放入執行佇列還是等待佇列中，並且在每個非同步請求執行完後，需要判斷是否需要把等待佇列中的請求移到執行佇列中並執行。不管是同步請求還是非同步請求，最終都會呼叫getResponseWithInterceptorChain()方法進行具體的網路請求，該方法下篇部落格深入理解OkHttp原始碼（二）——獲取響應會具體介紹。