1

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

我的电脑很慢，模拟器在上面运行很慢。当我测试我的应用程序时，似乎SystemClock.uptimeMillis()调用正在从实际的计算机时钟返回实时值，这意味着即使模拟器运行，模拟器中的时间也不会运行缓慢。

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

如果是这样的话，那将是有道理的。我需要确定，因为我需要知道我的线程无法跟上速度只是模拟器速度慢的症状，还是我真的需要重新设计东西。（无法在真机上测试，因为我还没有）。

4

1 回答 1

2

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

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

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 秒准确地报告回来（+10 毫秒，开销我假设），从 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 过渡效果等，所以这是有道理的。但是如果可以选择模拟时钟就好了。

于 2011-04-26T07:11:32.457 回答