一、協程是什麼

1.簡介

協程並不是 Kotlin 提出來的新概念，其他的一些編程語言，例如：Go、Python 等都可以在語言層面上實現協程，甚至是 Java，也可以通過使用擴展庫來間接地支持協程。

「協程 Coroutines」源自 Simula 和 Modula-2 語言，這個術語早在 1958 年就被 Melvin Edward Conway 發明並用於構建彙編程序，說明協程是一種編程思想，並不侷限於特定的語言。

當我們在瞭解協程的時候，不可避免的會跟線程、進程做比較做分析，下面來貼個圖便於理解

從 Android 開發者的角度去理解它們的關係：

我們所有的代碼都是跑在線程中的，而線程是跑在進程中的。
協程沒有直接和操作系統關聯，但它不是空中樓閣，它也是跑在線程中的，可以是單線程，也可以是多線程。
單線程中的協程總的執行時間並不會比不用協程少。
Android 系統上，如果在主線程進行網絡請求，會拋出NetworkOnMainThreadException，對於在主線程上的協程也不例外，這種場景使用協程還是要切線程的。

協程設計的初衷是爲了解決併發問題，讓「協作式多任務」實現起來更加方便。

協程就是 Kotlin 提供的一套線程封裝的 API，但並不是說協程就是爲線程而生的。

不過，我們學習 Kotlin 中的協程，一開始確實可以從線程控制的角度來切入。因爲在 Kotlin 中，協程的一個典型的使用場景就是線程控制。就像 Java 中的Executor 和 Android 中的AsyncTask，Kotlin 中的協程也有對 Thread API 的封裝，讓我們可以在寫代碼時，不用關注多線程就能夠很方便地寫出併發操作。

下面的例子是使用協程進行網絡請求獲取用戶信息並顯示到 UI 控件上：

launch({
    val user = api.getUser() // 👈 網絡請求（IO 線程）
    nameTv.text = user.name  // 👈 更新 UI（主線程）
})

這裏只是展示了一個代碼片段，launch並不是一個頂層函數，它必須在一個對象中使用，launch 函數加上實現在 {} 中具體的邏輯，就構成了一個協程。

通常我們做網絡請求，要不就傳一個 callback，要不就是在 IO 線程裏進行阻塞式的同步調用，而在這段代碼中，上下兩個語句分別工作在兩個線程裏，但寫法上看起來和普通的單線程代碼一樣。

這裏的api.getUser是一個掛起函數，所以能夠保證nameTv.text的正確賦值，這就涉及到了協程中最著名的「非阻塞式掛起」。這個名詞看起來不是那麼容易理解，後面會講。現在先把這個概念放下，只需要記住協程就是這樣寫的就行了。

這種「用同步的方式寫異步的代碼」看起來很方便吧，那麼我們來看看協程具體好在哪。

2.協程好在哪

前面提到，launch 函數不是頂層函數，是不能直接用的，可以使用下面三種方法來創建協程：

// 方法一，使用 runBlocking 頂層函數
runBlocking {
    getImage(imageId)
}

// 方法二，使用 GlobalScope 單例對象
//            👇 可以直接調用 launch 開啓協程
GlobalScope.launch {
    getImage(imageId)
}

// 方法三，自行通過 CoroutineContext 創建一個 CoroutineScope 對象
//                                    👇 需要一個類型爲 CoroutineContext 的參數
val coroutineScope = CoroutineScope(context)
coroutineScope.launch {
    getImage(imageId)
}

方法一通常適用於單元測試的場景，而業務開發中不會用到這種方法，因爲它是線程阻塞的。
方法二和使用 runBlocking 的區別在於不會阻塞線程。但在 Android 開發中同樣不推薦這種用法，因爲它的生命週期會和 app 一致，且不能取消（什麼是協程的取消後面會講）。
方法三是比較推薦的使用方法，我們可以通過 context 參數去管理和控制協程的生命週期（這裏的 context 和 Android 裏的不是一個東西，是一個更通用的概念，會有一個 Android 平臺的封裝來配合使用）。

協程最常用的功能是併發，而併發的典型場景就是多線程。可以使用 Dispatchers.IO參數把任務切到 IO 線程執行：

CoroutineScope(Dispatchers.IO).launch {
    ...
}

也可以使用 Dispatchers.Main 參數切換到主線程：

CoroutineScope(Dispatchers.Main).launch{
    ...
}

