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 に答える