接上篇文章《在 Android 開(kāi)發(fā)中使用協(xié)程 | 背景介紹》

本文是介紹 Android 協(xié)程系列中的第二部分，這篇文章主要會(huì)介紹如何使用協(xié)程來(lái)處理任務(wù)，并且能在任務(wù)開(kāi)始執(zhí)行后保持對(duì)它的追蹤。

[[323364]]

保持對(duì)協(xié)程的追蹤

本系列文章的第一篇，我們探討了協(xié)程適合用來(lái)解決哪些問(wèn)題。這里再簡(jiǎn)單回顧一下，協(xié)程適合解決以下兩個(gè)常見(jiàn)的編程問(wèn)題：

• 處理耗時(shí)任務(wù) (Long running tasks)，這種任務(wù)常常會(huì)阻塞住主線程;
• 保證主線程安全 (Main-safety)，即確保安全地從主線程調(diào)用任何 suspend 函數(shù)。

協(xié)程通過(guò)在常規(guī)函數(shù)之上增加 suspend 和 resume 兩個(gè)操作來(lái)解決上述問(wèn)題。當(dāng)某個(gè)特定的線程上的所有協(xié)程被 suspend 后，該線程便可騰出資源去處理其他任務(wù)。

協(xié)程自身并不能夠追蹤正在處理的任務(wù)，但是有成百上千個(gè)協(xié)程并對(duì)它們同時(shí)執(zhí)行掛起操作并沒(méi)有太大問(wèn)題。協(xié)程是輕量級(jí)的，但處理的任務(wù)卻不一定是輕量的，比如讀取文件或者發(fā)送網(wǎng)絡(luò)請(qǐng)求。

使用代碼來(lái)手動(dòng)追蹤上千個(gè)協(xié)程是非常困難的，您可以嘗試對(duì)所有協(xié)程進(jìn)行跟蹤，手動(dòng)確保它們都完成了或者都被取消了，那么代碼會(huì)臃腫且易出錯(cuò)。如果代碼不是很完美，就會(huì)失去對(duì)協(xié)程的追蹤，也就是所謂 "work leak" 的情況。

任務(wù)泄漏 (work leak) 是指某個(gè)協(xié)程丟失無(wú)法追蹤，它類似于內(nèi)存泄漏，但比它更加糟糕，這樣丟失的協(xié)程可以恢復(fù)自己，從而占用內(nèi)存、CPU、磁盤(pán)資源，甚至?xí)l(fā)起一個(gè)網(wǎng)絡(luò)請(qǐng)求，而這也意味著它所占用的這些資源都無(wú)法得到重用。

泄漏協(xié)程會(huì)浪費(fèi)內(nèi)存、CPU、磁盤(pán)資源，甚至發(fā)送一個(gè)無(wú)用的網(wǎng)絡(luò)請(qǐng)求。

為了能夠避免協(xié)程泄漏，Kotlin 引入了結(jié)構(gòu)化并發(fā) (structured concurrency) 機(jī)制，它是一系列編程語(yǔ)言特性和實(shí)踐指南的結(jié)合，遵循它能幫助您追蹤到所有運(yùn)行于協(xié)程中的任務(wù)。

在 Android 平臺(tái)上，我們可以使用結(jié)構(gòu)化并發(fā)來(lái)做到以下三件事：

• 取消任務(wù) —— 當(dāng)某項(xiàng)任務(wù)不再需要時(shí)取消它;
• 追蹤任務(wù) —— 當(dāng)任務(wù)正在執(zhí)行時(shí)，追蹤它;
• 發(fā)出錯(cuò)誤信號(hào) —— 當(dāng)協(xié)程失敗時(shí)，發(fā)出錯(cuò)誤信號(hào)表明有錯(cuò)誤發(fā)生。

接下來(lái)我們對(duì)以上幾點(diǎn)一一進(jìn)行探討，看看結(jié)構(gòu)化并發(fā)是如何幫助能夠追蹤所有協(xié)程，而不會(huì)導(dǎo)致泄漏出現(xiàn)的。

結(jié)構(gòu)化并發(fā)：

