How could SystemClock.uptimeMillis() ever wrap?

非 Y 不嫁゛ 提交于 2019-12-22 05:42:11

问题


The Android docs on uptimeMillis() says:

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

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?


[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...]


回答1:


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.



来源:https://stackoverflow.com/questions/13548585/how-could-systemclock-uptimemillis-ever-wrap

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!