SystemClock.uptimeMillis（）如何包装？ [英] How could SystemClock.uptimeMillis() ever wrap?
问题描述
从启动后返回毫秒，不计算在深度睡眠中花费的时间。 注意：此值可能会偶尔复位（否则将会绕过）。
Returns milliseconds since boot, not counting time spent in deep sleep. Note: This value may get reset occasionally (before it would otherwise wrap around).
奇怪的是，文档很担心它绕过。毕竟，该方法返回一个很长的。一个快速的计算可以看出，它需要大约292,271,023年才能包装!!!
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（）也是一个很长的代表时代的时代。然而，Android绝对没有提到价值包装的可能性。更重要的是，对于从0开始的uptimeMillis ...]
[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...]
推荐答案
这主要是猜想，但似乎有意义在我发现的文档上。如果我们考虑到 native public long long uptimeMillis（） in SystemClock 是一种本机方法，运行在32位空格，然后当您调用它时，它只是被转换为Java long ，那么这是有道理的，因为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屋！
