初識 · Kotin知識點難點歸納總結

## 參考文章 [Kotlin 的協程用力瞥一眼 - 學不會協程？很可能因為你看過的教程都是錯的](https://kaixue.io/kotlin-coroutines-1/) ## 協程是什么協程并不是 Kotlin 提出來的新概念，其他的一些編程語言，例如：Go、Python 等都可以在語言層面上實現協程，甚至是 Java，也可以通過使用擴展庫來間接地支持協程。當在網上搜索協程時，我們會看到： * Kotlin 官方文檔說「本質上，協程是輕量級的線程」。 * 很多博客提到「不需要從用戶態切換到內核態」、「是協作式的」等等。作為 Kotlin 協程的初學者，這些概念并不是那么容易讓人理解。這些往往是作者根據自己的經驗總結出來的，只看結果，而**不管過程就不容易理解協程**。「協程 Coroutines」源自 Simula 和 Modula-2 語言，這個術語早在 1958 年就被[Melvin Edward Conway](https://kaixue.io/kotlin-coroutines-1/%5Bhttps://zh.wikipedia.org/wiki/%E9%A9%AC%E5%B0%94%E6%96%87%C2%B7%E5%BA%B7%E5%A8%81%5D(https://zh.wikipedia.org/wiki/%E9%A9%AC%E5%B0%94%E6%96%87%C2%B7%E5%BA%B7%E5%A8%81))發明并用于構建匯編程序，說明**協程是一種編程思想**，并不局限于特定的語言。 Go 語言也有協程，叫 Goroutines，從英文拼寫就知道它和 Coroutines 還是有些差別的（設計思想上是有關系的），否則 Kotlin 的協程完全可以叫 Koroutines 了。因此，對一個新術語，我們需要知道什么是「標準」術語，什么是變種。當我們討論協程和線程的關系時，很容易**陷入中文的誤區**，兩者都有一個「程」字，就覺得有關系，其實就英文而言，Coroutines 和 Threads 就是兩個概念。從 Android 開發者的角度去理解它們的關系： * 我們所有的代碼都是跑在線程中的，而線程是跑在進程中的。 * 協程沒有直接和操作系統關聯，但它不是空中樓閣，它也是跑在線程中的，可以是單線程，也可以是多線程。 * 單線程中的協程總的執行時間并不會比不用協程少。 * Android 系統上，如果在主線程進行網絡請求，會拋出`NetworkOnMainThreadException`，**對于在主線程上的協程也不例外，這種場景使用協程還是要切線程的**。協程**設計的初衷是為了解決并發問題，讓「協作式多任務」實現起來更加方便**。視頻里講到，**協程就是 Kotlin 提供的一套線程封裝的 API（前提是對JVM而言），但并不是說協程就是為線程而生的**。不過，我們學習 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 一樣也擺脫不了直接使用`Thead`的那些困難和不方便： * 線程什么時候執行結束 * 線程間的相互通信 * 多個線程的管理我們可以用 Java 的`Executor`線程池來進行線程管理： ~~~kotlin val executor = Executors.newCachedThreadPool() executor.execute({ ... }) ~~~ 用 Android 的`AsyncTask`來解決線程間通信： ~~~kotlin 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 那樣有效地消除回調地獄，不過無論是設計理念，還是代碼風格，兩者是有很大區別的，協程在寫法上和普通的順序代碼類似。 >[success] 這里并不會比較 RxJava 和協程哪個好，或者討論誰取代誰的問題，我這里只給出一個建議，你最好都去了解下，因為協程和 Rx 的設計思想本來就不同。下面的例子是使用協程進行網絡請求獲取用戶信息并顯示到 UI 控件上： ~~~kotlin 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`為例，來看看什么是閉包： ~~~kotlin // 創建一個 Thread 的完整寫法 Thread(object : Runnable { override fun run() { ... } }) // 滿足 SAM，先簡化為 Thread({ ... }) // 使用閉包，再簡化為 Thread { ... } ~~~ **形如`Thread {...}`這樣的結構中`{}`就是一個閉包**。 **在 Kotlin 中有這樣一個語法糖：當函數的最后一個參數是 lambda 表達式時，可以將 lambda 寫在括號外。這就是它的閉包原則**。在這里需要一個類型為`Runnable`的參數，而`Runnable`是一個接口，且只定義了一個函數`run`，這種情況滿足了 Kotlin 的[SAM](https://medium.com/tompee/idiomatic-kotlin-lambdas-and-sam-constructors-fe2075965bfb)，可以轉換成傳遞一個 lambda 表達式（第二段），因為是最后一個參數，根據閉包原則我們就可以直接寫成`Thread {...}`（第三段）的形式。對于上文所使用的`launch`函數，可以通過閉包來進行簡化： ~~~kotlin launch { ... } ~~~ ### 基本使用前面提到，**`launch`函數不是頂層函數，是不能直接用的，可以使用下面三種方法來創建協程** ~~~kotlin // 方法一，使用 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 平臺的封裝來配合使用）。關于`CoroutineScope`和`CoroutineContext`的更多內容后面的文章再講。 **協程最常用的功能是并發，而并發的典型場景就是多線程**。可以使用`Dispatchers.IO`參數把任務切到 IO 線程執行： ~~~kotlin coroutineScope.launch(Dispatchers.IO) { ... } ~~~ 也可以使用`Dispatchers.Main`參數切換到主線程： ~~~kotlin coroutineScope.launch(Dispatchers.Main) { ... } ~~~ 所以在「協程是什么」一節中講到的異步請求的例子完整寫出來是這樣的： ~~~kotlin coroutineScope.launch(Dispatchers.Main) { // 在主線程開啟協程 val user = api.getUser() // IO 線程執行網絡請求 nameTv.text = user.name // 主線程更新 UI } ~~~ 而通過 Java 實現以上邏輯，我們通常需要這樣寫： ~~~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 協程，多層網絡請求只需要這么寫： ~~~kotlin coroutineScope.launch(Dispatchers.Main) { // 開始協程：主線程 val token = api.getToken() // 網絡請求：IO 線程 val user = api.getUser(token) // 網絡請求：IO 線程 nameTv.text = user.name // 更新 UI：主線程 } ~~~ 如果遇到的場景是多個網絡請求需要等待所有請求結束之后再對 UI 進行更新。比如以下兩個請求 ~~~kotlin api.getAvatar(user, callback) api.getCompanyLogo(user, callback) ~~~ 如果使用回調式的寫法，那么代碼可能寫起來既困難又別扭。于是我們可能會選擇妥協，通過先后請求代替同時請求： ~~~kotlin api.getAvatar(user) { avatar -> api.getCompanyLogo(user) { logo -> show(merge(avatar, logo)) } } ~~~ 在實際開發中如果這樣寫，本來能夠并行處理的請求被強制通過串行的方式去實現，可能會導致等待時間長了一倍，也就是性能差了一倍。而如果使用協程，可以直接把兩個并行請求寫成上下兩行，最后再把結果進行合并即可： ~~~kotlin 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`函數實現線程切換的功能： ~~~kotlin coroutineScope.launch(Dispatchers.IO) { ... } ~~~ **這個`launch`函數，它具體的含義是：我要創建一個新的協程，并在指定的線程上運行它。這個被創建、被運行的所謂「協程」是誰？就是你傳給`launch`的那些代碼，這一段連續代碼叫做一個「協程」**。所以，**什么時候用協程？當你需要切線程或者指定線程的時候。你要在后臺執行任務？切！** ~~~kotlin launch(Dispatchers.IO) { val image = getImage(imageId) } ~~~ 然后需要在前臺更新界面？再切！ ~~~kotlin coroutineScope.launch(Dispatchers.IO) { val image = getImage(imageId) launch(Dispatchers.Main) { avatarIv.setImageBitmap(image) } } ~~~ 好像有點不對勁？這不還是有嵌套嘛。 **如果只是使用`launch`函數，協程并不能比線程做更多的事**。不過協程中卻有一個很實用的函數：**`withContext`。這個函數可以切換到指定的線程，并在閉包內的邏輯執行結束之后，自動把線程切回去繼續執行**。那么可以將上面的代碼寫成這樣： ~~~kotlin coroutineScope.launch(Dispatchers.Main) { // ?? 在 UI 線程開始 val image = withContext(Dispatchers.IO) { // ?? 切換到 IO 線程，并在執行完成后切回 UI 線程 getImage(imageId) // ?? 將會運行在 IO 線程 } avatarIv.setImageBitmap(image) // ?? 回到 UI 線程更新 UI } ~~~ 這種寫法看上去好像和剛才那種區別不大，但如果你需要頻繁地進行線程切換，這種寫法的優勢就會體現出來。可以參考下面的對比： ~~~kotlin // 第一種寫法 coroutineScope.launch(Dispatchers.IO) { ... launch(Dispatchers.Main){ ... launch(Dispatchers.IO) { ... launch(Dispatchers.Main) { ... } } } } // 通過第二種寫法來實現相同的邏輯 coroutineScope.launch(Dispatchers.Main) { ... withContext(Dispatchers.IO) { ... } ... withContext(Dispatchers.IO) { ... } ... } ~~~ **由于可以"自動切回來"，消除了并發代碼在協作時的嵌套**。由于消除了嵌套關系，我們甚至可以把`withContext`放進一個單獨的函數里面： ~~~kotlin launch(Dispatchers.Main) { // ?? 在 UI 線程開始 val image = getImage(imageId) avatarIv.setImageBitmap(image) // ?? 執行結束后，自動切換回 UI 線程 } // ?? fun getImage(imageId: Int) = withContext(Dispatchers.IO) { ... } ~~~ 這就是之前說的「**用同步的方式寫異步的代碼**」了。不過如果只是這樣寫，編譯器是會報錯的： ~~~kotlin 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 協程的文章和演講都會提到它。它的中文意思是「暫停」或者「可掛起」。如果你去看一些技術博客或官方文檔的時候，大概可以了解到：**「代碼執行到`suspend`函數的時候會『掛起』，并且這個『掛起』是非阻塞式的，它不會阻塞你當前的線程。」** 上面報錯的代碼，其實只需要在前面加一個`suspend`就能夠編譯通過： ~~~kotlin //?? suspend fun getImage(imageId: Int) = withContext(Dispatchers.IO) { ... } ~~~ 本篇文章到此結束，而`suspend`具體是什么，「非阻塞式」又是怎么回事，函數怎么被掛起，這些疑問的答案，將在下一篇文章全部揭曉。