Kotlin協程-從理論到實戰-有解無憂

上一篇文章從理論上對Kotlin協程進行了部分說明，本文將在上一篇的基礎上，從實戰出發，繼續協程之旅，

從源頭說起

在Kotlin中，要想使用協程，首先需要使用協程創建器創建，但還有個前提——協程作用域(CoroutineScope)，在早期的Kotlin實作中，協程創建器是一等函式，也就是說我們隨時隨地可以通過協程創建器創建協程，但在協程正式發布以后，協程創建器需要在協程作用域物件上才能創建了，Kotlin添加了協程作用域來實作結構化并發，什么是結構化并發呢，通俗地說就是正確實施多個協程監控、管理的能力，在實際業務中，我們可能需要創建多個協程物件來完成不同的作業，為了對這些不相關的協程管理起來，Kotlin引入了協程作用域，通過某個協程作用域創建的協程都會被它管理著，在條件滿足的時候，執行每個協程的取消作業或者結束自己，

為了方便我們直接上手，官方提供了MainScope和GlobalScope供我們使用，正如名字那樣，他們分別有不同的應用場景，前者比較適合用在UI相關的類中，而后者適用于在整個應用生命周期中都需要存活的類中，當然，對于Android開發者，其實我們有更好的選擇——使用ViewModel的Kotlin擴展，它不僅有著全部的協程作用域功能，開箱即用，而且還在onCleared方法中實作了自動取消，

創建協程

有了協程作用域，那我們來創建一個最簡單的協程吧，

viewModelScope.launch{
    //這里就是協程代碼啦啦啦啦
    delay(2000)
    System.out.println("Hello World")
}

launch創建并啟動了一個協程，協程啟動兩秒后，在控制抬列印了Hello World，然后協程就結束了（協程是有完整生命周期的），這個協程完成的作業有限，我們可以使用執行緒完成相同的功能:

thread {
            Thread.sleep(2000)
            System.out.println("Hello World")
        }

我們可以看到，除去構建函式，兩段代碼唯一的區別就是延遲函式——delay和Thread.sleep.從功能上看他們都是讓后面的代碼延遲執行，但是效果卻是不一樣的，前者不會阻塞執行緒，這段代碼其實是放在主執行緒里面執行的，但是它不會影響到UI的繪制，而后者假如把它放在主執行緒執行的話，應用會出現兩秒的無回應，Kotlin把這種不會阻塞當前執行緒執行的函式稱之為掛起函式，掛起函式可以在掛起點斷開與當前執行緒的聯系，讓執行緒空閑下來完成其他的操作，當條件滿足后，掛起函式重新在掛起點恢復，接著往下執行后面的代碼，

還有個小問題沒有解決，在上一篇文章中，我曾經說過，掛起函式只能在掛起函式中執行，既然delay是掛起函式，那么反推，我們的代碼塊也應該是個掛起函式，而這個掛起函式就是所謂的協程體，

讓協程跨執行緒作業

如果你看到上面的代碼，然后轉手在協程體里面寫個網路請求的話，你會發現，你的應用崩潰了，這是怎么回事呢？因為協程雖然不會阻塞主執行緒，但是主執行緒是不允許進行網路請求的，如果這時你就急著下了協程沒啥用的結論，那么你就膚淺了，讓我們稍微改一改上面的代碼，讓它運行在子執行緒吧，

viewModelScope.launch (Dispatchers.IO){
    //這里就是協程代碼啦啦啦啦
    delay(2000)
    System.out.println("Hello World")
}

很好，現在協程體里面的網路請求可以順利執行了，但是很快有讀者就會發現新問題了——我怎么把網路請求的結果傳回主執行緒呢，難不成還搞個Handler,那和直接使用執行緒有什么區別，辣雞協程，嘿，別急，這個協程其實也為客官處理好了，讓我們再次改造一下代碼：

viewModelScope.launch (Dispatchers.IO){
    //這里就是協程代碼啦啦啦啦，這里是在子執行緒執行的代碼哦
    //假裝這個是網路請求吧
    delay(2000)
    withContext(Dispatchers.Main) {
        //哦豁豁，這里竟然運行在主執行緒哦
        System.out.println("Hello World")
    }
}

很好，我們可以愉快地使用協程處理網路請求了，那么這些魔法是怎么發生的呢，停下腳步，我們來重新審視一下上面的代碼，

首先，相比于最開始的代碼，我們的代碼里多了兩個物件，一個方法呼叫，首先我們來看那兩個物件，從名字中我們不難猜到它就是調度執行緒的，
Kotlin提供了四個常用的實作

