前言

Kotlin協(xié)程提供了一種新的異步執(zhí)行方式，但直接查看庫函數(shù)可能會有點(diǎn)混亂，本文中嘗試揭開協(xié)程的神秘面紗。

理論

它是什么

這是別人翻譯: 協(xié)程把異步編程放入庫中來簡化這類操作。程序邏輯在協(xié)程中順序表述，而底層的庫會將其轉(zhuǎn)換為異步操作。庫會將相關(guān)的用戶代碼打包成回調(diào)，訂閱相關(guān)事件，調(diào)度其執(zhí)行到不同的線程（甚至不同的機(jī)器），而代碼依然想順序執(zhí)行那么簡單。

我的理解：子任務(wù)程協(xié)作運(yùn)行，優(yōu)雅的處理異步問題解決方案。

它能干什么?

我在做安卓開發(fā)，它能替換掉Handler,AsyncTask 甚至是Rxjava來優(yōu)雅的解決異步問題。

下面讓我們從基礎(chǔ)開始吧，假設(shè)有一個名為launch可以用來啟動協(xié)程

private fun myHeavyFunction() { Log.e("Thread Running ", Thread.currentThread().name)}val job = launch { myHeavyFunction() }

上面的代碼是使用launch一種非常簡單的方法，返回Job一個異步執(zhí)行函數(shù)，Job代表一個協(xié)程coroutine作業(yè)，可以取消或查詢它的狀態(tài)。

override fun onStop() { if (job.isActive) {  job.cancel() }}

現(xiàn)在，如果查看我們的日志，檢查我們的函數(shù)實(shí)際運(yùn)行的是哪個線程？我們就會得到類似的結(jié)果

E / Thread運(yùn)行：ForkJoinPool.commonPool-worker-2

我們的代碼是在一個線程中運(yùn)行的，讓我們稍微了解一下launch本身:  

public fun launch( context:CoroutineContext =DefaultDispatcher, start:CoroutineStart CoroutineStart.DEFAULT, parent:Job?=null, onComp1etion:CompletionHand1er? =null, block:suspend CoroutineScope.()->Unit):Job{ 

再看看DefaultDispatcher的值是什么？

@Suppress("PropertyName ") public actual val DefaultDispatcher: CoroutineDispatcher = CommonPoolobject CommonPool:CoroutineDispatcher()

launch是將CoroutineContext作為第一個參數(shù)，這個參數(shù)值默認(rèn)為代表一個CommonPool線程池類的DefaultDispatcher，這個線程池類根據(jù)當(dāng)前CPU處理器總數(shù)創(chuàng)建一個帶有Executors的CoroutineContext。完整代碼在這里。

launch是一種協(xié)程構(gòu)建器，可以接受一個協(xié)程分配器CoroutineDispatcher，分配器實(shí)際上負(fù)責(zé)在單獨(dú)的線程中運(yùn)行代碼。

我們可以輕松創(chuàng)建自己的分配器：

val singleThreadDispatcher = newSingleThreadContext("singleThreadDispatcher")

newSingleThreadContext 由Kotlin協(xié)同程序庫本身提供，用于創(chuàng)建僅在單個線程上運(yùn)行的上下文。我們可以在此基礎(chǔ)上創(chuàng)建自己的函數(shù)：

fun <T> singleThreadAsync(block: () -> T): Job = launch(singleThreadDispatcher) { block.invoke() }job = singleThreadAsync { myHeavyFunction() }

下面是運(yùn)行后的日志

E / Thread運(yùn)行：singleThreadDispatcher

所以我們用我們自己的線程方案創(chuàng)建了我們自己的簡單協(xié)程:)

讓我們看看我們可以通過Dispatchers做更多事情：

object MyDispatcher : CoroutineDispatcher() { override fun dispatch(context: CoroutineContext, block: Runnable) {  thread {   block.run()  } }}object RxDispatcher : CoroutineDispatcher() { override fun dispatch(context: CoroutineContext, block: Runnable) {  Observable.fromCallable { block.run() }    .subscribeOn(Schedulers.io())    .subscribe {} }}object UIDispatcher : CoroutineDispatcher() { override fun dispatch(context: CoroutineContext, block: Runnable) {  Handler(Looper.getMainLooper()).post {   block.run()  } }}

在這里，我們創(chuàng)建了三個不同的分配器程序并重載了dispatch方法， 我們在每個dispatch方法中以不同的方式執(zhí)行Runnable塊，也就是一個簡單的線程，這個異步線程是使用RxJava實(shí)現(xiàn)，而Android主線程是使用Handler完成。

