2011-08-12 193 views
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找出訂單?

任何想法調試這將非常感激。

回答

5

這是行不通的。你還沒有給出任何代碼來幫助弄清楚你做錯了什麼,但是你做錯了一些事情:從錯誤的處理程序中移除,傳遞錯誤的可運行的東西。

+0

我所需要的只是一個起點。您只提供了兩個:(1)從錯誤的處理程序中移除,(2)傳遞錯誤的可運行的。我會盡力自己調試。如果我沒有成功,我會發布實際的代碼。 Thanks + 1. – ef2011

+0

不要實際的十六進制引用表明我正在從同一個處理程序中移除並傳遞正確的runnable? – ef2011

+0

發現並解決了問題。事實證明,日誌中的'cancelTimeout()'是由'setTimeout()'調用的(爲了確保先前的超時被取消),所以沒有任何cancelTimeout()真的被調用過。 0.01秒的差異和精確的2秒超時後應該提供給我一個暗示,但你知道如何調試去... :) – ef2011

相關問題