所以在「協程是什麼」一節中講到的異步請求的例子完整寫出來是這樣的：

CoroutineScope(Dispatchers.Main).launch{   // 在主線程開啓協程
    val user = api.getUser() // IO 線程執行網絡請求
    nameTv.text = user.name  // 主線程更新 UI
}

而通過 Java 實現以上邏輯，我們通常需要這樣寫：

api.getUser(new Callback<User>() {
    @Override
    public void success(User user) {
        runOnUiThread(new Runnable() {
            @Override
            public void run() {
                nameTv.setText(user.name);
            }
        })
    }
    
    @Override
    public void failure(Exception e) {
        ...
    }
});

這種回調式的寫法，打破了代碼的順序結構和完整性，讀起來相當難受。

3.協程具體怎麼用

a.添加依賴

    //依賴協程核心庫
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.5'
    //依賴當前平臺所對應的平臺庫
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.5'

Kotlin 協程是以官方擴展庫的形式進行支持的。我們所使用的「核心庫」和「平臺庫」的版本應該保持一致。

核心庫中包含的代碼主要是協程的公共 API 部分。有了這一層公共代碼，才使得協程在各個平臺上的接口得到統一。
平臺庫中包含的代碼主要是協程框架在具體平臺的具體實現方式。因爲多線程在各個平臺的實現方式是有所差異- 的。

b.開始使用

協程最簡單的使用方法，其實在前面章節就已經看到了。我們可以通過一個 launch函數實現線程切換的功能：

CoroutineScope(Dispatchers.IO).launch {
    ...
}

這個 launch 函數，它具體的含義是：我要創建一個新的協程，並在指定的線程上運行它。這個被創建、被運行的所謂「協程」是誰？就是你傳給 launch 的那些代碼，這一段連續代碼叫做一個「協程」。

所以，什麼時候用協程？當你需要切線程或者指定線程的時候。你要在後臺執行任務？切！

launch(Dispatchers.IO) {
    val image = getImage(imageId)
}

然後需要在前臺更新界面？再切！

CoroutineScope(Dispatchers.IO).launch{
    val image = getImage(imageId)
    launch(Dispatch.Main) {
        avatarIv.setImageBitmap(image)
    }
}

好像有點不對勁？這不還是有嵌套嘛。

如果只是使用 launch 函數，協程並不能比線程做更多的事。不過協程中卻有一個很實用的函數：withContext 。這個函數可以切換到指定的線程，並在閉包內的邏輯執行結束之後，自動把線程切回去繼續執行。那麼可以將上面的代碼寫成這樣：

CoroutineScope(Dispatchers.Main).launch {      // 👈 在 UI 線程開始
    val image = withContext(Dispatchers.IO) {  // 👈 切換到 IO 線程，並在執行完成後切回 UI 線程
        getImage(imageId)                      // 👈 將會運行在 IO 線程
    }
    avatarIv.setImageBitmap(image)             // 👈 回到 UI 線程更新 UI
}

這種寫法看上去好像和剛纔那種區別不大，但如果你需要頻繁地進行線程切換，這種寫法的優勢就會體現出來。可以參考下面的對比：

// 第一種寫法
CoroutineScope(Dispatchers.IO).launch {
    ...
    launch(Dispachers.Main){
        ...
        launch(Dispachers.IO) {
            ...
            launch(Dispacher.Main) {
                ...
            }
        }
    }
}

// 通過第二種寫法來實現相同的邏輯
CoroutineScope(Dispatchers.Main).launch{
    ...
    withContext(Dispachers.IO) {
        ...
    }
    ...
    withContext(Dispachers.IO) {
        ...
    }
    ...
}

由於可以"自動切回來"，消除了併發代碼在協作時的嵌套。由於消除了嵌套關係，我們甚至可以把 withContext 放進一個單獨的函數裏面：

launch(Dispachers.Main) {              // 👈 在 UI 線程開始
    val image = getImage(imageId)
    avatarIv.setImageBitmap(image)     // 👈 執行結束後，自動切換回 UI 線程
}
//                               👇
fun getImage(imageId: Int) = withContext(Dispatchers.IO) {
    ...
}

這就是之前說的「用同步的方式寫異步的代碼」了。

不過如果只是這樣寫，編譯器是會報錯的：

fun getImage(imageId: Int) = withContext(Dispatchers.IO) {
    // IDE 報錯 Suspend function'withContext' should be called only from a coroutine or another suspend funcion
}