Default,它是標準協程構建者默認使用的調度器，使用共享的執行緒池作業，適用于計算型的任務；
Main,它是代表UI執行緒的調度器，通常來說只有一個執行緒，使用這個調度器就可以直接在協程中操作UI;
Unconfined,它沒有限定執行緒范圍，它在哪個執行緒中被呼叫就會在哪個執行緒里執行完初始的代碼，直到遇到掛起函式，隨后它會使用掛起函式指定的調度器恢復，這個程序可以一直持續下去，
IO,是用來承載阻塞的IO操作的，如檔案讀寫，網路連接等，是我們比較常用的調度器，

所以那兩個調度器物件是讓協程切換作業環境的魔法，接下來還有一個方法呼叫沒有解釋，withContext的作用是將當前的協程調度器切換到指定的調度器上，用這個調度器接著執行構建塊中的代碼，同時它也是一個掛起函式，提到掛起函式，我們就該想到，它是可恢復的，所以當這個掛起函式的代碼塊執行完成之后，它會自動恢復成原來的調度器，接著往下執行，

用協程串聯兩個異步操作

在專案開發中，還有一種常見的應用場景，客戶端需要先請求一些配置資訊，然后利用配置資訊再請求真正的內容資訊，這個程序描述起來是串行的，但是代碼寫起來卻是割裂的，需要在第一個網路請求的回呼中處理和發起第二個請求，然后在第二個回呼中獲取真正需要展示的資料，可能這個程序還會加個存庫，或者觸發另外請求的作業，那么完了，這代碼沒法看了，這放在以前，這種情況通常會使用RxJava，但是RxJava的代碼可讀性也還是差點意思，那么Kotlin協程可以寫成什么樣呢？

viewModelScope.launch(Dispatchers.IO) {
            val retrofit=Retrofit.Builder().build()
            val apiUser=retrofit.create(APIUser::class.java)
            val user=api.current()
            val detail=api.userDetail(user.id)
            withContext(Dispatchers.Main) {
                userLiveData.value=https://www.cnblogs.com/honguilee/archive/2023/06/16/detail
            }
        }

這和我們寫一般的同步代碼一摸一樣，沒有回呼，也不需要付出其他代價，這個程序甚至可以一直加下去，其實我覺得這個才是協程的真正威力，

讓多個協程一起作業

我們繼續復雜化使用場景——我在做一個多端使用的筆記App，現在用戶打開了某一個已存在的筆記，為了讓用戶能快速瀏覽到上一次的操作資訊，一方面我需要從檔案中讀取上一次操作的結果，另一方面我要拉取遠程的操作結果，然后對兩個結果合并，決定最終的展示資料，考慮到這兩個操作其實是并行的，上面我們讓協程串聯起來的思路已經不適用了，因為協程里面的操作都是串行的，既然一個協程解決不了，我們再加一個協程可不可以呢？看著好像是可以，但是，協程操作的結果我們怎么獲取到呢？查閱API，我找到了另一個協程構建器async，它會回傳一個協程物件，然后通過await方法獲取到協程的計算結果，思路來了，我們馬上動手

 val fileResult=viewModelScope.async(Dispatchers.IO) {
             //假裝是讀檔案的代碼吧
             1
         }
 val networkResult=viewModelScope.async(Dispatchers.IO) {
     //也是假裝是網路請求的代碼
     2
 }
 val fResult=fileResult.await()
val rResult=networkResult.await()
val result=if(fResult>rResult){
    fResult
}else{
    networkResult
}

然后你就會發現報錯了，await是掛起函式，看來兩個協程還完成不了，要三個，所以，讓我們創建第三個協程吧

 //前面的兩個協程不變
 viewModelScope.launch {
     val fResult=fileResult.await()
     val rResult=networkResult.await()
     val result=if(fResult>rResult){
         fResult
     }else{
         networkResult
     }
}

這就是協程間通信的基本寫法啦，從這個基礎之上，甚至還能衍生出更復雜的版本，但是萬變不離其宗，都可以參考這種思路完成，

協程的取消

正如之前提到的一樣，協程有著類似于執行緒的完整生命周期，包括創建，激活，完成中（取消中），已完成（已取消），剛才我們的示例都是正常狀態，協程完成作業后會自動結束，但協程的另一條取消流程我們還沒有提到，協程有自己的取消API——cancel可供使用，我們只需要保存好協程創建者回傳的協程物件就行了，當然更常見的還是文章開篇提到的使用協程作用域取消，這個操作會取消所有的協程，

總結

本篇文章從協程創建開始，講到了怎樣用協程寫出異步代碼，怎么讓多個協程共同作業，雖然覆寫了很大一部分使用場景，但是依然還有遺漏，由于篇幅限制，遺漏部分將在下一篇博文中繼續講解，希望大家持續關注，

青山不改，綠水長流，咱們下期見！

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/555429.html

標籤：其他

上一篇：Kotlin協程-從一到多

下一篇：返回列表