協程是什么
協程并不是 Kotlin 提出來的新概念，其他的一些編程語言，例如：Go、Python 等都可以在語言層面上實現協程，甚至是 Java，也可以通過使用擴展庫來間接地支持協程。
當在網上搜索協程時，我們會看到：
- Kotlin 官方文檔說「本質上，協程是輕量級的線程」。
- 很多博客提到「不需要從用戶態切換到內核態」、「是協作式的」等等。
作為 Kotlin 協程的初學者，這些概念并不是那么容易讓人理解。這些往往是作者根據自己的經驗總結出來的，只看結果，而不管過程就不容易理解協程。
「協程 Coroutines」源自 Simula 和 Modula-2 語言，這個術語早在 1958 年就被 Melvin Edward Conway 發明并用于構建匯編程序，說明協程是一種編程思想，并不局限于特定的語言。
Go 語言也有協程，叫 Goroutines，從英文拼寫就知道它和 Coroutines 還是有些差別的（設計思想上是有關系的），否則 Kotlin 的協程完全可以叫 Koroutines 了。
因此，對一個新術語，我們需要知道什么是「標準」術語，什么是變種。
當我們討論協程和線程的關系時，很容易陷入中文的誤區，兩者都有一個「程」字，就覺得有關系，其實就英文而言，Coroutines 和 Threads 就是兩個概念。
從 Android 開發者的角度去理解它們的關系：
- 我們所有的代碼都是跑在線程中的，而線程是跑在進程中的。
- 協程沒有直接和操作系統關聯，但它不是空中樓閣，它也是跑在線程中的，可以是單線程，也可以是多線程。
- 單線程中的協程總的執行時間并不會比不用協程少。
- Android 系統上，如果在主線程進行網絡請求，會拋出
NetworkOnMainThreadException，對于在主線程上的協程也不例外，這種場景使用協程還是要切線程的。
協程設計的初衷是為了解決并發問題，讓 「協作式多任務」 實現起來更加方便。這里就先不展開「協作式多任務」的概念，等我們學會了怎么用再講。
雖說協程就是 Kotlin 提供的一套線程封裝的 API，但并不是說協程就是為線程而生的。
不過，我們學習 Kotlin 中的協程，一開始確實可以從線程控制的角度來切入。因為在 Kotlin 中，協程的一個典型的使用場景就是線程控制。就像 Java 中的 Executor 和 Android 中的 AsyncTask，Kotlin 中的協程也有對 Thread API 的封裝，讓我們可以在寫代碼時，不用關注多線程就能夠很方便地寫出并發操作。
在 Java 中要實現并發操作通常需要開啟一個 Thread ：
// java
new Thread(new Runnable() {
@Override
public void run() {
...
}
}).start();
這里僅僅只是開啟了一個新線程，至于它何時結束、執行結果怎么樣，我們在主線程中是無法直接知道的。
Kotlin 中同樣可以通過線程的方式去寫：
// Kotlin
Thread({
...
}).start()
可以看到，和 Java 一樣也擺脫不了直接使用 Thread 的那些困難和不方便：
- 線程什么時候執行結束
- 線程間的相互通信
- 多個線程的管理
我們可以用 Java 的 Executor 線程池來進行線程管理：
val executor = Executors.newCachedThreadPool()
executor.execute({
...
})
用 Android 的 AsyncTask 來解決線程間通信：
object : AsyncTask<T0, T1, T2> {
override fun doInBackground(vararg args: T0): String { ... }
override fun onProgressUpdate(vararg args: T1) { ... }
override fun onPostExecute(t3: T3) { ... }
}
AsyncTask 是 Android 對線程池 Executor 的封裝，但它的缺點也很明顯：
- 需要處理很多回調，如果業務多則容易陷入「回調地獄」。
- 硬是把業務拆分成了前臺、中間更新、后臺三個函數。
看到這里你很自然想到使用 RxJava 解決回調地獄，它確實可以很方便地解決上面的問題。
RxJava，準確來講是 ReactiveX 在 Java 上的實現，是一種響應式程序框架，我們通過它提供的「Observable」的編程范式進行鏈式調用，可以很好地消除回調。
使用協程，同樣可以像 Rx 那樣有效地消除回調地獄，不過無論是設計理念，還是代碼風格，兩者是有很大區別的，協程在寫法上和普通的順序代碼類似。
這里并不會比較 RxJava 和協程哪個好，或者討論誰取代誰的問題，我這里只給出一個建議，你最好都去了解下，因為協程和 Rx 的設計思想本來就不同。
下面的例子是使用協程進行網絡請求獲取用戶信息并顯示到 UI 控件上：
???
launch({
val user = api.getUser() // ?? 網絡請求（IO 線程）
nameTv.text = user.name // ?? 更新 UI（主線程）
})
這里只是展示了一個代碼片段，launch 并不是一個頂層函數，它必須在一個對象中使用，我們之后再講，這里只關心它內部業務邏輯的寫法。
launch 函數加上實現在 {} 中具體的邏輯，就構成了一個協程。
通常我們做網絡請求，要不就傳一個 callback，要不就是在 IO 線程里進行阻塞式的同步調用，而在這段代碼中，上下兩個語句分別工作在兩個線程里，但寫法上看起來和普通的單線程代碼一樣。
這里的 api.getUser 是一個掛起函數，所以能夠保證 nameTv.text 的正確賦值，這就涉及到了協程中最著名的「非阻塞式掛起」。這個名詞看起來不是那么容易理解，我們后續的文章會專門對這個概念進行講解。現在先把這個概念放下，只需要記住協程就是這樣寫的就行了。
這種「用同步的方式寫異步的代碼」看起來很方便吧，那么我們來看看協程具體好在哪。
協程好在哪
開始之前
在講之前，我們需要先了解一下「閉包」這個概念，調用 Kotlin 協程中的 API，經常會用到閉包寫法。
其實閉包并不是 Kotlin 中的新概念，在 Java 8 中就已經支持。
我們先以 Thread 為例，來看看什么是閉包：
???
// 創建一個 Thread 的完整寫法
Thread(object : Runnable {
override fun run() {
...
}
})
// 滿足 SAM，先簡化為
Thread({
...
})
// 使用閉包，再簡化為
Thread {
...
}
形如 Thread {...} 這樣的結構中 {} 就是一個閉包。
在 Kotlin 中有這樣一個語法糖：當函數的最后一個參數是 lambda 表達式時，可以將 lambda 寫在括號外。這就是它的閉包原則。
在這里需要一個類型為 Runnable 的參數，而 Runnable 是一個接口，且只定義了一個函數 run，這種情況滿足了 Kotlin 的 SAM，可以轉換成傳遞一個 lambda 表達式（第二段），因為是最后一個參數，根據閉包原則我們就可以直接寫成 Thread {...}（第三段） 的形式。
對于上文所使用的 launch 函數，可以通過閉包來進行簡化 ：
???
launch {
...
}
基本使用
前面提到，launch 函數不是頂層函數，是不能直接用的，可以使用下面四種方法來創建協程：
???
// 方法一：使用 runBlocking 頂層函數
runBlocking {
getImage(imageId)
}
// 方法二：使用 GlobalScope 單例對象：可以直接調用 launch 開啟協程
GlobalScope.launch {
getImage(imageId)
}
// 方法三：自行通過 CoroutineContext 創建一個 CoroutineScope 對象
// 需要一個類型為 CoroutineContext 的參數
val coroutineScope = CoroutineScope(context)
coroutineScope.launch {
getImage(imageId)
}
//方法四：async 函數啟動新的協程，通過 await 獲取結果
coroutineScope.launch(Dispatchers.Main) {
// async 函數啟動新的協程
val avatar: Deferred = async { api.getAvatar(user) } // 獲取用戶頭像
val logo: Deferred = async { api.getCompanyLogo(user) } // 獲取用戶所在公司的 logo
// 獲取返回值
show(avatar.await(), logo.await()) // 更新 UI
}
- 方法一通常適用于單元測試的場景，而業務開發中不會用到這種方法，因為它是線程阻塞的。
- 方法二和使用
runBlocking的區別在于不會阻塞線程。但在 Android 開發中同樣不推薦這種用法，因為它的生命周期會和 app 一致，且不能取消（什么是協程的取消后面的文章會講）。 - 方法三是比較推薦的使用方法，我們可以通過
context參數去管理和控制協程的生命周期（這里的context和 Android 里的不是一個東西，是一個更通用的概念，會有一個 Android 平臺的封裝來配合使用）。
關于CoroutineScope和CoroutineContext的更多內容后面的文章再講。
接下來我們主要來對比 launch 與 async 這兩個函數。
相同點：它們都可以用來啟動一個協程，返回的都是
Coroutine，我們這里不需要糾結具體是返回哪個類。不同點：
async返回的Coroutine多實現了Deferred接口。
可以看到 方法四中 avatar 和 logo 的類型可以聲明為 Deferred ，通過 await 獲取結果并且更新到 UI 上顯示。
await 函數簽名如下：
public suspend fun await(): T
關于 Deferred 更深入的知識就不在這里過多闡述，它的意思就是延遲，也就是結果稍后才能拿到。
我們調用 Deferred.await() 就可以得到結果了。
協程最常用的功能是并發，而并發的典型場景就是多線程。可以使用 Dispatchers.IO 參數把任務切到 IO 線程執行：
coroutineScope.launch(Dispatchers.IO) {
...
}
也可以使用 Dispatchers.Main 參數切換到主線程：
???
coroutineScope.launch(Dispatchers.Main) {
...
}
所以在「協程是什么」一節中講到的異步請求的例子完整寫出來是這樣的：
???
coroutineScope.launch(Dispatchers.Main) { // 在主線程開啟協程
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) {
...
}
});
這種回調式的寫法，打破了代碼的順序結構和完整性，讀起來相當難受。
協程的「1 到 0」
對于回調式的寫法，如果并發場景再復雜一些，代碼的嵌套可能會更多，這樣的話維護起來就非常麻煩。但如果你使用了 Kotlin 協程，多層網絡請求只需要這么寫：
???
coroutineScope.launch(Dispatchers.Main) { // 開始協程：主線程
val token = api.getToken() // 網絡請求：IO 線程
val user = api.getUser(token) // 網絡請求：IO 線程
nameTv.text = user.name // 更新 UI：主線程
}
如果遇到的場景是多個網絡請求需要等待所有請求結束之后再對 UI 進行更新。比如以下兩個請求：
???
api.getAvatar(user, callback)
api.getCompanyLogo(user, callback)
如果使用回調式的寫法，那么代碼可能寫起來既困難又別扭。于是我們可能會選擇妥協，通過先后請求代替同時請求：
???
api.getAvatar(user) { avatar ->
api.getCompanyLogo(user) { logo ->
show(merge(avatar, logo))
}
}
在實際開發中如果這樣寫，本來能夠并行處理的請求被強制通過串行的方式去實現，可能會導致等待時間長了一倍，也就是性能差了一倍。
而如果使用協程，可以直接把兩個并行請求寫成上下兩行，最后再把結果進行合并，即采用上述的方法四：
???
coroutineScope.launch(Dispatchers.Main) {
// ?? async 函數之后再講
val avatar = async { api.getAvatar(user) } // 獲取用戶頭像
val logo = async { api.getCompanyLogo(user) } // 獲取用戶所在公司的 logo
val merged = suspendingMerge(avatar, logo) // 合并結果
// ??
show(merged) // 更新 UI
}
可以看到，即便是比較復雜的并行網絡請求，也能夠通過協程寫出結構清晰的代碼。需要注意的是 suspendingMerge 并不是協程 API 中提供的方法，而是我們自定義的一個可「掛起」的結果合并方法。
讓復雜的并發代碼，寫起來變得簡單且清晰，是協程的優勢。
這里，兩個沒有相關性的后臺任務，因為用了協程，被安排得明明白白，互相之間配合得很好，也就是我們之前說的「協作式任務」。
本來需要回調，現在直接沒有回調了，這種從 1 到 0 的設計思想真的妙哉。
在了解了協程的作用和優勢之后，我們再來看看協程是怎么使用的。
協程怎么用
在項目中配置對 Kotlin 協程的支持
在使用協程之前，我們需要在 build.gradle 文件中增加對 Kotlin 協程的依賴：
- 項目根目錄下的
build.gradle:
//groovy
buildscript {
...
ext.kotlin_coroutines = '1.3.1'
...
}
- Module 下的
build.gradle:
//Groovy
dependencies {
...
// ?? 依賴協程核心庫
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$kotlin_coroutines"
// ?? 依賴當前平臺所對應的平臺庫
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$kotlin_coroutines"
...
}
Kotlin 協程是以官方擴展庫的形式進行支持的。而且，我們所使用的「核心庫」和 「平臺庫」的版本應該保持一致。
- 核心庫中包含的代碼主要是協程的公共 API 部分。有了這一層公共代碼，才使得協程在各個平臺上的接口得到統一。
- 平臺庫中包含的代碼主要是協程框架在具體平臺的具體實現方式。因為多線程在各個平臺的實現方式是有所差異的。
完成了以上的準備工作就可以開始使用協程了。
開始使用協程
協程最簡單的使用方法，其實在前面章節就已經看到了。我們可以通過一個 launch 函數實現線程切換的功能：
???
coroutineScope.launch(Dispatchers.IO) {
...
}
這個 launch 函數，它具體的含義是：我要創建一個新的協程，并在指定的線程上運行它。這個被創建、被運行的所謂「協程」是誰？就是你傳給 launch 的那些代碼，這一段連續代碼叫做一個「協程」。
所以，什么時候用協程？當你需要切線程或者指定線程的時候。你要在后臺執行任務？切！
???
launch(Dispatchers.IO) {
val image = getImage(imageId)
}
然后需要在前臺更新界面？再切！
???
coroutineScope.launch(Dispatchers.IO) {
val image = getImage(imageId)
launch(Dispatchers.Main) {
avatarIv.setImageBitmap(image)
}
}
好像有點不對勁？這不還是有嵌套嘛。
如果只是使用 launch 函數，協程并不能比線程做更多的事。不過協程中卻有一個很實用的函數：withContext 。這個函數可以切換到指定的線程，并在閉包內的邏輯執行結束之后，自動把線程切回去繼續執行。那么可以將上面的代碼寫成這樣：
???
coroutineScope.launch(Dispatchers.Main) { // ?? 在 UI 線程開始
val image = withContext(Dispatchers.IO) { // ?? 切換到 IO 線程，并在執行完成后切回 UI 線程
getImage(imageId) // ?? 將會運行在 IO 線程
}
avatarIv.setImageBitmap(image) // ?? 回到 UI 線程更新 UI
}
這種寫法看上去好像和剛才那種區別不大，但如果你需要頻繁地進行線程切換，這種寫法的優勢就會體現出來。可以參考下面的對比：
???
// 第一種寫法
coroutineScope.launch(Dispatchers.IO) {
...
launch(Dispatchers.Main){
...
launch(Dispatchers.IO) {
...
launch(Dispatchers.Main) {
...
}
}
}
}
// 通過第二種寫法來實現相同的邏輯
coroutineScope.launch(Dispatchers.Main) {
...
withContext(Dispatchers.IO) {
...
}
...
withContext(Dispatchers.IO) {
...
}
...
}
由于可以"自動切回來"，消除了并發代碼在協作時的嵌套。由于消除了嵌套關系，我們甚至可以把 withContext 放進一個單獨的函數里面：
???
launch(Dispatchers.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 函數中調用。
suspend
suspend 是 Kotlin 協程最核心的關鍵字，幾乎所有介紹 Kotlin 協程的文章和演講都會提到它。它的中文意思是「暫?！够蛘摺缚蓲炱稹埂Ｈ绻闳タ匆恍┘夹g博客或官方文檔的時候，大概可以了解到：當「代碼執行到 suspend 函數的時候所在的協程就會『掛起』，并且這個『掛起』是非阻塞式的，它不會阻塞你當前的線程?！?/p>
上面報錯的代碼，其實只需要在前面加一個 suspend 就能夠編譯通過：
???
suspend fun getImage(imageId: Int) = withContext(Dispatchers.IO) {
...
}
所以接下來，我們的核心內容就是來好好說一說這個「掛起」。
「掛起」的本質
什么是掛起？掛起，就是一個稍后會被自動切回來的線程調度操作。
協程中「掛起」的對象到底是什么？掛起線程，還是掛起函數？都不對，我們掛起的對象是協程。
還記得協程是什么嗎？啟動一個協程可以使用 launch 或者 async 函數，協程其實就是這兩個函數中閉包的代碼塊。
launch ，async 或者其他函數創建的協程，在執行到某一個 suspend 函數的時候，這個協程會被「suspend」，也就是被掛起。
那此時又是從哪里掛起？從當前線程掛起。換句話說，就是這個協程從正在執行它的線程上脫離。
注意，不是這個協程停下來了！是脫離，當前線程不再管這個協程要去做什么了。
suspend 是有暫停的意思，但我們在協程中應該理解為：當線程執行到協程的 suspend 函數的時候，暫時不繼續執行協程代碼了。
我們先讓時間靜止，然后兵分兩路，分別看看這兩個互相脫離的線程和協程接下來將會發生什么事情：
線程：
前面我們提到，掛起會讓協程從正在執行它的線程上脫離，具體到代碼其實是：
協程的代碼塊中，線程執行到了 suspend 函數這里的時候，就暫時不再執行剩余的協程代碼，跳出協程的代碼塊。
那線程接下來會做什么呢？
如果它是一個后臺線程：
- 要么無事可做，被系統回收
- 要么繼續執行別的后臺任務
跟 Java 線程池里的線程在工作結束之后是完全一樣的：回收或者再利用。
如果這個線程它是 Android 的主線程，那它接下來就會繼續回去工作：也就是一秒鐘 60 次的界面刷新任務。
一個常見的場景是，獲取一個圖片，然后顯示出來：
???
// 主線程中
GlobalScope.launch(Dispatchers.Main) {
val image = suspendingGetImage(imageId) // 獲取圖片
avatarIv.setImageBitmap(image) // 顯示出來
}
suspend fun suspendingGetImage(id: String) = withContext(Dispatchers.IO) {
...
}
這段執行在主線程的協程，它實質上會往你的主線程 post 一個 Runnable，這個 Runnable 就是你的協程代碼：
???
handler.post {
val image = suspendingGetImage(imageId)
avatarIv.setImageBitmap(image)
}
當這個協程被掛起的時候，就是主線程 post 的這個 Runnable 提前結束，然后繼續執行它界面刷新的任務。
關于線程，我們就看完了。
這個時候你可能會有一個疑問，那 launch 包裹的剩下代碼怎么辦？
所以接下來，我們來看看協程這一邊。
協程：
線程的代碼在到達 suspend 函數的時候被掐斷，接下來協程會從這個 suspend 函數開始繼續往下執行，不過是在指定的線程。
誰指定的？是 suspend 函數指定的，比如我們這個例子中，函數內部的 withContext 傳入的 Dispatchers.IO 所指定的 IO 線程。
Dispatchers 調度器，它可以將協程限制在一個特定的線程執行，或者將它分派到一個線程池，或者讓它不受限制地運行，關于 Dispatchers 這里先不展開了。
那我們平日里常用到的調度器有哪些？
常用的 Dispatchers ，有以下三種：
-
Dispatchers.Main：Android 中的主線程 -
Dispatchers.IO：針對磁盤和網絡 IO 進行了優化，適合 IO 密集型的任務，比如：讀寫文件，操作數據庫以及網絡請求 -
Dispatchers.Default：適合 CPU 密集型的任務，比如計算
回到我們的協程，它從 suspend 函數開始脫離啟動它的線程，繼續執行在 Dispatchers 所指定的 IO 線程。
緊接著在 suspend 函數執行完成之后，協程為我們做的最爽的事就來了：會自動幫我們把線程再切回來。
這個「切回來」是什么意思？
我們的協程原本是運行在主線程的，當代碼遇到 suspend 函數的時候，發生線程切換，根據 Dispatchers 切換到了 IO 線程；
當這個函數執行完畢后，線程又切了回來，「切回來」也就是協程會幫我再 post 一個 Runnable，讓我剩下的代碼繼續回到主線程去執行。
我們從線程和協程的兩個角度都分析完成后，終于可以對協程的「掛起」suspend 做一個解釋：
協程在執行到有 suspend 標記的函數的時候，會被 suspend 也就是被掛起，而所謂的被掛起，就是切個線程；
不過區別在于，掛起函數在執行完成之后，協程會重新切回它原先的線程。
再簡單來講，在 Kotlin 中所謂的掛起，就是一個稍后會被自動切回來的線程調度操作。
這個「切回來」的動作，在 Kotlin 里叫做 resume，恢復。
通過剛才的分析我們知道：掛起之后是需要恢復。
而恢復這個功能是協程的，如果你不在協程里面調用，恢復這個功能沒法實現，所以也就回答了這個問題：為什么掛起函數必須在協程或者另一個掛起函數里被調用。
再細想下這個邏輯：一個掛起函數要么在協程里被調用，要么在另一個掛起函數里被調用，那么它其實直接或者間接地，總是會在一個協程里被調用的。
所以，要求 suspend 函數只能在協程里或者另一個 suspend 函數里被調用，還是為了要讓協程能夠在 suspend 函數切換線程之后再切回來。
怎么就「掛起」了？
我們了解到了什么是「掛起」后，再接著看看這個「掛起」是怎么做到的。
先隨便寫一個自定義的 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 函數才行。
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 才是有意義的。
怎么自定義 suspend 函數？
在了解了 suspend 關鍵字的來龍去脈之后，我們就可以進入下一個話題了：怎么自定義 suspend 函數。
這個「怎么自定義」其實分為兩個問題：
- 什么時候需要自定義
suspend函數？ - 具體該怎么寫呢？
什么時候需要自定義 suspend 函數
如果你的某個函數比較耗時，也就是要等的操作，那就把它寫成 suspend 函數。這就是原則。
耗時操作一般分為兩類：I/O 操作和 CPU 計算工作。比如文件的讀寫、網絡交互、圖片的模糊處理，都是耗時的，通通可以把它們寫進 suspend 函數里。
另外這個「耗時」還有一種特殊情況，就是這件事本身做起來并不慢，但它需要等待，比如 5 秒鐘之后再做這個操作。這種也是 suspend 函數的應用場景。
具體該怎么寫
給函數加上 suspend 關鍵字，然后在 withContext 把函數的內容包住就可以了。
提到用 withContext是因為它在掛起函數里功能最簡單直接：把線程自動切走和切回。
當然并不是只有 withContext 這一個函數來輔助我們實現自定義的 suspend 函數，比如還有一個掛起函數叫 delay，它的作用是等待一段時間后再繼續往下執行代碼。
使用它就可以實現剛才提到的等待類型的耗時操作：
???
suspend fun suspendUntilDone() {
while (!done) {
delay(5)
}
}
這些東西，在我們初步使用協程的時候不用立馬接觸，可以先把協程最基本的方法和概念理清楚。
好，關于協程中的「掛起」我們就解釋到這里。
可能你心中還會存在一些疑惑：
- 協程中掛起的「非阻塞式」到底是怎么回事？
- 協程和 RxJava 在切換線程方面功能是一樣的，都能讓你寫出避免嵌套回調的復雜并發代碼，那協程還有哪些優勢，或者讓開發者使用協程的理由？
非阻塞式掛起
什么是「非阻塞式掛起」
非阻塞式是相對阻塞式而言的。
編程語言中的很多概念其實都來源于生活，就像脫口秀的段子一樣。
線程阻塞很好理解，現實中的例子就是交通堵塞，它的核心有 3 點：
前面有障礙物，你過不去（線程卡了）
需要等障礙物清除后才能過去（耗時任務結束）
除非你繞道而行（切到別的線程）
從語義上理解「非阻塞式掛起」，講的是「非阻塞式」這個是掛起的一個特點，也就是說，協程的掛起，就是非阻塞式的，協程是不講「阻塞式的掛起」的概念的。
我們講「非阻塞式掛起」，其實它有幾個前提：并沒有限定在一個線程里說這件事，因為掛起這件事，本來就是涉及到多線程。
就像視頻里講的，阻塞不阻塞，都是針對單線程講的，一旦切了線程，肯定是非阻塞的，你都跑到別的線程了，之前的線程就自由了，可以繼續做別的事情了。
所以「非阻塞式掛起」，其實就是在講協程在掛起的同時切線程這件事情。
為什么要講非阻塞式掛起
因為它在寫法上和單線程的阻塞式是一樣的。
協程只是在寫法上「看起來阻塞」，其實是「非阻塞」的，因為在協程里面它做了很多工作，其中有一個就是幫我們切線程。
掛起，重點是說切線程先切過去，然后再切回來。
非阻塞式，重點是說線程雖然會切，但寫法上和普通的單線程差不多。
讓我們來看看下面的例子：
???
main {
GlobalScope.launch(Dispatchers.Main) {
// ?? 耗時操作
val user = suspendingRequestUser()
updateView(user)
}
private suspend fun suspendingRequestUser() : User = withContext(Dispatchers.IO) {
api.requestUser()
}
}
從上面的例子可以看到，耗時操作和更新 UI 的邏輯像寫單線程一樣放在了一起，只是在外面包了一層協程。
而正是這個協程解決了原來我們單線程寫法會卡線程這件事。
阻塞的本質
首先，所有的代碼本質上都是阻塞式的，而只有比較耗時的代碼才會導致人類可感知的等待，比如在主線程上做一個耗時 50 ms 的操作會導致界面卡掉幾幀，這種是我們人眼能觀察出來的，而這就是我們通常意義所說的「阻塞」。
舉個例子，當你開發的 app 在性能好的手機上很流暢，在性能差的老手機上會卡頓，就是在說同一行代碼執行的時間不一樣。
視頻中講了一個網絡 IO 的例子，IO 阻塞更多是反映在「等」這件事情上，它的性能瓶頸是和網絡的數據交換，你切多少個線程都沒用，該花的時間一點都少不了。
而這跟協程半毛錢關系沒有，切線程解決不了的事情，協程也解決不了。
協程與線程
Kotlin 協程和線程是無法脫離開講的。
別的語言我不說，在 Kotlin 里，協程就是基于線程來實現的一種更上層的工具 API，類似于 Java 自帶的 Executor 系列 API 或者 Android 的 Handler 系列 API。
只不過呢，協程它不僅提供了方便的 API，在設計思想上是一個基于線程的上層框架，你可以理解為新造了一些概念用來幫助你更好地使用這些 API，僅此而已。
就像 ReactiveX 一樣，為了讓你更好地使用各種操作符 API，新造了 Observable 等概念。
說到這里，Kotlin 協程的三大疑問：協程是什么、掛起是什么、掛起的非阻塞式是怎么回事，就已經全部講完了。非常簡單：
協程就是切線程；
掛起就是可以自動切回來的切線程；
掛起的非阻塞式指的是它能用看起來阻塞的代碼寫出非阻塞的操作，就這么簡單。
還糾正了官方文檔里面的一個錯誤，這里就不再重復了，最后想表達一點：
Kotlin 協程并沒有脫離 Kotlin 或者 JVM 創造新的東西，它只是將多線程的開發變得更簡單了，可以說是因為 Kotlin 的誕生而順其自然出現的東西，從語法上看它很神奇，但從原理上講，它并不是魔術。
