Question

我正在开发一个运行实时线程的应用程序。

我的电脑很慢，仿真器运行速度非常慢。当我测试我的应用程序时，好像SystemClock.uptimeMillis()调用正在从实际计算机时钟返回实时值，这意味着即使模拟器是模拟器中的时间也不是很慢。

这种预感是否正确？仿真器时钟与真实的计算机系统时钟相关联（而不是自身模拟并且受到基于主机CPU负载的波动）？似乎是一个显而易见的问题，但我无法在互联网上找到它。

如果是这样的话会有意义。我需要确定，因为我需要知道我的线程是否无法跟上只是模拟器缓慢的症状，或者我是否真的需要重新设计。（无法在真实的手机上进行测试，因为我还没有。）

Answer 1

我相信已经确定我的预感是正确的。

我进行了一些简单的测试，例如：

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似乎缺少“vm”时钟，因此上述功能不起作用。注意：

$ emulator -avd my_avd -qemu -clock ?
Available alarm timers, in order of precedence:
unix

但至少我收集到足够的证据来怀疑我的小理论是正确的。 :-)我没有看到模拟的应用程序如何播放音频或执行UI过渡效果等没有链接到真正的时钟，所以它是有道理的。但是可以选择模拟时钟。

仿真器时钟是否与实际系统时钟同步？

1 个答案: