在日常的開發(fā)中，我們都知道應該避免不必要的任務處理來節(jié)省設備的內存空間和電量的使用——這一原則在協(xié)程中同樣適用。您需要控制好協(xié)程的生命周期，在不需要使用的時候將它取消，這也是結構化并發(fā)所倡導的，繼續(xù)閱讀本文來了解有關協(xié)程取消的來龍去脈。?? 為了能夠更好地理解本文所講的內容，建議您首先閱讀本系列中的第一篇文章:?協(xié)程中的取消和異常 | 核心概念介紹。

調用 cancel 方法

當啟動多個協(xié)程時，無論是追蹤協(xié)程狀態(tài)，還是單獨取消各個協(xié)程，都是件讓人頭疼的事情。不過，我們可以通過直接取消協(xié)程啟動所涉及的整個作用域 (scope) 來解決這個問題，因為這樣可以取消所有已創(chuàng)建的子協(xié)程。// 假設我們已經定義了一個作用域val job1 = scope.launch { … }val job2 = scope.launch { … }scope.cancel()

取消作用域會取消它的子協(xié)程

有時候，您也許僅僅需要取消其中某一個協(xié)程，比如用戶輸入了某個事件，作為回應要取消某個進行中的任務。如下代碼所示，調用 job1.cancel 會確保只會取消跟 job1 相關的特定協(xié)程，而不會影響其余兄弟協(xié)程繼續(xù)工作。// 假設我們已經定義了一個作用域val job1 = scope.launch { … }val job2 = scope.launch { … }?// 第一個協(xié)程將會被取消，而另一個則不受任何影響job1.cancel()

被取消的子協(xié)程并不會影響其余兄弟協(xié)程

協(xié)程通過拋出一個特殊的異常 CancellationException 來處理取消操作。在調用 .cancel 時您可以傳入一個 CancellationException 實例來提供更多關于本次取消的詳細信息，該方法的簽名如下:fun cancel(cause: CancellationException? = null)如果您不構建新的 CancellationException 實例將其作為參數(shù)傳入的話，會創(chuàng)建一個默認的 CancellationException (請查看完整代碼)。public override fun cancel(cause: CancellationException?) { cancelInternal(cause ?: defaultCancellationException())}

• 完整代碼https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/common/src/JobSupport.kt#L612

一旦拋出了 CancellationException 異常，您便可以使用這一機制來處理協(xié)程的取消。有關如何執(zhí)行此操作的更多信息，請參考下面的處理取消的副作用一節(jié)。在底層實現(xiàn)中，子協(xié)程會通過拋出異常的方式將取消的情況通知到它的父級。父協(xié)程通過傳入的取消原因來決定是否來處理該異常。如果子協(xié)程因為 CancellationException 而被取消，對于它的父級來說是不需要進行其余額外操作的。不能在已取消的作用域中再次啟動新的協(xié)程如果您使用的是 androidx KTX 庫的話，在大部分情況下都不需要創(chuàng)建自己的作用域，所以也就不需要負責取消它們。如果您是在 ViewModel 的作用域中進行操作，請使用 viewModelScope，或者如果在生命周期相關的作用域中啟動協(xié)程，那就應該使用 lifecycleScope。viewModelScope 和 lifecycleScope 都是 CoroutineScope 對象，它們都會在適當?shù)臅r間點被取消。例如，當 ViewModel 被清除時，在其作用域內啟動的協(xié)程也會被一起取消。

• viewModelScope

  https://developer.android.google.cn/reference/kotlin/androidx/lifecycle/package-summary#(androidx.lifecycle.ViewModel).viewModelScope:kotlinx.coroutines.CoroutineScope

• lifecycleScope

  https://developer.android.google.cn/reference/kotlin/androidx/lifecycle/package-summary#lifecyclescope

為什么協(xié)程處理的任務沒有停止？

如果我們僅是調用了 cancel 方法，并不意味著協(xié)程所處理的任務也會停止。如果您使用協(xié)程處理了一些相對較為繁重的工作，比如讀取多個文件，那么您的代碼不會自動就停止此任務的進行。

讓我們舉一個更簡單的例子看看會發(fā)生什么。假設我們需要使用協(xié)程來每秒打印兩次?"Hello"。我們先讓協(xié)程運行一秒，然后將其取消。其中一個版本實現(xiàn)如下所示:

