image
我們在前面的同步異步請求源碼分析中經(jīng)常會到 Dispatcher 類中去調(diào)用一些方法。
OkHttp如何實現(xiàn)同步異步請求的呢？
發(fā)送的同步/異步的請求都會在 Dispatcher 中管理其狀態(tài)
到底什么是Dispatcher？
Dispatcher 的作用為維護同步/異步請求的狀態(tài)，同時它在它的內(nèi)部維護一個線程池，用于執(zhí)行相應的請求。
我們?nèi)タ?Dispatcher 的源碼 ===>
image.png
上面的源碼我們看到很多次了
- runningSyncCalls 正在執(zhí)行的同步請求隊列
- runningAsyncCalls 正在執(zhí)行的異步請求隊列，并且包含了已經(jīng)取消但沒執(zhí)行完成的異步請求
- readyAsyncCalls 就緒的異步請求隊列，當我們整個的異步請求不滿足一個條件的是時候，它就會進入到我們就緒的異步請求隊列中，來進行緩存，如果當條件在滿足了之后，就會把就緒的異步請求隊列放到正在執(zhí)行的異步請求隊列中去執(zhí)行。
- executorService 線程池，這個線程池正是dispatcher中維護了整個異步之間的請求和高效的網(wǎng)路操作
先去同步請求中 Dispatcher 調(diào)用的管理
通過同步請求代碼流程找到
image.png
最后到 dispatcher 中的 executed() 方法和 finished() 方法中去看看
image.png
image.png
可以看到再同步請求中 dispatcher 就只做了兩件事：
1.直接將同步請求加入到正在執(zhí)行的同步請求隊列中（不會像異步請求添加到請求隊列會考慮一些情況）
2.將同步請求移除到正在執(zhí)行的同步請求隊列
異步請求中 Dispatcher 調(diào)用的管理
通過異步請求代碼流程找到
image.png
可以知道是到了 dispatcher 的 enqueue() 方法中
image.png
同時我們再去看看 dispatcher 中線程池 executorService()的創(chuàng)建方法中看看
image.png
這里細細的想了想，dispatcher 就是維護我們的請求隊列，在異步中它維護了一個線程池 executorService 用于執(zhí)行異步的網(wǎng)絡請求。當請求滿足 enqueue() 方法中 if 的條件的時候，dispatcher就會直接將異步請求放入正在執(zhí)行的異步請求隊列中。并且調(diào)用線程池來執(zhí)行開啟任務。 如果不滿足就把異步請求放入到緩存的異步請求隊列中，等到條件滿足再將異步請求放入正在執(zhí)行的異步請求隊列中去。
我們再看最后一個
image.png
image.png
在異步和同步 中不管請求怎么樣都會去執(zhí)行 dispatcher 中的 finished()方法
我們就去看看 這個方法
image.png
最后在異步請求會多調(diào)用一個方法 promoteCalls() 我們?nèi)タ纯?br>
image.png
這下就明白 為什么只有 異步請求 才會去調(diào)用這個調(diào)整異步請求隊列的方法。
好了，這就是 dispatcher 在 OkHttp 中所做的所有內(nèi)容。
