Confirmed users
3,339
edits
Fennec/NativeUI/CodingStyle: Difference between revisions
Jump to navigation
Jump to search
→Timing things: Google recommends using SystemClock.uptimeMillis()
(→Timing things: Google recommends using SystemClock.uptimeMillis()) |
|||
| Line 84: | Line 84: | ||
=== Timing things === | === Timing things === | ||
TLDR: If you're adding stuff for timing, use | TLDR: Google recommends using SystemClock.uptimeMillis() for general purpose interval timing of user interface events or performance measurements. If you're adding stuff for timing, use SystemClock.uptimeMillis(), rather than something like new Date().getTime(). | ||
Normally in Java the default time-getter is System.currentTimeMillis() since it avoids the overhead of creating a new Date object. This is also what new Date() does under the hood. However, currentTimeMillis() and the Date object are both subject to change in unexpected ways if the user changes the time on their device, or if daylight savings comes into effect, or there's a network time update, or whatever. So Android has generously provided android.os.SystemClock which has various functions that you can use to get a better timestamp. Refer to the class javadoc and pick whichever function is most suitable for what you're trying to measure. | Normally in Java the default time-getter is System.currentTimeMillis() since it avoids the overhead of creating a new Date object. This is also what new Date() does under the hood. However, currentTimeMillis() and the Date object are both subject to change in unexpected ways if the user changes the time on their device, or if daylight savings comes into effect, or there's a network time update, or whatever. So Android has generously provided android.os.SystemClock which has various functions that you can use to get a better timestamp. Refer to the class javadoc and pick whichever function is most suitable for what you're trying to measure. | ||
http://developer.android.com/reference/android/os/SystemClock.html | |||