https://kotlinlang.org/docs/reference/coroutines/basics.html#structured-concurrency

借助 scope 來(lái)取消任務(wù)

在 Kotlin 中，定義協(xié)程必須指定其 CoroutineScope 。CoroutineScope 可以對(duì)協(xié)程進(jìn)行追蹤，即使協(xié)程被掛起也是如此。同第一篇文章中講到的調(diào)度程序 (Dispatcher) 不同，CoroutineScope 并不運(yùn)行協(xié)程，它只是確保您不會(huì)失去對(duì)協(xié)程的追蹤。

為了確保所有的協(xié)程都會(huì)被追蹤，Kotlin 不允許在沒(méi)有使用 CoroutineScope 的情況下啟動(dòng)新的協(xié)程。CoroutineScope 可被看作是一個(gè)具有超能力的 ExecutorService 的輕量級(jí)版本。它能啟動(dòng)新的協(xié)程，同時(shí)這個(gè)協(xié)程還具備我們?cè)诘谝徊糠炙f(shuō)的 suspend 和 resume 的優(yōu)勢(shì)。

CoroutineScope 會(huì)跟蹤所有協(xié)程，同樣它還可以取消由它所啟動(dòng)的所有協(xié)程。這在 Android 開(kāi)發(fā)中非常有用，比如它能夠在用戶離開(kāi)界面時(shí)停止執(zhí)行協(xié)程。

CoroutineScope 會(huì)跟蹤所有協(xié)程，并且可以取消由它所啟動(dòng)的所有協(xié)程。

啟動(dòng)新的協(xié)程

需要特別注意的是，您不能隨便就在某個(gè)地方調(diào)用 suspend 函數(shù)，suspend 和 resume 機(jī)制要求您從常規(guī)函數(shù)中切換到協(xié)程。

有兩種方式能夠啟動(dòng)協(xié)程，它們分別適用于不同的場(chǎng)景:

• launch 構(gòu)建器適合執(zhí)行 "一勞永逸" 的工作，意思就是說(shuō)它可以啟動(dòng)新協(xié)程而不將結(jié)果返回給調(diào)用方;
• async 構(gòu)建器可啟動(dòng)新協(xié)程并允許您使用一個(gè)名為 await 的掛起函數(shù)返回 result。

通常，您應(yīng)使用 launch 從常規(guī)函數(shù)中啟動(dòng)新協(xié)程。因?yàn)槌Ｒ?guī)函數(shù)無(wú)法調(diào)用 await (記住，它無(wú)法直接調(diào)用 suspend 函數(shù))，所以將 async 作為協(xié)程的主要啟動(dòng)方法沒(méi)有多大意義。稍后我們會(huì)討論應(yīng)該如何使用 async。

您應(yīng)該改為使用 coroutine scope 調(diào)用 launch 方法來(lái)啟動(dòng)協(xié)程。

scope.launch { 
    // 這段代碼在作用域里啟動(dòng)了一個(gè)新協(xié)程 
   // 它可以調(diào)用掛起函數(shù) 
   fetchDocs() 
} 

您可以將 launch 看作是將代碼從常規(guī)函數(shù)送往協(xié)程世界的橋梁。在 launch 函數(shù)體內(nèi)，您可以調(diào)用 suspend 函數(shù)并能夠像我們上一篇介紹的那樣保證主線程安全。

Launch 是將代碼從常規(guī)函數(shù)送往協(xié)程世界的橋梁。

注意：launch 和 async 之間的很大差異是它們對(duì)異常的處理方式不同。async 期望最終是通過(guò)調(diào)用 await 來(lái)獲取結(jié)果 (或者異常)，所以默認(rèn)情況下它不會(huì)拋出異常。這意味著如果使用 async 啟動(dòng)新的協(xié)程，它會(huì)靜默地將異常丟棄。

由于 launch 和 async 僅能夠在 CouroutineScope 中使用，所以任何您所創(chuàng)建的協(xié)程都會(huì)被該 scope 追蹤。Kotlin 禁止您創(chuàng)建不能夠被追蹤的協(xié)程，從而避免協(xié)程泄漏。

