一、聲明:
public final class SystemClock extends Object 是一個不可變類。
二、結構:
| java.lang.Object |
| ? |
android.os.SystemClock |
三、概述: 它是一個核心的技術裝置。三種不同的時鐘是可用的,他們不應該混淆:
1、System.currentTimeMillis()是一個標準的“牆”時鐘(時間和日期),表示從紀元到現在的毫秒數。該牆時鐘能夠被使用者或電話網路(見setCurrentTimeMillis(long))設定,所以該時間可能會向前或向後不可預知地跳越。該時鐘應該僅僅被使用在當現實世界的對應的日期和時間是重要的情況,例如一個日曆或鬧鐘應用程式。而間隔時間和經過時間應該使用不同的時鐘。如果你使用System.currentTimeMillis(),可以考慮監聽ACTION為ACTION_TIME_TICK、ACTION_TIME_CHANGED、ACTION_TIMEZONE_CHANGED的廣播去監聽時間變化。
2、uptimeMillis()表示自系統啟動時開始計數,以毫秒為單位。返回的是從系統啟動到現在這個過程中的處於非休眠期的時間。當系統進入深度睡眠時(CPU關閉,裝置變黑,等待外部輸入裝置)該時鐘會停止。但是該時鐘不會被時鐘調整,閑置或其他節能機所影響。這是大多數間隔時間的基本點,例如Thread.sleep(millls)、Object.wait(millis)和System.nanoTime()。該時鐘被保證是單調的,適用於檢測不包含休眠的間隔時間的情況。大多數的方法接受一個時間戳記的值除了uptimeMillis()時鐘。
3、elapsedRealtime() andelapsedRealtimeNanos() 返回系統啟動到現在的時間,包含裝置深度休眠的時間。該時鐘被保證是單調的,即使CPU在省電模式下,該時間也會繼續計時。該時鐘可以被使用在當測量時間間隔可能跨越系統睡眠的時間段。
有幾種機制控制事件發生的時間:
1、標準的方法像Thread.sleep(millis) 和Object.wait(millis)總是可用的,這些方法使用的是uptimeMillis()時鐘,如果裝置進入深度休眠,剩餘的時間將被延遲直到系統喚醒。這些同步方法可能被Thread.interrupt()中斷,並且你必須處理InterruptedException異常。
2、SystemClock.sleep(millis)是一個類似於Thread.sleep(millis)的實用方法,但是它忽略InterruptedException異常。使用該函數產生的延遲如果你不使用Thread.interrupt(),因為它會儲存線程的中斷狀態。
3、Handler可以在一個相對或者絕對的時間設定非同步回調,Handler類對象也使用uptimeMillis()時鐘,而且需要一個loop(經常出現在GUI程式中)。
4、AlarmManager可以觸發一次或重複事件,即使裝置深度休眠或者應用程式沒有運行。事件可以選擇用currentTimeMillis或者elapsedRealtime()(ELAPSED_REALTIME)來設定時間,當事件發生會觸發一個廣播。
四、方法:
1、public static long currentThreadTimeMillis() 返在當前線程啟動並執行毫秒數。
2、public static long elapsedRealtime() 返回系統啟動到現在的毫秒數,包含休眠時間。
3、public static long elapsedRealtimeNanos() 返回系統啟動到現在的納秒數,包含休眠時間。
4、public static boolean setCurrentTimeMillis(long millis) 設定當前的"牆"時間,要求調用進程有許可許可權。返回是否成功。
5、public static void sleep(long ms) 等待給定的時間。和Thread.sleep(millis)類似,但是它不會拋出InterruptedException異常。事件被延遲到下一個中斷操作。該方法直到指定的時間過去才返回。
6、public static long uptimeMillis() 返回系統啟動到現在的毫秒數,不包含休眠時間。就是說統計系統啟動到現在的非休眠期時間。