明天咱們來聊聊Kotlin的協程Coroutine。
如果你還沒有接觸過協程，舉薦你先瀏覽這篇入門級文章What? 你還不曉得Kotlin Coroutine?
如果你曾經接觸過協程，置信你都有過以下幾個疑難：
協程到底是個什么貨色？
協程的suspend有什么作用，工作原理是怎么的？
協程中的一些要害名稱(例如：Job、Coroutine、Dispatcher、CoroutineContext與CoroutineScope)它們之間到底是怎么樣的關系？
協程的所謂非阻塞式掛起與復原又是什么？
協程的外部實現原理是怎么樣的？
…
接下來的一些文章試著來剖析一下這些疑難，也歡送大家一起退出來探討。
協程是什么
這個疑難很簡略，只有你不是野路子接觸協程的，都應該可能曉得。因為官網文檔中曾經明確給出了定義。
上面來看下官網的原話(也是這篇文章最具備底氣的一段話)。
協程是一種并發設計模式，您能夠在 Android 平臺上應用它來簡化異步執行的代碼。
敲黑板劃重點：協程是一種并發的設計模式。
所以并不是一些人所說的什么線程的另一種體現。盡管協程的外部也應用到了線程。但它更大的作用是它的設計思維。將咱們傳統的Callback回調形式進行打消。將異步編程趨近于同步對齊。
解釋了這么多，最初咱們還是間接點，來看下它的長處
輕量：您能夠在單個線程上運行多個協程，因為協程反對掛起，不會使正在運行協程的線程阻塞。掛起比阻塞節儉內存，且反對多個并行操作。
內存泄露更少：應用結構化并發機制在一個作用域內執行多個操作。
內置勾銷反對：勾銷性能會主動通過正在運行的協程層次結構流傳。
Jetpack集成：許多 Jetpack 庫都蘊含提供全面協程反對的擴大。某些庫還提供本人的協程作用域，可供您用于結構化并發。
suspend
suspend是協程的關鍵字，每一個被suspend潤飾的辦法都必須在另一個suspend函數或者Coroutine協程程序中進行調用。
第一次看到這個定義不曉得你們是否有疑難，反正小憩我是很納悶，為什么suspend潤飾的辦法須要有這個限度呢？不加為什么就不能夠，它的作用到底是什么？
當然，如果你有關注我之前的文章，應該就會有所理解，因為在重溫Retrofit源碼，笑看協程實現這篇文章中我曾經有簡略的提及。
這里波及到一種機制俗稱CPS(Continuation-Passing-Style)。每一個suspend潤飾的辦法或者lambda表達式都會在代碼調用的時候為其額定增加Continuation類型的參數。
@GET("/v2/news")
suspend fun newsGet(@QueryMap params: Map): NewsResponse
下面這段代碼通過CPS轉換之后真正的面目是這樣的
@GET("/v2/news")
fun newsGet(@QueryMap params: Map, c: Continuation): Any?
通過轉換之后，原有的返回類型NewsResponse被增加到新增的Continutation參數中，同時返回了Any?類型。這里可能會有所疑難？返回類型都變了，后果不就出錯了嗎？
其實不是，Any?在Kotlin中比擬非凡，它能夠代表任意類型。
當suspend函數被協程掛起時，它會返回一個非凡的標識COROUTINE_SUSPENDED，而它實質就是一個Any；當協程不掛起進行執行時，它將返回執行的后果或者引發的異樣。這樣為了讓這兩種狀況的返回都反對，所以應用了Kotlin獨有的Any?類型。
返回值搞明確了，當初來說說這個Continutation參數。
首先來看下Continutation的源碼
public interface Continuation {
/**
* The context of the coroutine that corresponds to this continuation.
*/
public val context: CoroutineContext
/**
* Resumes the execution of the corresponding coroutine passing a successful or failed [result] as the
* return value of the last suspension point.
*/
public fun resumeWith(result: Result)
}
context是協程的上下文，它更多時候是CombinedContext類型，相似于協程的匯合，這個后續會詳情闡明。
resumeWith是用來喚醒掛起的協程。后面曾經說過協程在執行的過程中，為了避免阻塞應用了掛起的個性，一旦協程外部的邏輯執行結束之后，就是通過該辦法來喚起協程。讓它在之前掛起的地位繼續執行上來。
所以每一個被suspend潤飾的函數都會獲取下層的Continutation，并將其作為參數傳遞給本人。既然是從下層傳遞過去的，那么Continutation是由誰創立的呢？
其實也不難猜到，Continutation就是與協程創立的時候一起被創立的。
GlobalScope.launch {
}
launch的時候就曾經創立了Continutation對象，并且啟動了協程。所以在它外面進行掛起的協程傳遞的參數都是這個對象。
簡略的了解就是協程應用resumeWith替換傳統的callback，每一個協程程序的創立都會隨同Continutation的存在，同時協程創立的時候都會主動回調一次Continutation的resumeWith辦法，以便讓協程開始執行。
CoroutineContext
協程的上下文，它蘊含用戶定義的一些數據匯合，這些數據與協程密切相關。它相似于map匯合，能夠通過key來獲取不同類型的數據。同時CoroutineContext的靈活性很強，如果其須要扭轉只需應用以后的CoroutineContext來創立一個新的CoroutineContext即可。
來看下CoroutineContext的定義
public interface CoroutineContext {
/**
* Returns the element with the given [key] from this context or `null`.
*/
public operator fun get(key: Key): E?
/**
* Accumulates entries of this context starting with [initial] value and applying [operation]
* from left to right to current accumulator value and each element of this context.
*/
public fun fold(initial: R, operation: (R, Element) -> R): R
/**
* Returns a context containing elements from this context and elements from other [context].
* The elements from this context with the same key as in the other one are dropped.
*/
public operator fun plus(context: CoroutineContext): CoroutineContext = ...
/**
* Returns a context containing elements from this context, but without an element with
* the specified [key].
*/
public fun minusKey(key: Key): CoroutineContext
/**
* Key for the elements of [CoroutineContext]. [E] is a type of element with this key.
*/
public interface Key
/**
* An element of the [CoroutineContext]. An element of the coroutine context is a singleton context by itself.
*/
public interface Element : CoroutineContext {..}
}
每一個CoroutineContext都有它惟一的一個Key其中的類型是Element，咱們能夠通過對應的Key來獲取對應的具體對象。說的有點形象咱們間接通過例子來理解。
var context = Job() + Dispatchers.IO + CoroutineName("aa")
LogUtils.d("$context, ${context[CoroutineName]}")
context = context.minusKey(Job)
LogUtils.d("$context")
// 輸入
[JobImpl{Active}@158b42c, CoroutineName(aa), LimitingDispatcher@aeb0f27[dispatcher = DefaultDispatcher]], CoroutineName(aa)
[CoroutineName(aa), LimitingDispatcher@aeb0f27[dispatcher = DefaultDispatcher]]
Job、Dispatchers與CoroutineName都實現了Element接口。
如果須要聯合不同的CoroutineContext能夠間接通過+拼接，實質就是應用了plus辦法。
public operator fun plus(context: CoroutineContext): CoroutineContext =
if (context === EmptyCoroutineContext) this else // fast path -- avoid lambda creation
context.fold(this) { acc, element ->
val removed = acc.minusKey(element.key)
if (removed === EmptyCoroutineContext) element else {
// make sure interceptor is always last in the context (and thus is fast to get when present)
val interceptor = removed[ContinuationInterceptor]
if (interceptor == null) CombinedContext(removed, element) else {
val left = removed.minusKey(ContinuationInterceptor)
if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else
CombinedContext(CombinedContext(left, element), interceptor)
}
}
}
plus的實現邏輯是將兩個拼接的CoroutineContext封裝到CombinedContext中組成一個拼接鏈，同時每次都將ContinuationInterceptor增加到拼接鏈的最尾部.
那么CombinedContext又是什么呢？
internal class CombinedContext(
private val left: CoroutineContext,
private val element: Element
) : CoroutineContext, Serializable {
override fun get(key: Key): E? {
var cur = this
while (true) {
cur.element[key]?.let { return it }
val next = cur.left
if (next is CombinedContext) {
cur = next
} else {
return next[key]
}
}
}
...
}
留神看它的兩個參數，咱們間接拿下面的例子來剖析
Job() + Dispatchers.IO
(Job, Dispatchers.IO)
Job對應于left，Dispatchers.IO對應element。如果再拼接一層CoroutineName(aa)就是這樣的
((Job, Dispatchers.IO),CoroutineName)
性能相似與鏈表，但不同的是你可能拿到上一個與你相連的整體內容。與之對應的就是minusKey辦法，從匯合中移除對應Key的CoroutineContext實例。
有了這個根底，咱們再看它的get辦法就很清晰了。先從element中去取，沒有再從之前的left中取。
那么這個Key到底是什么呢？咱們來看下CoroutineName
public data class CoroutineName(
/**
* User-defined coroutine name.
*/
val name: String
) : AbstractCoroutineContextElement(CoroutineName) {
/**
* Key for [CoroutineName] instance in the coroutine context.
*/
public companion object Key : CoroutineContext.Key
/**
* Returns a string representation of the object.
*/
override fun toString(): String = "CoroutineName($name)"
}
很簡略它的Key就是CoroutineContext.Key，當然這樣還不夠，須要持續聯合對于的operator get辦法，所以咱們再來看下Element的get辦法
public override operator fun get(key: Key): E? =
@Suppress("UNCHECKED_CAST")
if (this.key == key) this as E else null
這里應用到了Kotlin的operator操作符重載的個性。那么上面的代碼就是等效的。
context.get(CoroutineName)
context[CoroutineName]
所以咱們就能夠間接通過相似于Map的形式來獲取整個協程中CoroutineContext匯合中對應Key的CoroutineContext實例。
本篇文章次要介紹了suspend的工作原理與CoroutineContext的內部結構。心愿對學習協程的搭檔們可能有所幫忙，敬請期待后續的協程剖析。
我的項目
android_startup: 提供一種在利用啟動時可能更加簡略、高效的形式來初始化組件，優化啟動速度。不僅反對Jetpack App Startup的全副性能，還提供額定的同步與異步期待、線程管制與多過程反對等性能。
AwesomeGithub: 基于Github客戶端，純練習我的項目，反對組件化開發，反對賬戶明碼與認證登陸。應用Kotlin語言進行開發，我的項目架構是基于Jetpack&DataBinding的MVVM；我的項目中應用了Arouter、Retrofit、Coroutine、Glide、Dagger與Hilt等風行開源技術。
flutter_github: 基于Flutter的跨平臺版本Github客戶端，與AwesomeGithub絕對應。
android-api-analysis: 聯合具體的Demo來全面解析Android相干的知識點, 幫忙讀者可能更快的把握與了解所論述的要點。
daily_algorithm: 每日一算法，由淺入深，歡送退出一起共勉。
：File類)