• launchhttps://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/launch.html
• asynchttps://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/async.html

在 ViewModel 中啟動(dòng)協(xié)程

既然 CoroutineScope 會(huì)追蹤由它啟動(dòng)的所有協(xié)程，而 launch 會(huì)創(chuàng)建一個(gè)新的協(xié)程，那么您應(yīng)該在什么地方調(diào)用 launch 并將其放在 scope 中呢? 又該在什么時(shí)候取消在 scope 中啟動(dòng)的所有協(xié)程呢?

在 Android 平臺(tái)上，您可以將 CoroutineScope 實(shí)現(xiàn)與用戶界面相關(guān)聯(lián)。這樣可讓您避免泄漏內(nèi)存或者對(duì)不再與用戶相關(guān)的 Activities 或 Fragments 執(zhí)行額外的工作。當(dāng)用戶通過(guò)導(dǎo)航離開(kāi)某界面時(shí)，與該界面相關(guān)的 CoroutineScope 可以取消掉所有不需要的任務(wù)。

結(jié)構(gòu)化并發(fā)能夠保證當(dāng)某個(gè)作用域被取消后，它內(nèi)部所創(chuàng)建的所有協(xié)程也都被取消。

當(dāng)將協(xié)程同 Android 架構(gòu)組件 (Android Architecture Components) 集成起來(lái)時(shí)，您往往會(huì)需要在 ViewModel 中啟動(dòng)協(xié)程。因?yàn)榇蟛糠值娜蝿?wù)都是在這里開(kāi)始進(jìn)行處理的，所以在這個(gè)地方啟動(dòng)是一個(gè)很合理的做法，您也不用擔(dān)心旋轉(zhuǎn)屏幕方向會(huì)終止您所創(chuàng)建的協(xié)程。

從生命周期感知型組件 (AndroidX Lifecycle) 的 2.1.0 版本開(kāi)始 (發(fā)布于 2019 年 9 月)，我們通過(guò)添加擴(kuò)展屬性 ViewModel.viewModelScope 在 ViewModel 中加入了協(xié)程的支持。

看看如下示例：

class MyViewModel(): ViewModel() { 
    fun userNeedsDocs() { 
       // 在 ViewModel 中啟動(dòng)新的協(xié)程 
        viewModelScope.launch { 
            fetchDocs() 
        } 
    } 
} 

當(dāng) viewModelScope 被清除 (當(dāng) onCleared() 回調(diào)被調(diào)用時(shí)) 之后，它將自動(dòng)取消它所啟動(dòng)的所有協(xié)程。這是一個(gè)標(biāo)準(zhǔn)做法，如果一個(gè)用戶在尚未獲取到數(shù)據(jù)時(shí)就關(guān)閉了應(yīng)用，這時(shí)讓請(qǐng)求繼續(xù)完成就純粹是在浪費(fèi)電量。

為了提高安全性，CoroutineScope 會(huì)進(jìn)行自行傳播。也就是說(shuō)，如果某個(gè)協(xié)程啟動(dòng)了另一個(gè)新的協(xié)程，它們都會(huì)在同一個(gè) scope 中終止運(yùn)行。這意味著，即使當(dāng)某個(gè)您所依賴的代碼庫(kù)從您創(chuàng)建的 viewModelScope 中啟動(dòng)某個(gè)協(xié)程，您也有方法將其取消。

注意：協(xié)程被掛起時(shí)，系統(tǒng)會(huì)以拋出 CancellationException 的方式協(xié)作取消協(xié)程。捕獲頂級(jí)異常 (如Throwable) 的異常處理程序?qū)⒉东@此異常。如果您做異常處理時(shí)消費(fèi)了這個(gè)異常，或從未進(jìn)行 suspend 操作，那么協(xié)程將會(huì)徘徊于半取消 (semi-canceled) 狀態(tài)下。

所以，當(dāng)您需要將一個(gè)協(xié)程同 ViewModel 的生命周期保持一致時(shí)，使用 viewModelScope 來(lái)從常規(guī)函數(shù)切換到協(xié)程中。然后，viewModelScope 會(huì)自動(dòng)為您取消協(xié)程，因此在這里哪怕是寫(xiě)了死循環(huán)也是完全不會(huì)產(chǎn)生泄漏。如下示例：

