SystemClock.uptimeMillis()如何包装？

Question

关于uptimeMillis()的Android文档说:

返回自引导以来的毫秒数,不计入深度睡眠所花费的时间.注意:此值可能偶尔会重置(否则会被包围).

似乎很奇怪的是,医生们担心它会缠绕在一起.毕竟,该方法返回一个long.一个快速的计算结果表明它需要大约292,271,023年才能永远包裹!

那么文档怎么了？它真的可以包装吗？值是否可以在达到最大值之前换行？这是文档实际上试图说的吗？如果是这样,它何时会换行？

---

[特别令人费解的是,System.currentTimeMillis()也是一个代表自纪元以来时间的长.然而,Android绝对没有提到价值包装的可能性.更重要的是,对于从0开始的uptimeMillis ...]

Answer 1

这主要是猜想,但基于我发现的文档似乎有意义.如果我们考虑到native public static long uptimeMillis()in SystemClock是一个本机方法,在32位空间中运行,然后它只是long在你调用它时被强制转换为Java ,那么它是有意义的,因为2 ^ 32毫秒很容易到达.