我相信已經確定我的預感是正確的。
我跑了一些簡單的測試,如:
long start = SystemClock.uptimeMillis();
Log.d("blah", "start");
while (SystemClock.uptimeMillis() < start + 10000)
{
// do some work-intensive stuff here
}
Log.d("blah", "finish");
...不管是什麼我在其間10秒做(代碼迴路內部和/或有意使用我的電腦做其他的東西加載CPU),線程始終在開始10秒後報告回來(+ 10ms,我假設的開銷),通過LogCat時間戳和秒錶來判斷,這表明加載的主機CPU不會擴大時間感在模擬器中,正如所料。
要改變這種行爲,我相信,我想傳遞一個選項QEMU層:
$ emulator -avd my_avd -qemu -clock vm
但是,這實際上可能只是有啓動VM(如果設置的時間做這QEMU明顯確實獨立於管理currentTimeMillis(),uptimeMillis()和nanoTime())的結果。不確定(QEMU的文檔相當粗糙。)無論如何,Android QEMU似乎缺乏「虛擬」時鐘,所以上述不起作用。注:
$ emulator -avd my_avd -qemu -clock ?
Available alarm timers, in order of precedence:
unix
但至少我收集了足夠的證據,懷疑我的小理論是正確的。 :-)我沒有看到模擬的應用程序如何播放音頻或執行UI轉換效果等沒有鏈接到真正的時鐘,所以它是有道理的。但是可以選擇模擬時鐘。
您是否嘗試過使用System.nanoTime? – 2011-04-25 02:23:32
謝謝詹姆斯。剛剛嘗試過,結果相同。我有一些答案(?)我要在下面發佈... – lacinato 2011-04-26 07:00:32