fun runForever() { 
    // 在 ViewModel 中啟動(dòng)新的協(xié)程 
    viewModelScope.launch { 
        // 當(dāng) ViewModel 被清除后，下列代碼也會(huì)被取消 
        while(true) { 
            delay(1_000) 
           // 每過(guò) 1 秒做點(diǎn)什么 
        } 
    } 
} 

通過(guò)使用 viewModelScope，可以確保所有的任務(wù)，包含死循環(huán)在內(nèi)，都可以在不需要的時(shí)候被取消掉。

協(xié)作取消：

https://kotlinlang.org/docs/reference/coroutines/cancellation-and-timeouts.html#cancellation-and-timeouts

任務(wù)追蹤

使用協(xié)程來(lái)處理任務(wù)對(duì)于很多代碼來(lái)說(shuō)真的很方便。啟動(dòng)協(xié)程，進(jìn)行網(wǎng)絡(luò)請(qǐng)求，將結(jié)果寫(xiě)入數(shù)據(jù)庫(kù)，一切都很自然流暢。

但有時(shí)候，可能會(huì)遇到稍微復(fù)雜點(diǎn)的問(wèn)題，例如您需要在一個(gè)協(xié)程中同時(shí)處理兩個(gè)網(wǎng)絡(luò)請(qǐng)求，這種情況下需要啟動(dòng)更多協(xié)程。

想要?jiǎng)?chuàng)建多個(gè)協(xié)程，可以在 suspend function 中使用名為 coroutineScope 或 supervisorScope 這樣的構(gòu)造器來(lái)啟動(dòng)多個(gè)協(xié)程。但是這個(gè) API 說(shuō)實(shí)話，有點(diǎn)令人困惑。coroutineScope 構(gòu)造器和 CoroutineScope 這兩個(gè)的區(qū)別只是一個(gè)字符之差，但它們卻是完全不同的東西。

另外，如果隨意啟動(dòng)新協(xié)程，可能會(huì)導(dǎo)致潛在的任務(wù)泄漏 (work leak)。調(diào)用方可能感知不到啟用了新的協(xié)程，也就意味著無(wú)法對(duì)其進(jìn)行追蹤。

為了解決這個(gè)問(wèn)題，結(jié)構(gòu)化并發(fā)發(fā)揮了作用，它保證了當(dāng) suspend 函數(shù)返回時(shí)，就意味著它所處理的任務(wù)也都已完成。

結(jié)構(gòu)化并發(fā)保證了當(dāng) suspend 函數(shù)返回時(shí)，它所處理任務(wù)也都已完成。

示例使用 coroutineScope 來(lái)獲取兩個(gè)文檔內(nèi)容：

suspend fun fetchTwoDocs() { 
    coroutineScope { 
        launch { fetchDoc(1) } 
        async { fetchDoc(2) } 
    } 
} 

在這個(gè)示例中，同時(shí)從網(wǎng)絡(luò)中獲取兩個(gè)文檔數(shù)據(jù)，第一個(gè)是通過(guò) launch 這樣 "一勞永逸" 的方式啟動(dòng)協(xié)程，這意味著它不會(huì)返回任何結(jié)果給調(diào)用方。

第二個(gè)是通過(guò) async 的方式獲取文檔，所以是會(huì)有返回值返回的。不過(guò)上面示例有一點(diǎn)奇怪，因?yàn)橥ǔ?lái)講兩個(gè)文檔的獲取都應(yīng)該使用 async，但這里我僅僅是想舉例來(lái)說(shuō)明可以根據(jù)需要來(lái)選擇使用 launch 還是 async，或者是對(duì)兩者進(jìn)行混用。

coroutineScope 和 supervisorScope 可以讓您安全地從 suspend 函數(shù)中啟動(dòng)協(xié)程。