意思是說，withContext 是一個 suspend函數，它需要在協程或者是另一個 suspend函數中調用。

c.suspend

suspend是 Kotlin 協程最核心的關鍵字，幾乎所有介紹 Kotlin 協程的文章和演講都會提到它。它的中文意思是「暫停」或者「可掛起」。如果你去看一些技術博客或官方文檔的時候，大概可以瞭解到：「代碼執行到 suspend 函數的時候會『掛起』，並且這個『掛起』是非阻塞式的，它不會阻塞你當前的線程。」

上面報錯的代碼，其實只需要在前面加一個suspend 就能夠編譯通過：

suspend fun getImage(imageId: Int) = withContext(Dispatchers.IO) {
    ...
}

而suspend具體是什麼，下面介紹。

4.小結

協程是一種編程思想，寫法簡潔，可以通過Dispatchers調度器切換到指定的線程。所有代碼都是運行在線程中的，協程也是。

二、掛起是什麼

1.「掛起」的本質

協程中「掛起」的對象到底是什麼？掛起線程，還是掛起函數？都不對，我們掛起的對象是協程。

launch ，async 或者其他函數創建的協程，在執行到某一個 suspend 函數的時候，這個協程會被「suspend」，也就是被掛起。

那此時又是從哪裏掛起？從當前線程掛起。換句話說，就是這個協程從正在執行它的線程上脫離。

注意，不是這個協程停下來了！是脫離，當前線程不再管這個協程要去做什麼了。

suspend 是有暫停的意思，但我們在協程中應該理解爲：當線程執行到協程的 suspend 函數的時候，暫時不繼續執行協程代碼了。

我們先讓時間靜止，然後兵分兩路，分別看看這兩個互相脫離的線程和協程接下來將會發生什麼事情：

線程：

前面我們提到，掛起會讓協程從正在執行它的線程上脫離，具體到代碼其實是：

協程的代碼塊中，線程執行到了 suspend 函數這裏的時候，就暫時不再執行剩餘的協程代碼，跳出協程的代碼塊。

那線程接下來會做什麼呢？

如果它是一個後臺線程：

要麼無事可做，被系統回收
要麼繼續執行別的後臺任務

跟 Java 線程池裏的線程在工作結束之後是完全一樣的：回收或者再利用。

如果這個線程它是 Android 的主線程，那它接下來就會繼續回去工作：也就是一秒鐘 60 次的界面刷新任務。

協程：

線程的代碼在到達suspend函數的時候被掐斷，接下來協程會從這個suspend 函數開始繼續往下執行，不過是在指定的線程。

誰指定的？是 suspend 函數指定的，比如函數內部的 withContext 傳入的Dispatchers.IO所指定的 IO 線程。

Dispatchers 調度器，它可以將協程限制在一個特定的線程執行，或者將它分派到一個線程池，或者讓它不受限制地運行。

常用的Dispatchers ，有以下三種：

Dispatchers.Main：Android 中的主線程
Dispatchers.IO：針對磁盤和網絡 IO 進行了優化，適合 IO 密集型的任務，比如：讀寫文件，操作數據庫以及網絡請求
Dispatchers.Default：適合 CPU 密集型的任務，比如計算

回到我們的協程，它從suspend函數開始脫離啓動它的線程，繼續執行在 Dispatchers所指定的 IO 線程。

緊接着在 suspend 函數執行完成之後，協程爲我們做的最爽的事就來了：會自動幫我們把線程再切回來。

這個「切回來」是什麼意思？

我們的協程原本是運行在主線程的，當代碼遇到suspend函數的時候，發生線程切換，根據 Dispatchers 切換到了 IO 線程；

當這個函數執行完畢後，線程又切了回來，「切回來」也就是協程會幫我再 post一個 Runnable，讓我剩下的代碼繼續回到主線程去執行。

ok，我們從線程和協程的兩個角度都分析完成後，終於可以對協程的「掛起」suspend 做一個解釋：

協程在執行到有 suspend 標記的函數的時候，會被 suspend 也就是被掛起，而所謂的被掛起，就是切個線程；

不過區別在於，掛起函數在執行完成之後，協程會重新切回它原先的線程。

再簡單來講，在 Kotlin 中所謂的掛起，就是一個稍後會被自動切回來的線程調度操作。

這個「切回來」的動作，在 Kotlin 裏叫做 resume，恢復。

通過剛纔的分析我們知道：掛起之後是需要恢復。

