API ドキュメントによると、以前のSO スレッドと同様SystemClock.elapsedRealtime()に、デバイスがスリープ状態であっても正確な時間を維持することになっています。これは私が観察するものではありません。
while (true)の値に基づいてループし、画面上の時間を更新する単純な時計を作成しましたSystemClock.elapsedRealtime()。NTP などを使用して 2 つのデバイスの時計を同期させ、いずれかのデバイスで画面のオンとオフを数回切り替えると、表示される時間が最大 +/- 0.7 秒ずれます。(これは、電話が外部電源に接続されていない場合にのみ発生するため、スリープ モードが原因である可能性があります)。
これは正常ですか？これは Android のバグですか？スリープ/ウェイク サイクルで最大 20 ミリ秒のタイミング精度を維持する方法はありますか?
サーバーと毎分 1 回通信するアプリケーションがあります。起動時にサーバー時間と SystemClock.elapsedRealtime() を記録し、elapsedRealtime を使用してサーバー時間を計算することで、デバイス クロックとサーバー クロックを同期します (これを行うのは、デバイス自体がネットワークから時間を同期し、#### できないためです)。絶対に信用してください）。
Galaxy Tab 2 で実行された 1 週間の間に、SystemClock.elapsedRealtime() はサーバー クロックからわずか2 時間未満で数分遅れました。私のログによると、ドリフトのペースは一定ではないため、デバイスの使用方法が影響します。
API は単調な時間を提供するためにクロックを必要としますが、精度は保証されません。そのため、長時間にわたって正確に時間を記録するのに役立つ方法ではありません。
私は同じ問題を抱えていたので、今夜、タイミング方法を からSystemClock.elapsedRealtime()に変更してみましたSystem.currentTimeMillis()。ここまでは順調ですね。アプリをクリックして戻っても、時間がずれることはありません。
Runnable in a service でテストしました。現在、メイン アクティビティで Runnable を使用してテストしており、sharedprefs を使用して、アプリがフォーカスを失ったときにすべてを保存しています。これら 2 つの方法のどちらが最適かはまだ判断していませんがcurrentTimeMillis、ドリフト時間の問題はないようelapsedRealtimeです。
Google がタイミングの目的で使用することをお勧めしていないことは知っていcurrentTimeMillisますが、アプリがフォーカスを失ったときに正確な時間を維持するのに適しているようです。