Kotlin的協程自推出以來，受到了越來越多Android開發者的追捧。另一方面由於它龐大的API，也將相當一部分開發者拒之門外。本篇試圖從協程的幾個重要概念入手，在複雜API中還原出它本來的面目，以全新的角度帶讀者走進Kotlin協程世界。
在很多有關協程的文章中，描述協程通常會用這樣的一句描述——協程比執行緒更加輕量，是可取消的。這句話沒有錯，這兩個都是協程的優點，但是並不是特點，它並沒有解釋協程是什麼。那麼什麼是協程的特點呢，我覺得可以先用執行緒做個類比，解釋一個概念最好的辦法就是類比。 我不打算使用科學嚴謹的描述，我想給執行緒一個我自己的定義——執行緒是一個可供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的作用是提供協程的各種設定資訊，本質上就是儲存非重複元素的容器(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不是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的一個概括解釋，後面將會針對各種場景再進行詳細梳理，希望大家喜歡。
青山不改，綠水長流，咱們下期見！