Android postDelayed vs Coroutines 延迟答案

【问题标题】：Android postDelayed vs Coroutines delayAndroid postDelayed vs Coroutines 延迟
【发布时间】：2019-09-24 09:08:46
【问题描述】：

我看到了this 的例子，我想知道是否有任何客观的理由来使用 Coroutines delay 而不是 Android Handler postDelayed 来实现这个？

如果链接失效，示例代码如下：

val watcher = object :TextWatcher{
    private var searchFor = ""

    override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
        val searchText = s.toString().trim()
        if (searchText == searchFor)
            return

        searchFor = searchText

        launch {       
            delay(300)  //debounce timeOut
            if (searchText != searchFor)
                return@launch

            // do our magic here
        }
    }

    override fun afterTextChanged(s: Editable?) = Unit
    override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) = Unit
}

编辑：澄清一下，来自 Coroutines 的 delay 可以替换为来自 Android Handler postDelayed 的延迟。不同的是，Coroutines 将执行延迟被挂起，而 Android Handler 将通过将消息存储到稍后执行的线程的消息队列中来执行延迟。看起来效果是一样的，区别在于延迟的执行方式。是否有任何客观原因表明其中一个会更好？

EDIT2：事实证明，在底层协程调度程序将使用类似于 Android 处理程序的东西。有关详细信息，请参阅this。这意味着为简单的延迟引入协程是不值得的。

【问题讨论】：

标签： android kotlin android-handler kotlin-coroutines

【解决方案1】：

是的，在某些情况下更喜欢delay 是有客观原因的。如果您需要在延迟之前携带变量形式，或者将其放入循环中，使用延迟将为您提供更清晰的代码。但是，在这种特殊情况下，它并没有增加太多，因为您在立即启动协程后会延迟，当然。但它也不会有任何缺点，因此如果您认为这样代码看起来更干净，您可能更愿意这样做。

所有协程的东西都是根据标准框架的东西来实现的。在引擎盖下，它将始终是 Handler 和其他您可以直接使用的东西。

【讨论】：