協程中的取消和異常 | 取消操作詳解

在日常的開發中,我們都知道應該避免不必要的任務處理來節省設備的內存空間和電量的使用——這一原則在協程中同樣適用。您需要控制好協程的生命週期,在不需要使用的時候將它取消,這也是結構化併發所倡導的,繼續閱讀本文來了解有關協程取消的來龍去脈。

⚠️ 爲了能夠更好地理解本文所講的內容,建議您首先閱讀本系列中的第一篇文章: 協程中的取消和異常 | 核心概念介紹

調用 cancel 方法

當啓動多個協程時,無論是追蹤協程狀態,還是單獨取消各個協程,都是件讓人頭疼的事情。不過,我們可以通過直接取消協程啓動所涉及的整個作用域 (scope) 來解決這個問題,因爲這樣可以取消所有已創建的子協程。

// 假設我們已經定義了一個作用域


val job1 = scope.launch { … }
val job2 = scope.launch { … }


scope.cancel()

取消作用域會取消它的子協程

有時候,您也許僅僅需要取消其中某一個協程,比如用戶輸入了某個事件,作爲迴應要取消某個進行中的任務。如下代碼所示,調用 job1.cancel 會確保只會取消跟 job1 相關的特定協程,而不會影響其餘兄弟協程繼續工作。

// 假設我們已經定義了一個作用域


val job1 = scope.launch { … }
val job2 = scope.launch { … }
 
// 第一個協程將會被取消,而另一個則不受任何影響
job1.cancel()

被取消的子協程並不會影響其餘兄弟協程

協程通過拋出一個特殊的異常 CancellationException 來處理取消操作。在調用 .cancel 時您可以傳入一個 CancellationException 實例來提供更多關於本次取消的詳細信息,該方法的簽名如下:

fun cancel(cause: CancellationException? = null)

如果您不構建新的 CancellationException 實例將其作爲參數傳入的話,會創建一個默認的 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 異常,您便可以使用這一機制來處理協程的取消。有關如何執行此操作的更多信息,請參考下面的處理取消的副作用一節。

在底層實現中,子協程會通過拋出異常的方式將取消的情況通知到它的父級。父協程通過傳入的取消原因來決定是否來處理該異常。如果子協程因爲 CancellationException 而被取消,對於它的父級來說是不需要進行其餘額外操作的。

不能在已取消的作用域中再次啓動新的協程

如果您使用的是 androidx KTX 庫的話,在大部分情況下都不需要創建自己的作用域,所以也就不需要負責取消它們。如果您是在 ViewModel 的作用域中進行操作,請使用 viewModelScope,或者如果在生命週期相關的作用域中啓動協程,那就應該使用 lifecycleScope。viewModelScope 和 lifecycleScope 都是 CoroutineScope 對象,它們都會在適當的時間點被取消。例如,當 ViewModel 被清除時,在其作用域內啓動的協程也會被一起取消。

  • 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

爲什麼協程處理的任務沒有停止?

如果我們僅是調用了 cancel 方法,並不意味着協程所處理的任務也會停止。如果您使用協程處理了一些相對較爲繁重的工作,比如讀取多個文件,那麼您的代碼不會自動就停止此任務的進行。

讓我們舉一個更簡單的例子看看會發生什麼。假設我們需要使用協程來每秒打印兩次 "Hello"。我們先讓協程運行一秒,然後將其取消。其中一個版本實現如下所示:

我們一步一步來看發生了什麼。當調用 launch 方法時,我們創建了一個活躍 (active) 狀態的協程。緊接着我們讓協程運行了 1,000 毫秒,打印出來的結果如下:

Hello 0
Hello 1
Hello 2

當 job.cancel 方法被調用後,我們的協程轉變爲取消中 (cancelling) 的狀態。但是緊接着我們發現 Hello 3 和 Hello 4 打印到了命令行中。當協程處理的任務結束後,協程又轉變爲了已取消 (cancelled) 狀態。

協程所處理的任務不會僅僅在調用 cancel 方法時就停止,相反,我們需要修改代碼來定期檢查協程是否處於活躍狀態。

讓您的協程可以被取消

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

val job = launch {
    for(file in files) {
        // TODO 檢查協程是否被取消
        readFile(file)
    }
}

所有 kotlinx.coroutines 中的掛起函數 (withContext, delay 等) 都是可取消的。如果您使用它們中的任一個函數,都不需要檢查協程是否已取消,然後停止任務執行,或是拋出 CancellationException 異常。但是,如果沒有使用這些函數,爲了讓您的代碼能夠配合協程取消,可以使用以下兩種方法:

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

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

