6

uptimeMillis() に関する Android ドキュメントには次のように書かれています。

ディープ スリープで費やされた時間をカウントせずに、起動からのミリ秒を返します。: この値はときどきリセットされることがあります (それ以外の場合はラップアラウンドする前に)。

ドキュメントがこれまでにラップアラウンドすることを心配しているのは非常に奇妙に思えます. 結局、メソッドは long を返します。簡単に計算すると、ラップするのに約292,271,023年かかることがわかります!!!

それで、ドキュメントはどうなっていますか?ラップすることは本当に可能ですか?長い間、最大値に達する前に値が折り返される可能性はありますか? それはドキュメントが実際に言おうとしていることですか?もしそうなら、いつラップされますか?


[ System.currentTimeMillis()もエポックからの時間を表す long であるため、特に不可解です。しかし、Android は値のラッピングの可能性についてまったく言及していません。0 から始まる uptimeMillis の場合はなおさらです...]

4

1 に答える 1

5

これは主に推測ですが、私が見つけたドキュメントに基づいて理にかなっているようです。native public static long uptimeMillis()inSystemClockが 32 ビット空間で実行されるネイティブ メソッドであり、呼び出し時に単に Java にキャストされることを考慮するとlong、2^32 ミリ秒は非常に簡単に到達できるため、理にかなっています。

于 2012-11-25T05:42:30.023 に答える