メソッドuptimeMillisの説明は次のとおりです。
深い睡眠に費やされた時間をカウントせずに、起動からのミリ秒を返します。 注:この値は、ときどきリセットされる場合があります(そうでない場合はラップアラウンドする前に)。
これはどのくらいの頻度で発生する可能性があり、(さらに重要なことに)Handler.postAtTimeによって実行されるランナブルに影響しますか?
メソッドuptimeMillisの説明は次のとおりです。
深い睡眠に費やされた時間をカウントせずに、起動からのミリ秒を返します。 注:この値は、ときどきリセットされる場合があります(そうでない場合はラップアラウンドする前に)。
これはどのくらいの頻度で発生する可能性があり、(さらに重要なことに)Handler.postAtTimeによって実行されるランナブルに影響しますか?
ラップしたときにuptimeMillisを呼び出した場合は、そうです。postAtTime呼び出しに影響します。
Javaで署名されたlongの範囲は次のとおりです。
-9,223,372,036,854,775,807 to 9,223,372,036,854,775,807 (~9.2E18)
9.2E18ミリ秒は292、277、266年です。あなたが宇宙探査機に取り組んでいるなら、あなたはおそらくこれを考慮に入れたいと思うでしょう、さもなければあなたはおそらくそれがあなたの生涯でラップしないと仮定することで逃げることができます。
私にとってのキッカーは、uptimeMillisのAndroidドキュメントが主張していることです
この時計は単調であることが保証されています。。。
そして、彼らがuptimeMillisが可変ラッピングのためにリセットされると言った直後に-単調な時計の正反対です!
uptimeMillis呼び出しはsystemTime()で実行され、Linuxシステムではclock_gettime(CLOCK_MONOTONIC、struct timespec *)に変換されます。
struct timespecは、32ビット値のように見えるtime_tに秒を保持します。ゼロ近くでカウントを開始した場合、ラップしたときに生きていない可能性があります。
より具体的な詳細が必要な場合は、Linuxカーネルでのclock_gettime(CLOCK_MONOTONIC)の動作を調査する必要があります。
私はそれをサービスに使用していましたが、リセットされるのを見たことがありませんでした。私は本当にそうではないと思います。の問題postAtTime()
は、スリープ中に呼び出されないことです(uptimeMillis()
更新されないため)。それが問題である場合、私は他の方法を使用します。