我看到这个例子,想知道是否有使用协程的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
}
编辑:澄清一下,协程中的delay
可以替换为Android Handler中的postDelayed
。不同之处在于,协程将在挂起时执行延迟,而Android Handler将通过将消息存储到线程的消息队列中以便稍后执行延迟。表面上看效果相同,区别在于延迟的执行方式。是否有客观原因说明一个优于另一个?
编辑2:事实证明,在幕后,协程调度程序将使用类似于Android Handler的东西。有关更多详细信息,请参见此处。这意味着引入协程来进行简单延迟是不值得的。
Dispatchers.Main
,它有一个基于Handler和Android特定内容的特殊Android实现。 - niquecoDispatchers.Main
的源代码 - 它是 kotlinx.coroutines 包的一部分。没有 Android 特定的实现。 - IgorGanapolsky