而恢復這個功能是協程的，如果你不在協程裏面調用，恢復這個功能沒法實現，所以也就回答了這個問題：爲什麼掛起函數必須在協程或者另一個掛起函數裏被調用。

因爲一個掛起函數要麼在協程裏被調用，要麼在另一個掛起函數裏被調用，所以不管是直接還是間接地，總是會在一個協程裏被調用的。

當然，要求 suspend 函數只能在協程裏或者另一個 suspend 函數裏被調用，還是爲了要讓協程能夠在 suspend 函數切換線程之後再切回來。

2.怎麼就「掛起」了？

我們瞭解到了什麼是「掛起」後，再接着看看這個「掛起」是怎麼做到的。

先隨便寫一個自定義的 suspend函數：

suspend fun suspendingPrint() {
  println("Thread: ${Thread.currentThread().name}")
}

I/System.out: Thread: main

輸出的結果還是在主線程。

爲什麼沒切換線程？因爲它不知道往哪切，需要我們告訴它。

比如例子中 suspendingGetImage 函數代碼：

//                                               👇
suspend fun suspendingGetImage(id: String) = withContext(Dispatchers.IO) {
  ...
}

我們可以發現不同之處其實在於 withContext函數。

其實通過 withContext源碼可以知道，它本身就是一個掛起函數，它接收一個 Dispatcher參數，依賴這個 Dispatcher 參數的指示，你的協程被掛起，然後切到別的線程。

所以這個 suspend，其實並不是起到把任何把協程掛起，或者說切換線程的作用。

真正掛起協程這件事，是 Kotlin 的協程框架幫我們做的。

所以我們想要自己寫一個掛起函數，僅僅只加上 suspend 關鍵字是不行的，還需要函數內部直接或間接地調用到 Kotlin 協程框架自帶的 suspend 函數纔行。

3.suspend 的意義？

這個 suspend 關鍵字，既然它並不是真正實現掛起，那它的作用是什麼？

它其實是一個提醒。

函數的創建者對函數的使用者的提醒：我是一個耗時函數，我被我的創建者用掛起的方式放在後臺運行，所以請在協程裏調用我。

爲什麼 suspend關鍵字並沒有實際去操作掛起，但 Kotlin 卻把它提供出來？

因爲它本來就不是用來操作掛起的。

掛起的操作 —— 也就是切線程，依賴的是掛起函數裏面的實際代碼，而不是這個關鍵字。

所以這個關鍵字，只是一個提醒。

還記得剛纔我們嘗試自定義掛起函數的方法嗎？

// 👇 redundant suspend modifier
suspend fun suspendingPrint() {
  println("Thread: ${Thread.currentThread().name}")
}

如果你創建一個 suspend 函數但它內部不包含真正的掛起邏輯，編譯器會給你一個提醒：redundant suspend modifier，告訴你這個suspend是多餘的。

因爲你這個函數實質上並沒有發生掛起，那你這個 suspend 關鍵字只有一個效果：就是限制這個函數只能在協程裏被調用，如果在非協程的代碼中調用，就會編譯不通過。

所以，創建一個 suspend 函數，爲了讓它包含真正掛起的邏輯，要在它內部直接或間接調用 Kotlin 自帶的 suspend 函數，你的這個 suspend纔是有意義的。

4.怎麼自定義 suspend 函數？

在瞭解了 suspend 關鍵字的來龍去脈之後，我們就可以進入下一個話題了：怎麼自定義 suspend 函數。

這個「怎麼自定義」其實分爲兩個問題：

什麼時候需要自定義 suspend 函數？
具體該怎麼寫呢？

a.什麼時候需要自定義 suspend 函數

如果你的某個函數比較耗時，也就是要等的操作，那就把它寫成 suspend 函數。這就是原則。

耗時操作一般分爲兩類：I/O 操作和 CPU 計算工作。比如文件的讀寫、網絡交互、圖片的模糊處理，都是耗時的，通通可以把它們寫進 suspend 函數裏。

另外這個「耗時」還有一種特殊情況，就是這件事本身做起來並不慢，但它需要等待，比如 5 秒鐘之後再做這個操作。這種也是 suspend 函數的應用場景。

a.具體該怎麼寫

給函數加上 suspend 關鍵字，然後在 withContext 把函數的內容包住就可以了。

提到用 withContext是因爲它在掛起函數裏功能最簡單直接：把線程自動切走和切回。

