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的一個概括解釋，后面將會針對各種場景再進行詳細梳理，希望大家喜歡，
青山不改，綠水長流，咱們下期見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/555313.html
標籤：其他
下一篇：返回列表