在测试我们的游戏时，这严重依赖于System.currentTimeMillis()，我们遇到了一个恼人的错误。
我们的游戏使用一组delta时间戳，指示何时应该发生某些事情。这些时间戳匹配正在播放的一段音乐。
在家测试对我们没有任何问题。在我们家测试时，无法重现这个错误。
但是，在城市之间驾车时进行测试，可以让我们在时间戳和音乐之间找到同步问题。我最好的猜测是Android会冻结系统，包括系统计时器，因为它是在切换网络，还是在寻找信号？
当我按下某个按钮时，我已经尝试在游戏中插入虚假的hick-up，让线程休眠几秒钟。这显然冻结了屏幕，但是当睡眠结束时，一切都仍然正常。
重现这个错误的唯一方法是乘汽车或公共汽车或火车去旅行 - 当然这很可能是大多数人玩游戏的地方。
问题当然是，
该怎么办？
有没有人有任何想法？
答案 0 :(得分：3)
阅读SystemClock。
System.currentTimeMillis（）是标准的“墙”时钟（时间和时间） date）表示自纪元以来的毫秒数。挂钟可以 由用户或电话网络设置（参见setCurrentTimeMillis（long））， 所以时间可能会不可预测地向后或向前跳跃。
自启动系统以来，uptimeMillis（）以毫秒为单位计算。 当系统进入深度睡眠状态时，此时钟停止（CPU关闭，显示 黑暗，设备等待外部输入），但不受时钟影响 缩放，空闲或其他节能机制。这是基础 大多数间隔时间，例如Thread.sleep（millls）， Object.wait（millis）和 System.nanoTime（）。这个时钟是有保证的 要单调，并且适用于间隔时间间隔 并没有跨越设备睡眠。
我认为最好使用System.nanoTime()。