android.os.SystemClock

SystemClock里面有许多关于时间的方法，记录：

SystemClock.uptimeMillis、SystemClock.elapsedRealtime()两个方法为主

uptimeMillis()记录的是从开机到现在的毫秒数（手机睡眠、待机、息屏等时间不包括在内），但是该事件不可以被时钟调整，或其他节能机制影响。 这是基本的对于大多数时间间隔例如Thread.sleep(millls)，Object.wait(millis)，和 System.nanoTime()。该时钟被保证是单调的，并且是为通用的用户界面事件，性能测量，和其他任何不需要在器件测量经过睡眠时间间隔时间的建议的基础。大多数的方法接受一个时间戳的值除了uptimeMillis()时钟；

elapsedRealtime()以毫秒为单位进行计数自动系统启动,包含深度睡眠、即包括睡眠待机等时间。该时钟应该被使用当测量时间间隔可能跨越系统睡眠的时间段。

其中Java语言中有个System.currentTimeMillis()，他表示的是 从1970年1月1日 UTC到现在的毫秒数，但是可以通过System.setCurrentTimeMillis修改的，那么，在某些情况下，一但被修改，时间间隔就不准了。因此在android有些需要使用到时间间隔的方法里面都是不建议使用Java里面的这个函数，而转用SystemClock.uptimeMillis；

因此Android里面基于时间间隔的函数、操作等建议使用SystemClock.uptimeMillis()，以保证不被其他机制影响，如Android的AlarmManager等需要時間間隔後出發或重複出發某一程序的地方。

SystemClock里面有一个工具性函数SystemClock.sleep(millis) ，其功能类似Thread.sleep(millis)，但是它忽视了原有的InterruptedException异常。使用该函数产生的延迟如果你不使用Thread.interrupt()，因为它会保存线程的中断状态。