我們一步一步來看發(fā)生了什么。當調用 launch 方法時，我們創(chuàng)建了一個活躍 (active) 狀態(tài)的協(xié)程。緊接著我們讓協(xié)程運行了 1,000 毫秒，打印出來的結果如下:Hello 0Hello 1Hello?2當 job.cancel 方法被調用后，我們的協(xié)程轉變?yōu)槿∠?(cancelling) 的狀態(tài)。但是緊接著我們發(fā)現(xiàn) Hello 3 和 Hello 4 打印到了命令行中。當協(xié)程處理的任務結束后，協(xié)程又轉變?yōu)榱艘讶∠?(cancelled) 狀態(tài)。協(xié)程所處理的任務不會僅僅在調用 cancel 方法時就停止，相反，我們需要修改代碼來定期檢查協(xié)程是否處于活躍狀態(tài)。

讓您的協(xié)程可以被取消

您需要確保所有使用協(xié)程處理任務的代碼實現(xiàn)都是協(xié)作式的，也就是說它們都配合協(xié)程取消做了處理，因此您可以在任務處理期間定期檢查協(xié)程是否已被取消，或者在處理耗時任務之前就檢查當前協(xié)程是否已取消。例如，如果您從磁盤中獲取了多個文件，在開始讀取文件內容之前，先檢查協(xié)程是否被取消了。類似這樣的處理方式，您可以避免處理不必要的 CPU 密集型任務。

val job = launch {????for(file?in?files)?{ // TODO 檢查協(xié)程是否被取消 readFile(file) }}所有 kotlinx.coroutines 中的掛起函數(shù) (withContext, delay 等) 都是可取消的。如果您使用它們中的任一個函數(shù)，都不需要檢查協(xié)程是否已取消，然后停止任務執(zhí)行，或是拋出 CancellationException 異常。但是，如果沒有使用這些函數(shù)，為了讓您的代碼能夠配合協(xié)程取消，可以使用以下兩種方法:

• 檢查 job.isActive 或者使用 ensureActive()

• 使用 yield() 來讓其他任務進行

檢查 job 的活躍狀態(tài)

先看一下第一種方法，在我們的 while(i<5) 循環(huán)中添加對于協(xié)程狀態(tài)的檢查:// 因為處于 launch 的代碼塊中，可以訪問到 job.isActive 屬性while (i < 5 && isActive)這樣意味著我們的任務只會在協(xié)程處于活躍的狀態(tài)下執(zhí)行。同樣，這也意味著在 while 循環(huán)之外，我們若還想處理別的行為，比如在 job 被取消后打日志出來，那就可以檢查 !isActive 然后再繼續(xù)進行相應的處理。

Coroutine 的代碼庫中還提供了另一個很有用的方法 —— ensureActive()，它的實現(xiàn)如下:

fun Job.ensureActive(): Unit { if (!isActive) { throw getCancellationException() }}?

如果 job 處于非活躍狀態(tài)，這個方法會立即拋出異常，我們可以在 while 循環(huán)開始就使用這個方法。

while (i < 5) { ensureActive() …}

通過使用 ensureActive 方法，您可以避免使用 if 語句來檢查 isActive 狀態(tài)，這樣可以減少樣板代碼的使用量，但是相應地也失去了處理類似于日志打印這種行為的靈活性。

使用 yield() 函數(shù)運行其他任務

如果要處理的任務屬于 1) CPU 密集型，2) 可能會耗盡線程池資源，3) 需要在不向線程池中添加更多線程的前提下允許線程處理其他任務，那么請使用 yield()。如果 job 已經完成，由 yield 所處理的首要任務將會是檢查任務的完成狀態(tài)，完成的話則直接通過拋出 CancellationException 來退出協(xié)程。yield 可以作為定期檢查所調用的第一個函數(shù)，例如上面提到的 ensureActive() 方法。

• yield()

  https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/yield.html

Job.join ??Deferred.await cancellation

等待協(xié)程處理結果有兩種方法:?來自 launch 的 job 可以調用 join 方法，由 async 返回的 Deferred (其中一種 job 類型) 可以調用 await 方法。Job.join 會掛起協(xié)程，直到任務處理完成。與 job.cancel 一起使用時，會按照以下方式進行:

• 如果您調用? job.cancel 之后再調用 job.join，那么協(xié)程會在任務處理完成之前一直處于掛起狀態(tài)；

• 在 job.join 之后調用 job.cancel 沒有什么影響，因為 job 已經完成了。

• Job.join

  https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-job/join.html

如果您關心協(xié)程處理結果，那么應該使用 Deferred。當協(xié)程完成后，結果會由 Deferred.await 返回。Deferred 是 Job 的其中一種類型，它同樣可以被取消。

• Deferred

  https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-deferred/index.html

• Deferred.await

  https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-deferred/await.html

在已取消的 deferred 上調用 await 會拋出 JobCancellationException 異常。

val deferred = async { … }deferred.cancel()val?result?=?deferred.await()?//?拋出?JobCancellationException?異常