如果我們用這些分配器程序執(zhí)行我們的函數(shù)，我們會得到這些日志

E / Thread Running：Thread-582 
E / Thread Running：RxCachedThreadScheduler-1 
E / Thread Running：main

這真的顯示了協(xié)同程序的強(qiáng)大功能，因?yàn)镃oroutines只是語言語法，它們與運(yùn)行它們的平臺無關(guān)。不同線程的職責(zé)分配只需開發(fā)人員使用一組函數(shù)就能實(shí)現(xiàn)，他可以在Rx線程或主線程上執(zhí)行他喜歡的協(xié)同程序。

協(xié)同程序就像空的冰淇淋甜筒，你可以選擇你想要冰淇淋的填入。

無線程Thread-less異步

編寫異步代碼傳統(tǒng)上被認(rèn)為是一種線程工作，其實(shí)并不總是如此，讓我們看看如何使用Coroutines解決這個問題

讓我們看看一系列函數(shù)執(zhí)行

mySmallFunction1() myHeavyFunction() // Takes 3 seconds to executemySmallFunction2()//Order運(yùn)行順序E/mySmallFunction1 running on: mainE/myHeavyFunction running on: mainE/mySmallFunction2 running on: main

現(xiàn)在因?yàn)閙yHeavyFunction()函數(shù)需要很長時間才能執(zhí)行，所以我們可能想要異步執(zhí)行它。

mySmallFunction1()thread { myHeavyFunction() } //Execution in a separate thread.mySmallFunction2()//Order順序E/mySmallFunction1 running on: mainE/mySmallFunction2 running on: mainE/myHeavyFunction running on: Thread-697

這里我們將myHeavyFunction()遷移到一個單獨(dú)的線程并異步執(zhí)行它，但是如果我們這樣做：

mySmallFunction1()launch(UI) { myHeavyFunction() }mySmallFunction2()//OrderE/mySmallFunction1 running on: mainE/mySmallFunction2 running on: mainE/myHeavyFunction running on: main

這里我們在主線程上運(yùn)行的Coroutine上下文（UI：由coroutine-android庫提供）中執(zhí)行重量函數(shù)，執(zhí)行仍然是異步的，因?yàn)镃oroutines是通過暫停這部分函數(shù)處理，但函數(shù)執(zhí)行仍然發(fā)生在主線程上，而不創(chuàng)建額外的線程。

實(shí)戰(zhàn)協(xié)程

在大多數(shù)情況下，我們需要來自一個異步執(zhí)行的回調(diào)，這樣我們就可以通過回調(diào)函數(shù)來更新UI等，這里就可以使用Deferred語法：

Deferred本身繼承擴(kuò)展了Job，但增加一個額外的功能，它可以在函數(shù)完成執(zhí)行后返回未來的值。

讓我們看看我們在這里做了什么:

fun <T> asyncExecutor(block: () -> T, response: (T) -> Unit): Job { return launch(UI) {  val deferred = async(singleThreadDispatcher) { block.invoke() }  response.invoke(deferred.await()) }}

讓我們分析一下：

1. launch（UI）使用Android的UI所在的線程上下文創(chuàng)建一個協(xié)同Job。

2. 我們通過async異步創(chuàng)建了另一個協(xié)同程序，其中包含我們需要調(diào)用的函數(shù)，唯一的區(qū)別是：這個協(xié)程返回一個Deferred值，async是協(xié)程庫的一部分。

3. 我們調(diào)用await（）函數(shù)來捕獲Deferred的未來值。這是在UI所在線程上下文中捕獲的。

總而言之，我們創(chuàng)建了一個異步執(zhí)行程序，我們可以在其中傳遞函數(shù)并讓它們異步執(zhí)行，然后將值返回給UI線程。

現(xiàn)在我們在哪里可以使用它 ? 數(shù)據(jù)庫查詢

// Insert into DB without callbacksingleThreadAsync { movieDataBase.movieDao().insert(movieObject) }// Get List of movies from DB and filter itasyncExecutor({ movieDataBase.movieDao().getAll() }, { movieList -> movieList   .filter { it.isFavorite }   .map { it.originalLanguage = "English" } //Dispatch to UI})

我們將插入到DB的請求變成了一個發(fā)射就可以忘記不用等待結(jié)果的異步請求，這是使用singleThreadAsync實(shí)現(xiàn)的 。

當(dāng)我們從DB檢索數(shù)據(jù)時，我們可以使用我們的asyncExecutor來檢索對象列表，然后使用Collection Framework中的運(yùn)算符發(fā)揮所有kotlin優(yōu)點(diǎn)啦！

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對VeVb武林網(wǎng)的支持。