檢查 job 的活躍狀態

先看一下第一種方法,在我們的 while(i<5) 循環中添加對於協程狀態的檢查:

// 因爲處於 launch 的代碼塊中,可以訪問到 job.isActive 屬性
while (i < 5 && isActive)

這樣意味着我們的任務只會在協程處於活躍的狀態下執行。同樣,這也意味着在 while 循環之外,我們若還想處理別的行爲,比如在 job 被取消後打日誌出來,那就可以檢查 !isActive 然後再繼續進行相應的處理。

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

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

 

如果 job 處於非活躍狀態,這個方法會立即拋出異常,我們可以在 while 循環開始就使用這個方法。

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

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

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

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

  • yield()

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

Job.join ???? Deferred.await cancellation

等待協程處理結果有兩種方法: 來自 launch 的 job 可以調用 join 方法,由 async 返回的 Deferred (其中一種 job 類型) 可以調用 await 方法。

Job.join 會掛起協程,直到任務處理完成。與 job.cancel 一起使用時,會按照以下方式進行:

  • 如果您調用  job.cancel 之後再調用 job.join,那麼協程會在任務處理完成之前一直處於掛起狀態;

  • 在 job.join 之後調用 job.cancel 沒有什麼影響,因爲 job 已經完成了。

  • Job.join

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

如果您關心協程處理結果,那麼應該使用 Deferred。當協程完成後,結果會由 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 的角色是負責在協程處理結果出來之前一直將協程掛起,因爲如果協程被取消了那麼協程就不會繼續進行計算,也就不會有結果產生。因此,在協程取消後調用 await 會拋出 JobCancellationException 異常: 因爲 Job 已被取消。

另一方面,如果您在 deferred.cancel 之後調用 deferred.await 不會有任何情況發生,因爲協程已經處理結束。

處理協程取消的副作用

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

檢查 !isActive

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

while (i < 5 && isActive) {
    if (…) {
        println(“Hello ${i++}”)
        nextPrintTime += 500L
    }
}
 
// 協程所處理的任務已經完成,因此我們可以做一些清理工作
println(“Clean up!”)

您可以查看完整版本

  • 完整版本

    https://pl.kotl.in/loI9DaIYj

所以現在,當協程不再處於活躍狀態,會退出 while 循環,就可以處理一些清理工作了。

Try catch finally

因爲當協程被取消後會拋出 CancellationException 異常,我們可以將掛起的任務放置於 try/catch 代碼塊中,然後在 finally 代碼塊中執行需要做的清理任務。

val job = launch {
   try {
      work()
   } catch (e: CancellationException){
      println(“Work cancelled!”)
    } finally {
      println(“Clean up!”)
    }
}


delay(1000L)
println(“Cancel!”)
job.cancel()
println(“Done!”)

但是,一旦我們需要執行的清理工作也掛起了,那上述代碼就不能夠繼續工作了,因爲一旦協程處於取消中狀態,它將不能再轉爲掛起 (suspend) 狀態。您可以查看完整代碼

  • 完整代碼

    https://pl.kotl.in/wjPINnWfG

處於取消中狀態的協程不能夠掛起

當協程被取消後需要調用掛起函數,我們需要將清理任務的代碼放置於 NonCancellable CoroutineContext 中。這樣會掛起運行中的代碼,並保持協程的取消中狀態直到任務處理完成。

val job = launch {
   try {
      work()
   } catch (e: CancellationException){
      println(“Work cancelled!”)
    } finally {
      withContext(NonCancellable){
         delay(1000L) // 或一些其他的掛起函數
         println(“Cleanup done!”)
      }
    }
}


delay(1000L)
println(“Cancel!”)
job.cancel()
println(“Done!”)

您可以查看其工作原理

  • 工作原理

    https://pl.kotl.in/ufZRQSa7o

suspendCancellableCoroutine 和 invokeOnCancellation

如果您通過 suspendCoroutine 方法將回調轉爲協程,那麼您更應該使用 suspendCancellableCoroutine 方法。可以使用 continuation.invokeOnCancellation 來執行取消操作:

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

爲了享受到結構化併發帶來的好處,並確保我們並沒有進行多餘的操作,那麼需要保證代碼是可被取消的。

 

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

協程代碼的取消需要是協作式的,因此請將代碼更新爲對協程的取消操作以延後的方式進行檢查,並避免不必要的操作。

 

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


推薦閱讀




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


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章