但是請(qǐng)注意，這段代碼不會(huì)顯式地等待所創(chuàng)建的兩個(gè)協(xié)程完成任務(wù)后才返回，當(dāng) fetchTwoDocs 返回時(shí)，協(xié)程還正在運(yùn)行中。

所以，為了做到結(jié)構(gòu)化并發(fā)并避免泄漏的情況發(fā)生，我們想做到在諸如 fetchTwoDocs 這樣的 suspend 函數(shù)返回時(shí)，它們所做的所有任務(wù)也都能結(jié)束。換個(gè)說(shuō)法就是，fetchTwoDocs 返回之前，它所啟動(dòng)的所有協(xié)程也都能完成任務(wù)。

Kotlin 確保使用 coroutineScope 構(gòu)造器不會(huì)讓 fetchTwoDocs 發(fā)生泄漏，coroutinScope 會(huì)先將自身掛起，等待它內(nèi)部啟動(dòng)的所有協(xié)程完成，然后再返回。因此，只有在 coroutineScope 構(gòu)建器中啟動(dòng)的所有協(xié)程完成任務(wù)之后，fetchTwoDocs 函數(shù)才會(huì)返回。

• coroutineScope：https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/coroutine-scope.html
• supervisorScope：https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/supervisor-scope.html

處理一堆任務(wù)

既然我們已經(jīng)做到了追蹤一兩個(gè)協(xié)程，那么來(lái)個(gè)刺激的，追蹤一千個(gè)協(xié)程來(lái)試試!

先看看下面這個(gè)動(dòng)畫(huà)

這個(gè)動(dòng)畫(huà)向我們展示了如何同時(shí)發(fā)出一千個(gè)網(wǎng)絡(luò)請(qǐng)求。當(dāng)然，在真實(shí)的 Android 開(kāi)發(fā)中最好別這么做，太浪費(fèi)資源了。

這段代碼中，我們?cè)?coroutineScope 構(gòu)造器中使用 launch 啟動(dòng)了一千個(gè)協(xié)程，您可以看到這一切是如何聯(lián)系到一起的。由于我們使用的是 suspend 函數(shù)，因此代碼一定使用了 CoroutineScope 創(chuàng)建了協(xié)程。我們目前對(duì)這個(gè) CoroutineScope 一無(wú)所知，它可能是viewModelScope 或者是其他地方定義的某個(gè) CoroutineScope，但不管怎樣，coroutineScope 構(gòu)造器都會(huì)使用它作為其創(chuàng)建新的 scope 的父級(jí)。

然后，在 coroutineScope 代碼塊內(nèi)，launch 將會(huì)在新的 scope 中啟動(dòng)協(xié)程，隨著協(xié)程的啟動(dòng)完成，scope 會(huì)對(duì)其進(jìn)行追蹤。最后，一旦所有在 coroutineScope 內(nèi)啟動(dòng)的協(xié)程都完成后，loadLots 方法就可以輕松地返回了。

注意：scope 和協(xié)程之間的父子關(guān)系是使用 Job 對(duì)象進(jìn)行創(chuàng)建的。但是您不需要深入去了解，只要知道這一點(diǎn)就可以了。

coroutineScope 和 supervisorScope 將會(huì)等待所有的子協(xié)程都完成。

以上的重點(diǎn)是，使用 coroutineScope 和 supervisorScope 可以從任何 suspend function 來(lái)安全地啟動(dòng)協(xié)程。即使是啟動(dòng)一個(gè)新的協(xié)程，也不會(huì)出現(xiàn)泄漏，因?yàn)樵谛碌膮f(xié)程完成之前，調(diào)用方始終處于掛起狀態(tài)。

更厲害的是，coroutineScope 將會(huì)創(chuàng)建一個(gè)子 scope，所以一旦父 scope 被取消，它會(huì)將取消的消息傳遞給所有新的協(xié)程。如果調(diào)用方是 viewModelScope，這一千個(gè)協(xié)程在用戶離開(kāi)界面后都會(huì)自動(dòng)被取消掉，非常整潔高效。