當然並不是只有 withContext 這一個函數來輔助我們實現自定義的 suspend 函數，比如還有一個掛起函數叫 delay，它的作用是等待一段時間後再繼續往下執行代碼。

使用它就可以實現剛纔提到的等待類型的耗時操作：

suspend fun suspendUntilDone() {
  while (!done) {
    delay(5)
  }
}

這些東西，在我們初步使用協程的時候不用立馬接觸，可以先把協程最基本的方法和概念理清楚。

5.小結

這一部分主要講的是掛起，這個掛起對象就是協程，是一段代碼塊。
掛起其實就是切換線程，而協程還可以再幫我們切回來。

三、掛起的非阻塞式是怎麼回事

1.什麼是「非阻塞式掛起」

非阻塞式是相對阻塞式而言的。

線程阻塞很好理解，現實中的例子就是交通堵塞，它的核心有 3 點：

前面有障礙物，你過不去（線程卡了）
需要等障礙物清除後才能過去（耗時任務結束）
除非你繞道而行（切到別的線程）

從語義上理解「非阻塞式掛起」，講的是「非阻塞式」這個是掛起的一個特點，也就是說，協程的掛起，就是非阻塞式的，協程是不講「阻塞式的掛起」的概念的。

我們講「非阻塞式掛起」，其實它有幾個前提：並沒有限定在一個線程裏說這件事，因爲掛起這件事，本來就是涉及到多線程。

阻塞不阻塞，都是針對單線程講的，一旦切了線程，肯定是非阻塞的，你都跑到別的線程了，之前的線程就自由了，可以繼續做別的事情了。

所以「非阻塞式掛起」，其實就是在講協程在掛起的同時切線程這件事情。

2.爲什麼要講非阻塞式掛起

協程只是在寫法上「看起來阻塞」，其實是「非阻塞」的，因爲在協程裏面它做了很多工作，其中有一個就是幫我們切線程。

讓我們來看看下面的例子：

main {
    CoroutineScope(Dispatchers.Main).launch {
        // 👇 耗時操作
        val user = suspendingRequestUser()
        updateView(user)
    }
    
    private suspend fun suspendingRequestUser() : User = withContext(Dispatchers.IO) {
        api.requestUser()
    }
}

從上面的例子可以看到，耗時操作和更新 UI 的邏輯像寫單線程一樣放在了一起，只是在外面包了一層協程。

而正是這個協程解決了原來我們單線程寫法會卡線程這件事。

3.協程與線程

在 Kotlin 裏，協程就是基於線程來實現的一種更上層的工具 API，類似於 Java 自帶的 Executor 系列 API 或者 Android 的 Handler 系列 API。

只不過呢，協程它不僅提供了方便的 API，在設計思想上是一個基於線程的上層框架，你可以理解爲新造了一些概念用來幫助你更好地使用這些 API，僅此而已。

就像 ReactiveX 一樣，爲了讓你更好地使用各種操作符 API，新造了 Observable 等概念。

4.小結

這一部分主要講的是非阻塞式掛起，掛起其實是切換線程，就是脫離了原來的線程，原來的線程該幹嘛幹嘛了，所以是非阻塞式掛起。

四、總結

協程就是切線程；
掛起就是可以自動切回來的切線程；
掛起的非阻塞式指的是它能用看起來阻塞的代碼寫出非阻塞的操作，就這麼簡單。

參考：

1，Kotlin 的協程用力瞥一眼 - 學不會協程？很可能因爲你看過的教程都是錯的
 2，Kotlin 協程的掛起好神奇好難懂？今天我把它的皮給扒了
 3，到底什麼是「非阻塞式」掛起？協程真的更輕量級嗎？
4，Kotlin 協程的實戰
 5，漫畫：什麼是協程？

向大佬們致敬。

Kotlin 協程總結

文章目錄

一、協程是什麼

1.簡介

2.協程好在哪

3.協程具體怎麼用

a.添加依賴

b.開始使用

c.suspend

4.小結

二、掛起是什麼

1.「掛起」的本質

線程：

協程：

2.怎麼就「掛起」了？

3.suspend 的意義？

4.怎麼自定義 suspend 函數？

a.什麼時候需要自定義 suspend 函數

a.具體該怎麼寫

5.小結

三、掛起的非阻塞式是怎麼回事

1.什麼是「非阻塞式掛起」

2.爲什麼要講非阻塞式掛起

3.協程與線程

4.小結

四、總結