怎么能SystemClock.uptimeMillis（）曾经包裹？ [英] How could SystemClock.uptimeMillis() ever wrap?

问题描述

借助上uptimeMillis Android的文档（）说：

返回毫秒启动以来，不包括在深度睡眠所花费的时间。 注意：这个值可能会偶尔复位（之前，否则将环绕）

Returns milliseconds since boot, not counting time spent in deep sleep. Note: This value may get reset occasionally (before it would otherwise wrap around).

这似乎很奇怪的是，文档是担心它曾经环绕周围。毕竟，该方法返回一个长。快速计算收益率，这将需要大约292271023年它永远包！

It seems quite strange that the docs are worried about it ever wrapping around. After all, the method returns a long. A quick calculation yields that it would take approximately 292,271,023 years for it to ever wrap!!!

所以，这是怎么回事的文档？难道真的可以没有它来包装？该值可以或许把它包达到了很长的最大值过吗？是什么文件实际上是想说什么？如果是这样，当它会包装？

So what's up with the docs? Is it really ever possible for it to wrap? Can the value perhaps wrap before it reaches the max value for a long? Is that what the docs are actually trying to say? And if so, when would it wrap?

[这是特别令人费解的是 System.currentTimeMillis的（） 是也是一个长期的再presents时间，因为一个时代。然而，Android的使得完全没有提及的价值包装的可能性。更何况，对于uptimeMillis它从0开始...]

[It's especially puzzling as System.currentTimeMillis() is also a long that represents time since an epoch. Yet, Android makes absolutely no mention of the possibility of the value wrapping. All the more so, for uptimeMillis which starts at 0...]

推荐答案

这主要是猜想，但似乎基于我发现的文档变得有意义。如果我们考虑到了本地公共静态长uptimeMillis（）在 SystemClock 是一个本地方法，在运行32位空间，然后它只是被转换为一个Java 长当你调用它的话很有道理，因为2 ^ 32毫秒非常容易到达。

This is mainly conjecture but seems to make sense based on the docs I've found. If we take account that native public static long uptimeMillis() in SystemClock is a native method, running in 32-bit space, and then it's simply being cast to a Java long when you call it then it makes sense because 2^32 milliseconds is very easily reachable.

这篇关于怎么能SystemClock.uptimeMillis（）曾经包裹？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！