4

在测试严重依赖于 的游戏时System.currentTimeMillis()，我们遇到了一个恼人的错误。

我们的游戏使用一组 delta 时间戳来指示某些事情应该何时发生。这些时间戳与正在播放的一段音乐相匹配。

在家测试完全没有问题。在我们家进行测试时，不可能重现该错误。

但是，在汽车中行驶时进行测试，在城市之间进行测试，会给我们带来时间戳和音乐之间的同步问题。我最好的猜测是Android冻结了系统，包括系统计时器，因为它正在切换网络或寻找信号？

我试过在游戏中插入一个假的打嗝，当我按下某个按钮时让线程休眠几秒钟。这会冻结屏幕（显然），但是当睡眠结束时，一切仍然正常同步。

重现此错误的唯一方法是乘汽车、公共汽车或火车旅行——这当然是大多数人在玩我们的游戏时最可能出现的地方。

问题当然是，

  • 该怎么办？

  • 有没有人有任何想法？

4

1 回答 1

3

阅读SystemClock。

System.currentTimeMillis()是标准的“挂钟”（时间和日期），表示自纪元以来的毫秒数。挂钟可以由用户或电话网络设置（参见 setCurrentTimeMillis(long)），因此时间可能会意外地向后或向前跳跃。

uptimeMillis() 以系统启动后的毫秒数计算。此时钟在系统进入深度睡眠（CPU 关闭、显示器变暗、设备等待外部输入）时停止，但不受时钟缩放、空闲或其他省电机制的影响。这是大多数间隔计时的基础，例如 Thread.sleep(millls)、Object.wait(millis) 和System.nanoTime()。这个时钟保证是单调的，适用于区间不跨越设备睡眠的区间计时。

我认为最好使用System.nanoTime()。

于 2013-06-02T16:26:36.160 回答