1
考慮下面的logcat的痕跡,這表明Handler.removeCallbacks()
被稱爲(通過MyListener.cancelTimeout()
)明確前myTask.run()
:Handler.removeCallbacks()不會刪除回調 - 爲什麼?
08-12 17:29:13.990: VERBOSE/MyListener.setTimeout(2625): TID: 2625, Handler{460a86e8}, [email protected]
08-12 17:29:14.000: VERBOSE/MyListener.cancelTimeout(2625): TID: 2625, Handler{460a86e8}, [email protected]
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}, [email protected]
08-12 17:29:16.010: VERBOSE/MyListener.handleTimeout(2625): TID: 2625
怎麼可能解釋這個謎?
注日誌中的精確時間戳:相同的確切Runnable對象(myTask @ 461cc378)正在被removeCallbacks() - 編恰好0.01秒後它已經postDelayed()。然後,2.01秒後,運行它()...
怎麼可能解釋一下嗎?
例如,爲0.01秒太短的Android找出訂單?
任何想法調試這將非常感激。
我所需要的只是一個起點。您只提供了兩個:(1)從錯誤的處理程序中移除,(2)傳遞錯誤的可運行的。我會盡力自己調試。如果我沒有成功,我會發布實際的代碼。 Thanks + 1. – ef2011
不要實際的十六進制引用表明我正在從同一個處理程序中移除並傳遞正確的runnable? – ef2011
發現並解決了問題。事實證明,日誌中的'cancelTimeout()'是由'setTimeout()'調用的(爲了確保先前的超時被取消),所以沒有任何cancelTimeout()真的被調用過。 0.01秒的差異和精確的2秒超時後應該提供給我一個暗示,但你知道如何調試去... :) – ef2011