Spi*_*dey 15 android kotlin android-handler kotlin-coroutines
我看到这个例子,我想知道是否有任何客观原因使用 Coroutinesdelay而不是 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
}
Run Code Online (Sandbox Code Playgroud)
编辑:为了澄清,delay来自 Coroutines 可以替换为来自 Android Handler 的延迟postDelayed。不同之处在于,Coroutines 会执行挂起的延迟,而 Android Handler 会通过将消息存储到稍后要执行的线程的消息队列中来执行延迟。看起来效果是一样的,区别在于延迟的执行方式。是否存在任何客观原因可以说明其中一个或另一个会更好?
EDIT2:事实证明,在幕后,协程调度程序将使用类似 Android 处理程序的东西。请参阅此了解更多详细信息。这意味着为了简单的延迟而引入协程是不值得的。
是的,在某些情况下有客观的理由选择delay。如果您需要在延迟之前携带变量,或者将其放入循环中,那么使用延迟将为您提供更清晰的代码。然而,在这种特殊情况下,它并没有增加太多,因为当然,你在立即启动协程后会延迟。但它也不会有任何缺点,所以如果您认为这样代码看起来更干净,您可能更愿意这样做。
所有协程的东西都是根据标准框架的东西来实现的。在幕后,它始终是 Handler 和其他您可以直接使用的东西。
| 归档时间: |
|
| 查看次数: |
11576 次 |
| 最近记录: |