我之前也在b站上發(fā)過很多關(guān)于Kotlin協(xié)程源碼分析的專欄，之前發(fā)的那些也挺好，但是我目前通過更加全面的學(xué)習(xí)系統(tǒng)從更加高的一個(gè)視角來詮釋我對協(xié)程之中有意思的點(diǎn)的理解。

第一部分大家可以參考我之前發(fā)的這期期視頻：

Kotlin協(xié)程PartI

主要講了協(xié)程的一些基礎(chǔ)內(nèi)容，然后分析了suspend函數(shù)通過轉(zhuǎn)換成自動機(jī)而實(shí)現(xiàn)的【掛起-恢復(fù)】的流程。

之后我也會基于這篇內(nèi)容發(fā)出視頻，但是視頻的內(nèi)容盡量壓縮到10分鐘以內(nèi)。壓縮的目的并不是為了減少知識的量或者是深度，而是將問題局限在一個(gè)點(diǎn)，讓更大群體的聽眾能夠獲取知識和信息。

以下是本篇專欄的目錄：

1. 簡單說一下launch的執(zhí)行邏輯

2. 任務(wù)是如何被分發(fā)給Dispatcher執(zhí)行的

Launch的執(zhí)行邏輯

在Kotlin中的協(xié)程構(gòu)建器，這里僅舉launch為例，它的執(zhí)行流程滿足如下的調(diào)用關(guān)系：

這個(gè)邏輯比較長，中間的部分我不想做過多展開，我們可以看看一頭一尾的邏輯：

當(dāng)我們執(zhí)行l(wèi)aunch方法時(shí)，Kotlin編譯器會對我們傳入的block進(jìn)行處理。上一期視頻中說過這個(gè)問題，Kotlin編譯器只認(rèn)suspend關(guān)鍵字，我們傳入的block在我們沒有注意到的情況下，其實(shí)是一個(gè)suspend lambda：

Kotlin編譯器會進(jìn)行處理，將這個(gè)block（suspend lambda）轉(zhuǎn)換成Continuation，具體大家可以去反編譯看一下代碼。

我們指直接轉(zhuǎn)到launch的快接近末尾的流程從startCoroutineCancellable開始看：

這個(gè)函數(shù)會調(diào)用下面的三個(gè)關(guān)聯(lián)的非常密切的函數(shù)，下面簡稱為【三段式】，也就是圖中標(biāo)顏色的部分：

如下圖，【三段式】中的第一個(gè)將Kotlin編譯器轉(zhuǎn)換的block進(jìn)行調(diào)用，產(chǎn)生Continuation對象；接著，這個(gè)Continuation對象調(diào)用其擴(kuò)展方法intercepted，通過ContinuationImpl#intercepted從當(dāng)前的CoroutineContext中找到ContinuationDisapatcher，并且返回一個(gè)DispatchedContinuation：

最后再通過resume方法執(zhí)行回調(diào)函數(shù)

任務(wù)是如何被分發(fā)給Dispatcher執(zhí)行的？

Dispatcher的設(shè)置

通過分析launch的執(zhí)行流程，可以看到當(dāng)前的關(guān)鍵就在intercepted過程中。這個(gè)過程會找當(dāng)前的CoroutineContext中的Interceptor。

在Kotlin coroutine庫中，Dispatcher，比如我們常見的Dispatchers.Main Dispatchers.IO都是CoroutineInterceptor的子類。在不指定Dispatcher的默認(rèn)情況下，使用的是Default。這是在launch方法中通過newContext指定的：

Dispatcher分發(fā)任務(wù)

繼續(xù)跟蹤Dispatchers.Default的intercept流程，就會指引我們走向CoroutineDispatcher#interceptContinuation方法，這也是為什么我上面說會返回?DispatchedContinuation

所以在【三段式】的最后的resumeCancellableWith我們就可以看DispatchContinuation中的定義：

在Dispatchers.Default中的dispatch邏輯是這樣干的：

如下圖所示，DispatchedContinuation本身是一個(gè)Runnable

在dispatch方法中，針對這個(gè)runnable進(jìn)行處理，處理為task之后，通過currentWorker提交到的一個(gè)叫做WorkerQueue的隊(duì)列中：

WorkerQueue本身和Worker是綁定的，關(guān)于什么之后執(zhí)行DispatchContinuation需要看Worker的處理。

以上的邏輯歸結(jié)到這張圖里：

Dispatch Worker#run

這里有必要總結(jié)一下，在launch中最先傳入的block，通過Kotlin編譯器變成了Continuation，通過Interceptor變成了DispatchedContinuation，然后變成了Task，在不同的階段我們最開始傳入的block被不斷的包裝，名字也隨之變化，大家不要弄混了。

Worker#run

Worker#run方法被委托給了runWorker，具體的操作就是不斷執(zhí)行尋找task的操作。

executeTask會執(zhí)行Task的run方法：

在這里就會檢查當(dāng)前job的狀態(tài)，并且執(zhí)行對應(yīng)的邏輯。

總結(jié)

綜合來看，Dispatcher分發(fā)邏輯是非常清晰的，在最開始執(zhí)行的時(shí)候會調(diào)用Kotlin編譯器的編譯結(jié)果，這里沒展示，如果出視頻的話我會給大家看看，然后會調(diào)用最關(guān)鍵的【三段式】，這其實(shí)就是對block的一層層的包裝處理，在三段式的最后一段調(diào)用resume，這樣被包裝的block就可以放到Dispatcher中去執(zhí)行了。

Dispatcher具體的邏輯我沒有研究，如果之后有機(jī)會可以出一期和Java的線程池對比的視頻，好！本期專欄就是這樣~