前言

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

理論

它是什么

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

我的理解：子任務(wù)程協(xié)作運行，優(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ù)實際運行的是哪個線程？我們就會得到類似的結(jié)果

E / Thread運行：ForkJoinPool.commonPool-worker-2

我們的代碼是在一個線程中運行的，讓我們稍微了解一下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 = CommonPool

object 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，分配器實際上負(fù)責(zé)在單獨的線程中運行代碼。

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

val singleThreadDispatcher = newSingleThreadContext("singleThreadDispatcher")

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

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

job = singleThreadAsync { myHeavyFunction() }

下面是運行后的日志

E / Thread運行：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實現(xiàn)，而Android主線程是使用Handler完成。

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

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

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

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

無線程Thread-less異步

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

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

mySmallFunction1() 
myHeavyFunction() // Takes 3 seconds to execute
mySmallFunction2()
//Order運行順序
E/mySmallFunction1 running on: main
E/myHeavyFunction running on: main
E/mySmallFunction2 running on: main

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

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

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

mySmallFunction1()
launch(UI) { myHeavyFunction() }
mySmallFunction2()
//Order
E/mySmallFunction1 running on: main
E/mySmallFunction2 running on: main
E/myHeavyFunction running on: main

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

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

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

Deferred本身繼承擴展了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 callback
singleThreadAsync { movieDataBase.movieDao().insert(movieObject) }

// Get List of movies from DB and filter it
asyncExecutor({ movieDataBase.movieDao().getAll() }, { movieList ->
 movieList
   .filter { it.isFavorite }
   .map { it.originalLanguage = "English" }
 //Dispatch to UI
})

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

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

總結(jié)

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

最新評論