原文作者 ：Sean McQuillan
原文地址： Coroutines on Android (part II): Getting started
譯者 ： 秉心說
這是關於在 Android 中使用協程的一系列文章。本篇的重點是開始任務以及追蹤已經開始的任務。
上一篇 ：
在 Android 上使用協程（一）：Getting The Background
協程解決了什麼問題？
追蹤協程
在上篇文章中，我們探索了協程擅長解決的問題。通常，協程對於下面兩個常見的編程問題來說都是不錯的解決方案：
耗時任務，運行時間過長阻塞主線程
主線程安全，允許你在主線程中調用任意 suspend(掛起) 函數
爲了解決這些問題，協程基於基礎函數添加了 suspend 和 resume。當特定線程上的所有協程都被掛起，該線程就可以做其他工作了。
但是，協程本身並不能幫助你追蹤正在進行的任務。同時擁有並掛起數百甚至上千的協程是不可能的。儘管協程是輕量的，但它們執行的任務並不是，例如文件讀寫，網絡請求等。
使用代碼手動追蹤一千個協程的確是很困難的。你可以嘗試去追蹤它們，並且手動保證它們最後會完成或者取消，但是這樣的代碼冗餘，而且容易出錯。如果你的代碼不夠完美，你將失去對一個協程的追蹤，我把它稱之爲任務泄露。
任務泄露就像內存泄露一樣，而且更加糟糕。對於已經丟失泄露的協程，除了內存消耗之外，它還會恢復自己來消耗 CPU，磁盤，甚至啓動一個網絡請求。
泄露的協程會浪費內存，CPU，磁盤，甚至發送一個不需要的網絡請求。
爲了避免泄露協程，Kotlin 引入了 structured concurrency(結構化併發)。結構化並集合了語言特性和最佳實踐，遵循這個原則將幫助你追蹤協程中的所有任務。
在 Android 中，我們使用結構化併發可以做三件事：
取消不再需要的任務
追蹤所有正在進行的任務
協程失敗時的錯誤信號
讓我們深入探討這幾點，來看看結構化併發是如何幫助我們避免丟失對協程的追蹤以及任務泄露。
通過作用域取消任務
在 Kotlin 中，協程必須運行在 CoroutineScope 中。CoroutineScope 會追蹤你的協程，即使協程已經被掛起。不同於上一篇文章中說過的 Dispatchers，它實際上並不執行協程，它僅僅只是保證你不會丟失對協程的追蹤。
爲了保證所有的協程都被追蹤到，Kotlin 不允許你在沒有 CoroutineScope 的情況下開啓新的協程。你可以把 CoroutineScope 想象成具有特殊能力的輕量級的 ExecutorServicce。它賦予你創建新協程的能力，這些協程都具備我們在上篇文章中討論過的掛起和恢復的能力。
CoroutineScope 會追蹤所有的協程，並且它也可以取消所有由他開啓的協程。這很適合 Android 開發者，當用戶離開當前頁面後，可以保證清理掉所有已經開啓的東西。
CoroutineScope 會追蹤所有的協程，並且它也可以取消所有由他開啓的協程。
啓動新的協程
有一點需要注意的是，你不是在任何地方都可以調用掛起函數。掛起和恢復機制要求你從普通函數切換到協程。
啓動協程有兩種方法，且有不同的用法：
使用 launch 協程構建器啓動一個新的協程，這個協程是沒返回值的
使用 async 協程構建器啓動一個新的協程，它允許你返回一個結果，通過掛起函數
await來獲取。
在大多數情況下，如何從一個普通函數啓動協程的答案都是使用 launch。因爲普通函數是不能調用 await 的（記住，普通函數不能直接調用掛起函數）。稍後我們會討論什麼時候應該使用 async。
你應該調用 launch 來使用協程作用域啓動一個新的協程。
scope.launch {
// This block starts a new coroutine
// "in" the scope.
//
// It can call suspend functions
fetchDocs()
}
你可以把 launch 想象成一座橋樑，連接了普通函數中的代碼和協程的世界。在 launch 內部，你可以調用掛起函數，並且創建主線程安全性，就像上篇文章中提到的那樣。
Launch 是把普通函數帶進協程世界的橋樑。
提示：
launch和async很大的一個區別是異常處理。async期望你通過調用await來獲取結果（或異常），所以它默認不會拋出異常。這就意味着使用async啓動新的協程，它會悄悄的把異常丟棄。
由於 launch 和 async 只能在 CoroutineScope 中使用，所以你創建的每一個協程都會被協程作用域追蹤。Kotlin 不允許你創建未被追蹤的協程，這樣可以有效避免任務泄露。
在 ViewModel 中啓動
如果一個 CoroutineScope 追蹤在其中啓動的所有協程，launch 會新建一個協程，那麼你應該在何處調用 launch 並將其置於協程作用域中呢？還有，你應該在什麼時候取消在作用域中啓動的所有協程呢？
在 Android 中，通常將 CoroutineScope 和用戶界面相關聯起來。這將幫助你避免協程泄露，並且使得用戶不再需要的 Activity 或者 Fragment 不再做額外的工作。當用戶離開當前頁面，與頁面相關聯的 CoroutineScope 將取消所有工作。
結構化併發保證當協程作用域取消，其中的所有協程都會取消。
當通過 Android Architecture Components 集成協程時，一般都是在 ViewModel 中啓動協程。這裏是許多重要任務開始工作的地方，並且你不必擔心旋轉屏幕會殺死協程。
爲了在 ViewModel 中使用協程，你可以來自 lifecycle-viewmodel-ktx:2.1.0-
alpha04 這個庫的 viewModelScope。viewModelScope 即將在 Android Lifecycle v2.1.0 發佈，現在仍然是 alpha 版本。關於 viewModelScope 的原理可以閱讀 這篇博客。既然這個庫目前還是 alpha 版本，就可能會有 bug，API 也可能發生變動。如果你找到了 bug，可以在 這裏 提交。
看一下使用的例子：
class MyViewModel(): ViewModel() {
fun userNeedsDocs() {
// Start a new coroutine in a ViewModel
viewModelScope.launch {
fetchDocs()
}
}
}
當 viewModelScope 被清除（即 onCleared() 被調用）時，它會自動取消由它啓動的所有協程。這肯定是正確的行爲，當我們還沒有讀取到文檔，用戶已經關閉了 app，我們還繼續請求的話只是在浪費電量。
爲了更高的安全性，協程作用域會自動傳播。如果你啓動的協程中又啓動了另一個協程，它們最終會在同一個作用域中結束。這就意味着你依賴的庫通過你的 viewModelScope 啓動了新的協程，你就有辦法取消它們了！
Warning: Coroutines are cancelled cooperatively by throwing a
CancellationException when the coroutine is suspended. Exception
handlers that catch a top-level exception like Throwable will catch
this exception. If you consume the exception in an exception handler, or
never suspend, the coroutine will linger in a semi-canceled state.（這段沒有理解）
所以，當你需要協程和 ViewModel 的生命週期保持一致時，使用 viewModelScope 來從普通函數切換到協程。那麼，由於 viewModelScope 會自動取消協程，編寫下面這樣的無限循環是沒有問題的，不會造成泄露。
fun runForever() {
// start a new coroutine in the ViewModel
viewModelScope.launch {
// cancelled when the ViewModel is cleared
while(true) {
delay(1_000)
// do something every second
}
}
}
使用 viewModelScope，你可以確保任何工作，即使是死循環，都能在不再需要執行的時候將其取消。
追蹤任務
啓動一個協程是沒問題的，很多時候也正是這樣做的。通過一個協程，進行網絡請求，保存數據到數據庫。
有時候，情況會稍微有點複雜。如果你想在一個協程中同時進行兩個網絡請求，你就需要啓動更多的協程。
爲了啓動更多的協程，任何掛起函數都可以使用 coroutineScope 或者 supervisorScope 構建器來新建協程。這個 API，說實話有點讓人困惑。coroutineScope 構建器和 CoroutineScope 是兩個不同的東西，卻只有一個字母不一樣。
在任何地方啓動新協程，這可能會導致潛在的任務泄露。調用者可能都不知道新協程的啓動，它又如何其跟蹤呢？
結構化併發幫助我們解決了這個問題。它給我們提供了一個保障，保證當掛起函數返回時，它的所有工作都已經完成。
結構化併發保證當掛起函數返回時，它的所有任務都已經完成。
下面是使用 coroutineScope 來查詢文檔的例子：
suspend fun fetchTwoDocs() {
coroutineScope {
launch { fetchDoc(1) }
async { fetchDoc(2) }
}
}
在這個例子中，同時從網絡讀取兩個文檔。第一個是在由 launch 啓動的協程中執行，它不會給調用者返回任何結果。
第二個使用的是 async，所以文檔可以返回給調用者。這裏例子有點奇怪，通常兩個文檔都會使用 async。但是我只是想向你展示你可以根據你的需求混合使用 launch 和 async。
coroutineScope 和 supervisorScope 讓你可以安全的在掛起函數中啓動協程。
儘管上面的代碼沒有在任何地方顯示的聲明要等待協程的執行完成，看起來當協程還在運行的時候，fetDocs 方法就會返回。
爲了結構化併發和避免任務泄露，我們希望確保當掛起函數（例如 fetchDocs）返回時，它的所有任務都已經完成。這就意味着，由 fetchDocs 啓動的所有協程都會先於它返回之前執行結束。
Kotlin 通過 coroutineScope 構建器確保 fetchDocs 中的任務不會泄露。coroutineScope 構建器直到在其中啓動的所有協程都執行結束時纔會掛起自己。正因如此，在 coroutineScope 中的所有協程尚未結束之前就從 fetchDocs 中返回是不可能的。
許多許多任務
現在我們已經探索瞭如何追蹤一個和兩個協程，現在是時候來嘗試追蹤一千個協程了！
看一下下面的動畫：
這個例子展示了同時進行一千次網絡請求。這在真實的代碼中是不建議的，會浪費大量資源。
上面的代碼中，我們在 coroutineScope 中通過 launch 啓動了一千個協程。你可以看到它們是如何連接起來的。由於我們是在掛起函數中，所以某個地方的代碼一定是使用了 CoroutineScope 來啓動協程。對於這個 CoroutineScope，我們一無所知，它可能是 viewModelScope 或者定義在其他地方的 CoroutineScope。無論它是什麼作用域，coroutineScope 構建器都會把它當做新建作用域的父親。
在 coroutineScope 代碼塊中，launch 將在新的作用域中啓動協程。當協程完成啓動，這個新的作用域將追蹤它。最後，一旦在 coroutineScope 中啓動的所有協程都完成了，loadLots 就可以返回了。
Note: the parent-child relationship between scopes and coroutines is
created using Job objects. But you can often think of the relationship
between coroutines and scopes without diving into that level.coroutineScope 和 supervisorScope 會等待所有子協程執行結束。
這裏有很多事情在進行，其中最重要的就是使用 coroutineScope 或者 supervisorScope，你可以在任意掛起函數中安全的啓動協程。儘管這將啓動一個新協程，你也不會意外的泄露任務，因爲只有所有新協程都完成了你纔可以掛起調用者。
很酷的是 coroutineScope 可以創建子作用域。如果父作用域被取消，它會將取消動作傳遞給所有的新協程。如果調用者是 viewModelScope，當用戶離開頁面是，所有的一千個協程都會自動取消。多麼的整潔！
在我們移步談論異常處理之前，有必要來討論一下 coroutineScope 和 supervisorScope。它們之間最大的不同就是，當其中任意一個子協程失敗時，coroutineScope 會取消。所以，如果一個網絡請求失敗了，其他的所有請求都會立刻被取消。如果你想繼續執行其他請求的話，你可以使用 supervisorScope，當一個子協程失敗時，它不會取消其他的子協程。
協程失敗的異常處理
在協程中，錯誤也是用過拋出異常來發出信號，和普通函數一樣。掛起函數的異常將在 resume 的時候重新拋出給調用者。和普通函數一樣，你不會被限制使用 try/catch 來處理錯誤，你也可以按你喜歡的方式來處理異常。
但是，有一些情況下，協程中的異常會丟失。
val unrelatedScope = MainScope()
// example of a lost error
suspend fun lostError() {
// async without structured concurrency
unrelatedScope.async {throw InAsyncNoOneCanHearYou("except")
}
}
注意，上面的代碼中聲明瞭一個未經關聯的協程作用域，並且未通過結構化併發啓動新協程。記住我開始說過的，結構化併發集合了語言特性和最佳實踐，在掛起函數中引入未經關聯的協程作用並不是結構化併發的最佳實踐。
上面代碼中的錯誤會丟失，因爲 async 認爲你會調用 await，這時候會重新拋出異常。但是如果你沒有調用 await，這個錯誤將永遠被保存，靜靜的等待被發現。
結構化併發保證當一個協程發生錯誤，它的調用者或者作用域可以發現。
如果我們使用結構化併發寫上面的代碼，異常將會正確的拋給調用者。
suspend fun foundError() {
coroutineScope {
async {
throw StructuredConcurrencyWill("throw")
}
}
}
由於 coroutineScope 會等待所有子協程執行完成，所以當子協程失敗時它也會知道。當 coroutineScope 啓動的協程拋出了異常，coroutineScope 會將異常扔給調用者。如果使用 coroutineScope 代替 supervisorScope，當異常拋出時，會立刻停止所有的子協程。
使用結構化併發
在這篇文章中，我介紹了結構化併發，以及在代碼中配合 ViewModel 使用來避免任務泄露。我還談論了它是如何讓掛起函數更加簡單。兩者都確保在返回之前完成任務，也可以確保正確的異常處理。
我們使用非結構化併發，很容易造成意外的任務泄露，這對調用者來說是未知的。任務將變得不可取消，也不能保證異常被正確的拋出。這會導致我們的代碼產生一些模糊的錯誤。
使用未關聯的 CoroutineScope（注意是大寫字母 C），或者使用全局作用域 GlobalScope ，會導致非結構化併發。只有在少數情況下，你需要協程的生命週期長於調用者的作用域時，才考慮使用非結構化併發。通常情況下，你都應該使用結構化併發來追蹤協程，處理異常，擁有良好的取消機制。
如果你有非結構化併發的經驗，那麼結構化併發的確需要一些時間來適應。這種保障使得和掛起函數交互更加安全和簡單。我們應該儘可能的使用結構化併發，因爲它使得代碼更加簡單和易讀。
在文章的開頭，我列舉了結構化併發幫助我們解決的三個問題：
取消不再需要的任務
追蹤所有正在進行的任務
協程失敗時的錯誤信號
結構化併發給予我們如下保證：
當作用域取消，其中的協程也會取消
當掛起函數返回，其中的所有任務都已完成
當協程發生錯誤，其調用者會得到通知
這些加在一起，使得我們的代碼更加安全，簡潔，並且幫助我們避免任務泄露。
What's Next?
這篇文章中，我們探索瞭如何在 Android 的 ViewModel 中啓動協程，以及如何使用結構化併發來優化代碼。
下一篇中，我們將更多的討論在特定情況下使用協程。
文章首發微信公衆號：
秉心說， 專注 Java 、 Android 原創知識分享，LeetCode 題解。更多 JDK 源碼解析，掃碼關注我吧！
