0 
SystemClock.uptimeMillis()

Android SystemClockからのこの呼び出しは、「MaxesOut」の前にゼロにリセットされます。

現在、これを使用してアニメーションをベースにしています。以下の動きなどは、リセットによってアプリケーションが本質的にフリーズする例です。

if (currentTime > frameTime + sequenceTime)
{
    frameTime = currentTime;
}

ここに問題currentTimeがあります50と言うと、50にframeTime設定されていますか？理想的にcurrentTimeは増加しますSystemClock.uptimeMillis()が、リセットされた場合はどうなりますか？currentTimeは、これを修正する方法や、すべてのオブジェクトをframeTimeリセットする方法に比べて非常に小さくなります。currentTime

これは、同様のジレンマを持つさまざまなオブジェクトがある場合のほんの小さな例です。

4

1 に答える 1

0

ドキュメントを読んだところ、「稼働時間」クロックはデバイスが再起動されたときにのみリセットされます。アプリケーションが...どういうわけか...再起動しても実行し続けることができない限り、クロックのリセットについて心配する必要はありません。

（一方、アプリケーションが再起動後も継続するアニメーションを実行する必要がある場合は、「currentTimeMillis」クロックを使用する必要があります。AndroidのドキュメントにSystemClock代替案が記載されています。）

ドキュメントには、「注：この値はときどきリセットされる可能性があります（そうでない場合はラップアラウンドする前に）」と記載されています。。

これは私にはあまり意味がありません。クロックはミリ秒のクロックであり、長いものとして返されるため、ラップアラウンドすることは期待できません。（2 ^ 64ミリ秒は非常に長い時間です。）私が考えることができる唯一の説明は、一部のデバイスがこのクロックを実装するために32ビットのハードウェアタイマーを使用しているということです...

于 2012-08-07T01:39:03.833 に答える