【问题标题】:Handler.removeCallbacks() doesn't remove callback - Why?Handler.removeCallbacks() 不删除回调 - 为什么?
【发布时间】:2011-08-12 21:59:25
【问题描述】:

鉴于以下 LogCat 跟踪,这表明 Handler.removeCallbacks()myTask.run() 之前被调用(通过 MyListener.cancelTimeout()明显

08-12 17:29:13.990: VERBOSE/MyListener.setTimeout(2625): TID: 2625, Handler{460a86e8}, myTask@461cc378
08-12 17:29:14.000: VERBOSE/MyListener.cancelTimeout(2625): TID: 2625, Handler{460a86e8}, myTask@461cc378
08-12 17:29:16.010: VERBOSE/myTask.run(2625): TID: 2625, MyTimeoutTask(handleTimeout())
08-12 17:29:16.010: VERBOSE/MyListener.cancelTimeout(2625): TID: 2625, Handler{460a86e8}, myTask@461cc378
08-12 17:29:16.010: VERBOSE/MyListener.handleTimeout(2625): TID: 2625

什么可以解释这个谜团?

请注意日志中的确切时间戳:相同的 Runnable 对象 (myTask@461cc378) 正好在 0.01 秒 延迟后被 removeCallbacks()-ed ()。然后,2.01 秒后,它是 run()...

这有什么可以解释的?

例如,0.01 秒对于 Android 来说是不是太短而无法计算顺序?

非常感谢任何调试此问题的想法。

【问题讨论】:

    标签: java android handler postdelayed


    【解决方案1】:

    这确实有效。您没有提供任何代码来帮助找出您做错了什么,但您做错了:从错误的处理程序中删除,传递错误的可运行文件等。

    【讨论】:

    • 我所需要的只是一个起点。您只提供了两个:(1)从错误的处理程序中删除,(2)传递错误的可运行文件。我会尝试自己调试这个。如果我不成功,我将发布实际代码。谢谢+1。
    • 实际的十六进制引用是否表明我正在从同一个处理程序中删除并传递正确的可运行对象?
    • 发现并解决了问题。事实证明,日志中的cancelTimeout()setTimeout() 调用的那个(以确保取消先前的超时),因此实际上没有调用cancelTimeout()。 0.01 秒的差异和紧随其后的确切 2 秒超时应该为我提供了一个提示,但你知道调试是如何进行的...... :)
    猜你喜欢
    • 1970-01-01
    • 2023-01-15
    • 2013-05-08
    • 1970-01-01
    • 1970-01-01
    • 2020-01-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多