一 概述:
Android 开发中经常会遇到计算时间间隔的场景,Android 系统中提供了几种计算时间的方法:System.currentTimeMillis()、SystemClock.uptimeMillis() 和 SystemClock.elapsedRealtime()。
那么他们之间有什么区别呢?使用的时候会遇到什么样的“坑”呢?今天梳理一下。
Android 系统提供了三种不同的可用时钟:
- System.currentTimeMillis()
- SystemClock.uptimeMillis()
- SystemClock.elapsedRealtime()
二 System.currentTimeMillis()
System.currentTimeMillis() 会产生一个标准的自1970年1月1日0时0分0秒到现在的毫秒数。
需要提别注意的是,这个数值会通过 System.setCurrentTimeMillis 来修改的,所以该时间可能会向前或向后不可预知地跳越。比如用户设置调整了系统时间,那么这个数值就会发生变化。
该时钟应该仅仅被使用在当现实世界的对应的日期和时间是重要的情况,例如一个日历或闹钟应用程序。而间隔时间和经过时间应该使用不同的时钟。如果你使用 System.currentTimeMillis(),可以考虑监听 ACTION 为 ACTION_TIME_TICK、 ACTION_TIME_CHANGED、ACTION_TIMEZONE_CHANGED 的广播去监听时间变化。
一句话概括就是:它是系统时间,也就是日期时间,可以被系统设置修改,然后值就会发生跳变。
结合其特点我们可以判断:System.currentTimeMillis() 不适合计算时间间隔。
例如:
now = System.currentTimeMillis()
//do something...
duration = System.currentTimeMillis() -now;
如果在 do something 的时候,改变了系统时间,那么获取 duration 就不准了。通常在比较小的时间里,(毫秒级,秒级)一般不会有什么问题,系统时间可能不会改变。但是如果时间很长的话,那就保证不了了。
三 SystemClock.uptimeMillis()
SystemClock.uptimeMillis() 表示自系统启动时开始计数,以毫秒为单位。
返回的是从系统启动到现在这个过程中的处于非休眠期的时间。当系统进入深度睡眠时(CPU关闭,设备变黑,等待外部输入装置)该时钟会停止。但是该时钟不会被时钟调整,闲置或其他节能机所影响。这是大多数间隔时间的基本点,例如 Thread.sleep(millls)、Object.wait(millis) 和 System.nanoTime()。该时钟被保证是单调的,适用于检测不包含休眠的间隔时间的情况。
一句话概括:它是自开机后,经过的时间,不包括深度睡眠的时间。由于不计算睡眠时间,所以非常适合做一些特殊的时间间隔计算。
四 SystemClock.elapsedRealtime()
SystemClock.elapsedRealtime() 和 elapsedRealtimeNanos() 返回系统启动到现在的时间,包含设备深度休眠的时间。
该时钟被保证是单调的,即使 CPU 在省电模式下,该时间也会继续计时。该时钟可以被使用在当测量时间间隔可能跨越系统睡眠的时间段。
一句话概括就是:它们是自开机后,经过的时间,包括深度睡眠的时间。适用于任何情况下的时间间隔计算。