在繼續(xù)探討報(bào)錯(cuò) (error) 相關(guān)的問(wèn)題之前，有必要花點(diǎn)時(shí)間來(lái)討論一下 supervisorScope 和 coroutineScope，它們的主要區(qū)別是當(dāng)出現(xiàn)任何一個(gè)子 scope 失敗的情況，coroutineScope 將會(huì)被取消。如果一個(gè)網(wǎng)絡(luò)請(qǐng)求失敗了，所有其他的請(qǐng)求都將被立即取消，這種需求選擇 coroutineScope。相反，如果您希望即使一個(gè)請(qǐng)求失敗了其他的請(qǐng)求也要繼續(xù)，則可以使用 supervisorScope，當(dāng)一個(gè)協(xié)程失敗了，supervisorScope 是不會(huì)取消剩余子協(xié)程的。

協(xié)程失敗時(shí)發(fā)出報(bào)錯(cuò)信號(hào)

在協(xié)程中，報(bào)錯(cuò)信號(hào)是通過(guò)拋出異常來(lái)發(fā)出的，就像我們平常寫(xiě)的函數(shù)一樣。來(lái)自 suspend 函數(shù)的異常將通過(guò) resume 重新拋給調(diào)用方來(lái)處理。跟常規(guī)函數(shù)一樣，您不僅可以使用 try/catch 這樣的方式來(lái)處理錯(cuò)誤，還可以構(gòu)建抽象來(lái)按照您喜歡的方式進(jìn)行錯(cuò)誤處理。

但是，在某些情況下，協(xié)程還是有可能會(huì)弄丟獲取到的錯(cuò)誤的。

val unrelatedScope = MainScope() 
// 丟失錯(cuò)誤的例子 
suspend fun lostError() { 
   // 未使用結(jié)構(gòu)化并發(fā)的 async 
    unrelatedScope.async { 
        throw InAsyncNoOneCanHearYou("except") 
    } 
} 

注意：上述代碼聲明了一個(gè)無(wú)關(guān)聯(lián)協(xié)程作用域，它將不會(huì)按照結(jié)構(gòu)化并發(fā)的方式啟動(dòng)新的協(xié)程。還記得我在一開(kāi)始說(shuō)的結(jié)構(gòu)化并發(fā)是一系列編程語(yǔ)言特性和實(shí)踐指南的集合，在 suspend 函數(shù)中引入無(wú)關(guān)聯(lián)協(xié)程作用域違背了結(jié)構(gòu)化并發(fā)規(guī)則。

在這段代碼中錯(cuò)誤將會(huì)丟失，因?yàn)?async 假設(shè)您最終會(huì)調(diào)用 await 并且會(huì)重新拋出異常，然而您并沒(méi)有去調(diào)用 await，所以異常就永遠(yuǎn)在那等著被調(diào)用，那么這個(gè)錯(cuò)誤就永遠(yuǎn)不會(huì)得到處理。

結(jié)構(gòu)化并發(fā)保證當(dāng)一個(gè)協(xié)程出錯(cuò)時(shí)，它的調(diào)用方或作用域會(huì)被通知到。

如果您按照結(jié)構(gòu)化并發(fā)的規(guī)范去編寫(xiě)上述代碼，錯(cuò)誤就會(huì)被正確地拋給調(diào)用方處理。

suspend fun foundError() { 
    coroutineScope { 
        async {  
            throw StructuredConcurrencyWill("throw") 
        } 
    } 
} 

coroutineScope 不僅會(huì)等到所有子任務(wù)都完成才會(huì)結(jié)束，當(dāng)它們出錯(cuò)時(shí)它也會(huì)得到通知。如果一個(gè)通過(guò) coroutineScope 創(chuàng)建的協(xié)程拋出了異常，coroutineScope 會(huì)將其拋給調(diào)用方。因?yàn)槲覀冇玫氖莄oroutineScope 而不是 supervisorScope，所以當(dāng)拋出異常時(shí)，它會(huì)立刻取消所有的子任務(wù)。

使用結(jié)構(gòu)化并發(fā)

在這篇文章中，我介紹了結(jié)構(gòu)化并發(fā)，并展示了如何讓我們的代碼配合 Android 中的 ViewModel 來(lái)避免出現(xiàn)任務(wù)泄漏。

