Kotlin協程-從理論到實戰_ZenDei技術網路在線

> 上一篇文章從理論上對Kotlin協程進行了部分說明，本文將在上一篇的基礎上，從實戰出發，繼續協程之旅。 ### 從源頭說起在Kotlin中，要想使用協程，首先需要使用協程創建器創建，但還有個前提——協程作用域(`CoroutineScope`)。在早期的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=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可供使用，我們只需要保存好協程創建者返回的協程對象就行了。當然更常見的還是文章開篇提到的使用協程作用域取消。這個操作會取消所有的協程。

總結

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

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