> Kotlin的協程自推出以來，受到了越來越多Android開發者的追捧。另一方面由於它龐大的API，也將相當一部分開發者拒之門外。本篇試圖從協程的幾個重要概念入手，在複雜API中還原出它本來的面目，以全新的角度帶讀者走進Kotlin協程世界。 ### 什麼是協程 在很多有關協程的文章中，描述協程 ...
Kotlin的協程自推出以來，受到了越來越多Android開發者的追捧。另一方面由於它龐大的API，也將相當一部分開發者拒之門外。本篇試圖從協程的幾個重要概念入手，在複雜API中還原出它本來的面目，以全新的角度帶讀者走進Kotlin協程世界。
什麼是協程
在很多有關協程的文章中，描述協程通常會用這樣的一句描述——協程比線程更加輕量，是可取消的。這句話沒有錯，這兩個都是協程的優點，但是並不是特點，它並沒有解釋協程是什麼。那麼什麼是協程的特點呢，我覺得可以先用線程做個類比，解釋一個概念最好的辦法就是類比。 我不打算使用科學嚴謹的描述，我想給線程一個我自己的定義——線程是一個可供CPU調度的執行單元，它有自己的執行塊，可以獨立地執行邏輯。我特意將線程的三個關鍵特征列舉出來了：
- 線程由CPU調度
- 線程擁有自己的代碼塊
- 代碼塊需要才能調度執行
這是我對線程的直觀感受，並且這些特點是能從代碼上體現出來的。如Java中的Thread，它是線程的同時，也是一個實體對象，能通過API來認識它，使用它。而它的特別之處就是我上面列舉的三點，這些都是線程特有的。我試著用相同的思路來給協程下一個自己的定義——協程是由線程調度執行的執行單元，它也有自己的執行塊，可以獨立或者協同執行邏輯。其實Kotlin中的協程也有自己對應實體和操作API，甚至和線程的還很像(如生命周期），但是由於Kotlin對協程的封裝過於徹底，很多API沒有暴露出來，以至於我對協程的認識一直處於盲人摸象的狀態。另外，其實協程是有多種實現方式的，以下我的觀點僅針對Kotlin的協程實現，可能與其他語言的實現不一致。
Kotlin中的協程對象本質上來講就是個可執行的代碼塊， 執行的代碼就是創建協程傳遞進去的。除此之外它還有個最大的特點——協程是不和線程綁定的。它可以在某個時刻斷開當前的線程，然後在其他時候，附著到其他線程上。也就是說，它像一個乒乓球，線程就好比是球拍，它可以在球拍間反覆橫跳。所以，結合這兩個特點，官方給協程的定義是 一個可掛起的計算實體。我覺得這個定義不算精確，它只體現了掛起這個概念，沒有體現恢復的概念。我給它一個我自己的定義——一個可被調度的計算實體。
協程中幾個關鍵概念
明白了協程是什麼還不夠，因為Kotlin的協程還涉及到很多方面，有幾個關鍵概念需要理解。
掛起函數
提到Kotlin的協程就不得不提到掛起函數，這是Kotlin協程實現的最重要的概念之一。簡單來說，掛起函數是一種非同步實現方案，它是一個普通函數的前提下，還具備掛起和恢復的特性。 它是解決耗時計算和結果傳遞的一種方案。那麼它和我們常見的基於回調的方案相比，有什麼不同呢。在基於回調的方案中，計算過程和結果沒有關係，結果需要通過另一個對象，在計算完成後由計算過程手動傳遞，而這一過程是可能被反覆嵌套的，從而導致，一些本該是串列化的代碼，被割裂成幾個部分，分散到不同的代碼塊中。如以下讀寫文件的代碼
// asynchronously read into `buf`, and when done run the lambda
inChannel.read(buf) {
// this lambda is executed when the reading completes
bytesRead ->
...
...
process(buf, bytesRead)
// asynchronously write from `buf`, and when done run the lambda
outChannel.write(buf) {
// this lambda is executed when the writing completes
...
...
outFile.close()
}
}
同樣的邏輯，將read和write實現為掛起函數後，能寫成什麼樣呢？
launch {
// suspend while asynchronously reading
val bytesRead = inChannel.aRead(buf)
// we only get to this line when reading completes
...
...
process(buf, bytesRead)
// suspend while asynchronously writing
outChannel.aWrite(buf)
// we only get to this line when writing completes
...
...
outFile.close()
}
這是Kotlin官方給的一個例子，可以看出掛起函數的實現非常符合直覺，是和思考過程保持一致的，同時還減少了大量的嵌套。
為了更好地解釋掛起函數，我還需要引入了一個新的概念——掛起點。
掛起點是一個分界點，代表著從這個時刻之後，執行過程可能會轉移到其他地方執行，然後在某個時刻，再從這個點恢復，繼續往下執行。這個過程中，當前線程不會被阻塞。所以 掛起函數其實實現了非同步非阻塞的通信模式。
一句話總結，掛起函數是一種不阻塞當前線程，並能返回非同步計算結果的函數。
協程創建者
前面提到的掛起函數雖然好，但是有個限制，普通方法是不能調用掛起函數的，只能通過掛起函數調用。那麼就出現了先有雞還是先有蛋的問題。解決這個問題的方法就是協程創建者。launch, future, sequence都是協程創建者。顧名思義，協程創建者是用來創建協程對象的，除此之外和普通函數沒有區別。它們就是通往協程世界和掛起函數的大門。在這個大門裡，我們可以盡情地使用掛起函數，簡化我們的計算過程。當然，這些都不是固定不變的，這些函數都有多個配置參數，其中最重要的就是CoroutineContext。
CoroutineContext
CoroutineContext的作用是提供協程的各種配置信息，本質上就是保存非重覆元素的容器(Set)，裡面的元素可以根據Key獲取到（如調度器），稱之為元素（Element）。這裡，我忍不住想把它的介面定義放出來，因為實在是太美了。
interface CoroutineContext {
operator fun <E : Element> get(key: Key<E>): E?
fun <R> fold(initial: R, operation: (R, Element) -> R): R
operator fun plus(context: CoroutineContext): CoroutineContext
fun minusKey(key: Key<*>): CoroutineContext
interface Element : CoroutineContext {
val key: Key<*>
}
interface Key<E : Element>
}
以上就是Kotlin中對CoroutineContext的定義，這些API每個都有其巧妙的用途，讓人嘆服
-
get目的是根據Key獲取對應的對象，這個方法的奇特之處就是查詢參數。利用這個方法在執行某個操作之前判斷CoroutineContext是否有某個配置對象，從而實現一種許可權認證。 -
fold其實就是一種迭代演算法，可以對全部元素進行檢查。 -
plus這就很有意思了，它可以讓兩個對象合併起來，並且當key相同時使用右側的對象覆蓋左側的對象。這在我們的協程使用中絕對是最靈活的API了。我們可以使用+替換調原本的調度器，使用我們給定的調度器，而且看起來是那麼自然。 -
minusKey返回不包含指定key的context，相當於一種取反操作，這在某些情境下非常有用。
我覺得這應該算得上是對抽象的極致體現了，這個介面用簡單的API抽象了增刪改查四個操作，並且保留了強大的擴展性。在最開始接觸協程的時候，我常常對協程複雜的工作機制和簡單的參數配置產生了深深的懷疑，直到我看到了這個定義，我才明白它真正的強大之處，它不僅可以用系統預設的工作配置完成工作，還允許用戶實現自己的CoroutineContext來隨時替換掉預設配置，完成自己定製化的任務。
Continuation
Continuation不是Kotlin特有的概念，它在維基上的解釋是一種控制狀態的抽象表示。而在Kotlin中，它是對協程在掛起點的一個狀態抽象，這可能不太好理解，我們可以通過具體的API來將這個概念具體化。
interface Continuation<in T> {
val context: CoroutineContext
fun resumeWith(result: Result<T>)
}
它有個關鍵的函數——resumeWith，它表示在掛起狀態之後的某個時刻，通過這個狀態對象從原來的位置恢復過來。這是掛起函數實現的關鍵。而這裡面的控制狀態就是由參數體現了，成功或者失敗，所以它還有兩個擴展方法：
fun <T> Continuation<T>.resume(value: T)
fun <T> Continuation<T>.resumeWithException(exception: Throwable)
總結
協程是一個可被調度的計算實體，可通過協程創建者創建，在協程的代碼塊里可以使用掛起函數，它能必要的時候掛起，然後在條件滿足後恢復，完成非同步代碼的串列化編程。
以上就是理解協程的關鍵概念，在實際使用協程的過程中可能用不到很多，但是卻會對我們理解其運作過程很有幫助，也是寫出標準協程代碼的關鍵。Kotlin協程並沒有很多黑魔法，只是為了適用多種不同的使用場景，有了龐大的API，本篇文章就是對這些API的一個概括解釋，後面將會針對各種場景再進行詳細梳理，希望大家喜歡。
青山不改，綠水長流，咱們下期見！
