为什么我要使用 Kotlin 的协程？
似乎 RxKotlin 库更加通用。
相比之下，Kotlin 的协程看起来明显不那么强大，而且使用起来更麻烦。
我对协程的看法基于 this design talk by Andrey Breslav (JetBrains)
演讲幻灯片是 accessible here.

编辑(感谢@hotkey):
关于协程当前状态的更好来源 here.

最佳答案

免责声明:这个答案的一部分是无关紧要的，因为协程现在有流 API，与 Rx 非常相似。如果您想要最新的答案，请跳至上次编辑。
Rx 中有两部分； Observable 模式，以及一组用于操作、转换和组合它们的可靠操作符。 Observable 模式本身并没有做太多事情。与协程相同；这只是处理异步的另一种范式。您可以比较回调、Observable 和协程的优缺点来解决给定的问题，但您无法将范式与功能齐全的库进行比较。这就像将语言与框架进行比较。
Kotlin 协程如何比 RxKotlin 更好？还没有使用协程，但它看起来类似于 C# 中的 async/wait。您只需编写顺序代码，一切都和编写同步代码一样简单......除了它异步执行。更容易掌握。
为什么我要使用 kotlin 协程？我会自己回答。大多数时候我会坚持使用 Rx，因为我喜欢事件驱动的架构。但是如果出现我正在编写顺序代码的情况，并且我需要在中间调用一个异步方法，我会很乐意利用协程来保持这种方式并避免将所有内容都包装在 Observable 中。
编辑 :现在我正在使用协程，是时候进行更新了。
RxKotlin 只是在 Kotlin 中使用 RxJava 的语法糖，所以我将在下面讨论 RxJava 而不是 RxKotlin。协程是比 RxJava 更低的杠杆和更通用的概念，它们服务于其他用例。也就是说，有一个用例可以比较 RxJava 和协程( channel )，它异步传递数据。协程在这里比 RxJava 有明显的优势:
协程更好地处理资源

在 RxJava 中，您可以将计算分配给调度程序，但 subscribeOn()和 ObserveOn()令人困惑。每个协程都被赋予一个线程上下文并返回到父上下文。对于 channel ，双方(生产者、消费者)都在自己的上下文中执行。协程对线程或线程池的影响更直观。

协程可以更好地控制这些计算何时发生。例如，您可以传递手动( yield )、优先级( select )、并行化(多个 producer/actor on channel )或锁定资源( Mutex )用于给定的计算。在服务器(RxJava 首先出现的地方)上可能无关紧要，但在资源有限的环境中可能需要这种级别的控制。

由于它的 react 性质，背压不适用于 RxJava。在另一端send() to channel 是一个挂起函数，当达到 channel 容量时挂起。这是大自然赋予的开箱即用的背压。您也可以 offer()到 channel ，在这种情况下，调用永远不会挂起，而是返回 false如果 channel 已满，则有效再现onBackpressureDrop()来自 RxJava。或者，您可以编写自己的自定义背压逻辑，这对于协程来说并不困难，尤其是与使用 RxJava 做同样的事情相比。

还有另一个用例，协程大放异彩，这将回答您的第二个问题“我为什么要使用 Kotlin 协程？”。协程是后台线程或 AsyncTask 的完美替代品(安卓)。就像 launch { someBlockingFunction() } 一样简单.当然，您也可以使用 RxJava 来实现这一点，使用 Schedulers和 Completable也许。你不会(或很少)使用观察者模式和作为 RxJava 签名的运算符，暗示这项工作超出了 RxJava 的范围。 RxJava 的复杂性(这里是一种无用的税收)将使您的代码比 Coroutine 的版本更加冗长和简洁。
可读性很重要。在这方面，RxJava 和协程的方法有很大不同。协程比 RxJava 更简单。如果您不放心map() , flatmap()和函数式响应式(Reactive)编程一般来说，协程操作更容易，涉及基础指令:for , if , try/catch ...但我个人发现协程的代码对于非平凡的任务更难理解。特别是它涉及更多的嵌套和缩进，而 RxJava 中的操作符链使一切保持一致。函数式编程使处理更加明确。最重要的是，RxJava 可以使用其丰富的(好吧，太丰富了)运算符集中的一些标准运算符来解决复杂的转换。当您拥有需要大量组合和转换的复杂数据流时，RxJava 会大放异彩。
我希望这些注意事项将帮助您根据需要选择正确的工具。
编辑:协程现在有了流，一个非常非常类似于 Rx 的 API。人们可以比较每一种的利弊，但事实是差异很小。
协程的核心是一种并发设计模式，带有附加库，其中一个是类似于 Rx 的流 API。显然，Coroutines 的范围比 Rx 广泛得多，有很多 Coroutines 可以做而 Rx 不能做的事情，我无法一一列举。但通常如果我在我的一个项目中使用协程，它归结为一个原因:
协程更擅长从代码中删除回调
我避免使用回调会损害可读性太多。协程使异步代码简单易写。通过利用 suspend 关键字，您的代码看起来像同步代码。
我在项目中看到 Rx 主要用于替换回调的相同目的，但是如果您不打算修改您的架构以提交响应式模式，Rx 将是一个负担。考虑这个接口(interface):

interface Foo {
   fun bar(callback: Callback)
}

协程等价物更明确，返回类型和关键字 suspend 指示它是异步操作。

interface Foo {
   suspend fun bar: Result
}

但是 Rx 等价物有一个问题:

interface Foo {
   fun bar: Single<Result>
}

当您在回调或协程版本中调用 bar() 时，您会触发计算；使用 Rx 版本，您可以获得可以随意触发的计算的表示。您需要调用 bar() 然后订阅 Single。通常没什么大不了的，但是对于初学者来说有点困惑，并且可能会导致微妙的问题。
此类问题的一个示例，假设回调 bar 函数是这样实现的:

fun bar(callback: Callback) {
   setCallback(callback)
   refreshData()
}

如果您没有正确移植它，您将以只能触发一次的 Single 结束，因为 refreshData() 是在 bar() 函数中调用的，而不是在订阅时调用。这是一个初学者的错误，当然，但事实是 Rx 不仅仅是回调替代品，而且许多开发人员都在努力掌握 Rx。
如果您的目标是将异步任务从回调转换为更好的范式，协程是完美的选择，而 Rx 会增加一些复杂性。

https://stackoverflow.com/questions/42066066/