同樣，我還幫助您更深入去理解和使用 suspend 函數(shù)，通過(guò)確保它們?cè)诤瘮?shù)返回之前完成任務(wù)，或者是通過(guò)暴露異常來(lái)確保它們正確發(fā)出錯(cuò)誤信號(hào)。

如果我們使用了不符合結(jié)構(gòu)化并發(fā)的代碼，將會(huì)很容易出現(xiàn)協(xié)程泄漏，即調(diào)用方不知如何追蹤任務(wù)的情況。這種情況下，任務(wù)是無(wú)法取消的，同樣也不能保證異常會(huì)被重新拋出來(lái)。這樣會(huì)使得我們的代碼很難理解，并可能會(huì)導(dǎo)致一些難以追蹤的 bug 出現(xiàn)。

您可以通過(guò)引入一個(gè)新的不相關(guān)的 CoroutineScope (注意是大寫(xiě)的 C)，或者是使用 GlobalScope 創(chuàng)建的全局作用域，但是這種方式的代碼不符合結(jié)構(gòu)化并發(fā)要求的方式。

但是當(dāng)出現(xiàn)需要協(xié)程比調(diào)用方的生命周期更長(zhǎng)的情況時(shí)，就可能需要考慮非結(jié)構(gòu)化并發(fā)的編碼方式了，只是這種情況比較罕見(jiàn)。因此，使用結(jié)構(gòu)化編程來(lái)追蹤非結(jié)構(gòu)化的協(xié)程，并進(jìn)行錯(cuò)誤處理和任務(wù)取消，將是非常不錯(cuò)的做法。

如果您之前一直未按照結(jié)構(gòu)化并發(fā)的方法編碼，一開(kāi)始確實(shí)一段時(shí)間去適應(yīng)。這種結(jié)構(gòu)確實(shí)保證與 suspend 函數(shù)交互更安全，使用起來(lái)更簡(jiǎn)單。在編碼過(guò)程中，盡可能多地使用結(jié)構(gòu)化并發(fā)，這樣讓代碼更易于維護(hù)和理解。

在本文的開(kāi)始列舉了結(jié)構(gòu)化并發(fā)為我們解決的三個(gè)問(wèn)題：

• 取消任務(wù) —— 當(dāng)某項(xiàng)任務(wù)不再需要時(shí)取消它;
• 追蹤任務(wù) —— 當(dāng)任務(wù)正在執(zhí)行時(shí)，追蹤它;
• 發(fā)出錯(cuò)誤信號(hào) —— 當(dāng)協(xié)程失敗時(shí)，發(fā)出錯(cuò)誤信號(hào)表明有錯(cuò)誤發(fā)生。

實(shí)現(xiàn)這種結(jié)構(gòu)化并發(fā)，會(huì)為我們的代碼提供一些保障：

• 作用域取消時(shí)，它內(nèi)部所有的協(xié)程也會(huì)被取消;
• suspend 函數(shù)返回時(shí)，意味著它的所有任務(wù)都已完成;
• 協(xié)程報(bào)錯(cuò)時(shí)，它所在的作用域或調(diào)用方會(huì)收到報(bào)錯(cuò)通知。

總結(jié)來(lái)說(shuō)，結(jié)構(gòu)化并發(fā)讓我們的代碼更安全，更容易理解，還避免了出現(xiàn)任務(wù)泄漏的情況。

下一步

本篇文章，我們探討了如何在 Android 的 ViewModel 中啟動(dòng)協(xié)程，以及如何在代碼中運(yùn)用結(jié)構(gòu)化并發(fā)，來(lái)讓我們的代碼更易于維護(hù)和理解。

在下一篇文章中，我們將探討如何在實(shí)際編碼過(guò)程中使用協(xié)程，感興趣的讀者請(qǐng)繼續(xù)關(guān)注我們的更新。

【本文是51CTO專欄機(jī)構(gòu)“谷歌開(kāi)發(fā)者”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者(微信公眾號(hào)：Google_Developers)】

戳這里，看該作者更多好文