：System.currentTimeMillis() 方法产生一个标准的自1970年1月1号0时0分0秒所差的毫秒数。该时间可以通过调用setCurrentTimeMillis(long)方法来手动设置，也可以通过网络来自动获取.那么，在某些情况下，一但被修改，时间间隔就不准了。System.currentTimeMillis()得到的毫秒数为“1970年1月1号0时0分0秒-----》当前手机系统的时间”的差。因此如果在执行intervalTime(时间间隔)的值期间用户更改了手机系统的时间，那么得到的结果是不可预料的
结论：它不适合用在需要时间间隔的地方，如Thread.sleep, Object.wait等，因为可以通过System.setCurrentTimeMillis来改变它的值。
SystemClock.uptimeMillis()**方法用来计算自开机启动到目前的毫秒数。如果系统进入了深度睡眠状态（CPU停止运行、显示器息屏、等待外部输入设备）该时钟会停止计时，**但是该方法并不会受时钟刻度、时钟闲置时间亦或其它节能机制的影响。因此SystemClock.uptimeMillis()方法也成为了计算间隔的基本依据，比如Thread.sleep()、Object.wait()、System.nanoTime()以及Handler都是用SystemClock.uptimeMillis()方法。这个时钟是保证单调性,适用于计算不跨越设备的时间间隔。目前大多数方法接受一个时间戳值uptimeMillis()的时钟。
结论：SystemClock.uptimeMillis()适用于计算适合用在需要时间间隔的地方。
但是，待机时，系统深度休眠，此时需要计算这之间的电流，上述显然不能满足了。
SystermClock. elapsedRealtime ()自开机后，经过的时间，包括深度睡眠的时间。这里的时间要求不能发生跳变，包括手机深度睡眠的时间，很明显SystermClock. elapsedRealtime ()最合适。
休眠比：
休眠比较低，说明有进程在使用CPU，不断地唤醒CPU、持有CPU锁或者block CPU suspend, 但如果手机的休眠比很高，但平均电流也很高，这就很大可能是CPU休眠之后还有器件未进入低功耗状态，需要从器件方面去分析。
如何计算休眠比，就需要SystermClock. elapsedRealtime - SystemClock.uptimeMillis() 差值在总elapsedRealtime 的比例计算。