為什么會拿到這個異常呢？await 的角色是負責在協(xié)程處理結果出來之前一直將協(xié)程掛起，因為如果協(xié)程被取消了那么協(xié)程就不會繼續(xù)進行計算，也就不會有結果產生。因此，在協(xié)程取消后調用 await 會拋出 JobCancellationException 異常: 因為 Job 已被取消。

另一方面，如果您在 deferred.cancel 之后調用 deferred.await 不會有任何情況發(fā)生，因為協(xié)程已經處理結束。

處理協(xié)程取消的副作用

假設您要在協(xié)程取消后執(zhí)行某個特定的操作，比如關閉可能正在使用的資源，或者是針對取消需要進行日志打印，又或者是執(zhí)行其余的一些清理代碼。我們有好幾種方法可以做到這一點:

檢查 !isActive

如果您定期地進行 isActive 的檢查，那么一旦您跳出 while 循環(huán)，就可以進行資源的清理。之前的代碼可以更新至如下版本:

while?(i?5?&&?isActive)?{ if (…) { println(“Hello ${i++}”) nextPrintTime += 500L }}?// 協(xié)程所處理的任務已經完成，因此我們可以做一些清理工作println(“Clean?up!”)您可以查看完整版本。

• 完整版本

  https://pl.kotl.in/loI9DaIYj

所以現(xiàn)在，當協(xié)程不再處于活躍狀態(tài)，會退出 while 循環(huán)，就可以處理一些清理工作了。

Try catch finally

因為當協(xié)程被取消后會拋出 CancellationException 異常，我們可以將掛起的任務放置于 try/catch 代碼塊中，然后在 finally 代碼塊中執(zhí)行需要做的清理任務。val job = launch { try { work() } catch (e: CancellationException){ println(“Work cancelled!”) } finally { println(“Clean up!”) }}delay(1000L)println(“Cancel!”)job.cancel()println(“Done!”)但是，一旦我們需要執(zhí)行的清理工作也掛起了，那上述代碼就不能夠繼續(xù)工作了，因為一旦協(xié)程處于取消中狀態(tài)，它將不能再轉為掛起 (suspend) 狀態(tài)。您可以查看完整代碼。

• 完整代碼https://pl.kotl.in/wjPINnWfG

處于取消中狀態(tài)的協(xié)程不能夠掛起

當協(xié)程被取消后需要調用掛起函數(shù)，我們需要將清理任務的代碼放置于 NonCancellable CoroutineContext 中。這樣會掛起運行中的代碼，并保持協(xié)程的取消中狀態(tài)直到任務處理完成。

val job = launch { try { work() } catch (e: CancellationException){ println(“Work cancelled!”) } finally { withContext(NonCancellable){ delay(1000L) // 或一些其他的掛起函數(shù) println(“Cleanup done!”) } }}delay(1000L)println(“Cancel!”)job.cancel()println(“Done!”)您可以查看其工作原理。

• 工作原理https://pl.kotl.in/ufZRQSa7o

suspendCancellableCoroutine 和 invokeOnCancellation

如果您通過 suspendCoroutine 方法將回調轉為協(xié)程，那么您更應該使用 suspendCancellableCoroutine 方法。可以使用 continuation.invokeOnCancellation 來執(zhí)行取消操作:

suspend fun work() { return suspendCancellableCoroutine { continuation ->???????continuation.invokeOnCancellation?{? // 處理清理工作???????} // 剩余的實現(xiàn)代碼}

為了享受到結構化并發(fā)帶來的好處，并確保我們并沒有進行多余的操作，那么需要保證代碼是可被取消的。

使用在 Jetpack: viewModelScope 或者 lifecycleScope 中定義的 CoroutineScopes，它們在 scope 完成后就會取消它們處理的任務。如果要創(chuàng)建自己的 CoroutineScope，請確保將其與 job 綁定并在需要時調用 cancel。

協(xié)程代碼的取消需要是協(xié)作式的，因此請將代碼更新為對協(xié)程的取消操作以延后的方式進行檢查，并避免不必要的操作。

現(xiàn)在，大家了解了本系列的第一部分協(xié)程的一些基本概念、第二部分協(xié)程的取消，在接下來的文章中，我們將繼續(xù)深入探討學習第三部分異常處理，感興趣的讀者請繼續(xù)關注我們的更新。

---

推薦閱讀

點擊屏末?|?閱讀原文?|?查看 Android 官方中文文檔 —— 使用 Kotlin 更快地編寫更出色的 Android 應用

---

總結

以上是生活随笔為你收集整理的vs 启动调用的目标发生异常_协程中的取消和异常 | 取消操作详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。