前言
從剛開始做Android開始，就時刻謹記一條規(guī)則：如果有能實現(xiàn)功能的Android API，就不要用Java API。所以我很少用Timer，直到前一陣一個朋友問我：
我有一個Timer計時器，我看logcat已經(jīng)啟動了，為什么沒執(zhí)行呢，跟修改了時鐘有關(guān)系嗎？
當(dāng)時簡單的看了一下源碼，發(fā)現(xiàn)Timer確實和時鐘有關(guān)系，讓他修改成Handler，昨天又想起來這個問題覺得應(yīng)該好好整理一下。
正文
首先寫一個Demo：
// 點擊啟動Timer計時器
findViewById(R.id.start_timer).setOnClickListener(v -> startTimer());
// 點擊啟動Handler延時任務(wù)
findViewById(R.id.start_handler_delay).setOnClickListener(v -> startHandlerDelay());
/**
* 10s后，修改TextView顯示Handler delay成功
*/
private void startHandlerDelay() {
Log.e("lzp", "start handler delay");
mHandler.postDelayed(() -> {
mTextView.setText("start handler delay successfully");
Log.e("lzp", "start handler delay successfully");
}, 10 * 1000);
}
/**
* 10后，修改TextView顯示Timer delay成功
*/
private void startTimer() {
Log.e("lzp", "start timer");
Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
mTextView.setText("start timer successfully");
Log.e("lzp", "start timer successfully");
}
}, 10 * 1000);
}
為了驗證修改時鐘是否會影響delay任務(wù)，所以延遲10s，在10s內(nèi)修改模擬器時鐘，看看驗證的結(jié)果。
第一步：Handler delay中修改時鐘快1個小時：
第二步：Handler delay中修改時鐘慢一個小時：
第三步：Timer delay中修改時鐘快一個小時：
第四步：Timer delay中修改時鐘慢一個小時：
從測試的情況看，修改時鐘對于Handler實現(xiàn)的delay無影響，對于Timer實現(xiàn)的delay如果是把時鐘調(diào)慢，Timer不會按時執(zhí)行。
Handler delay的實現(xiàn)
public final boolean postDelayed(@NonNull Runnable r, long delayMillis) {
return sendMessageDelayed(getPostMessage(r), delayMillis);
}
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
/**
* Returns milliseconds since boot, not counting time spent in deep sleep.
*
* @return milliseconds of non-sleep uptime since boot.
*/
@CriticalNative
native public static long uptimeMillis();
上面postDelayed方法內(nèi)部的實現(xiàn)，最終使用的是SystemClock.uptimeMillis()，從該方法的注釋可以看出這個方法返回的是開機時間（不包含深度休眠的時間），所以修改了時鐘對于Handler無影響。
Timer的delay實現(xiàn)
public void schedule(TimerTask task, long delay) {
if (delay < 0)
throw new IllegalArgumentException("Negative delay.");
sched(task, System.currentTimeMillis()+delay, 0);
}
Timer的schedule使用的是System.currentTimeMillis()，這個方法返回的是當(dāng)前時間戳，所以修改了時鐘，必然會執(zhí)行的效果有影響，所以還得看一下具體的Task執(zhí)行的源碼：
private void mainLoop() {
while (true) {
try {
TimerTask task;
boolean taskFired;
synchronized(queue) {
...
task = queue.getMin();
synchronized(task.lock) {
...
// 當(dāng)前時間戳
currentTime = System.currentTimeMillis();
// task執(zhí)行的時間戳，就是剛剛調(diào)用schedule算出的： System.currentTimeMillis()+delay
executionTime = task.nextExecutionTime;
// task執(zhí)行時間小于等于當(dāng)前時間戳，taskFired為true
if (taskFired = (executionTime<=currentTime)) {
if (task.period == 0) { // Non-repeating, remove
queue.removeMin();
task.state = TimerTask.EXECUTED;
} else { // Repeating task, reschedule
queue.rescheduleMin(
task.period<0 ? currentTime - task.period
: executionTime + task.period);
}
}
}
// taskFired為false，表示task執(zhí)行時間未到，需要wait對應(yīng)的時間差
if (!taskFired) // Task hasn't yet fired; wait
queue.wait(executionTime - currentTime);
}
// 執(zhí)行task
if (taskFired) // Task fired; run it, holding no locks
task.run();
...
}
}
為了方便理解，這里刪除了部分與分析無關(guān)的代碼，簡單的說Timer內(nèi)部有一個死循環(huán)，不停的取隊列中時間最小的任務(wù)，然后對比當(dāng)前時間是否已經(jīng)大于了task的執(zhí)行時間，如果已經(jīng)大于會執(zhí)行task，否則等待要執(zhí)行的時間差。
所以當(dāng)時鐘調(diào)快一個消失，時間戳必然大于task的執(zhí)行時間，所以task可以正常執(zhí)行，但是當(dāng)調(diào)慢了以后，當(dāng)前時間戳?xí)∮趖ask的執(zhí)行時間，相當(dāng)于delay的時間被延長了時鐘變慢的時間。例如：在delay期間，修改時鐘慢一分鐘，那么task就會在一分鐘后執(zhí)行，下面是logcat截圖：
總結(jié)
從實現(xiàn)上對比，其實Handler和Timer的實現(xiàn)是類似的：隊列 + 任務(wù) + 處理器。在性能上可能不會太大的差別。Handler的實現(xiàn)更適合做延時任務(wù)，Time更適合做定時器，例如服務(wù)端的定時任務(wù)，例如每天晚上的0點備份數(shù)據(jù)，節(jié)假日開啟某個配置等等。
最后總結(jié)一句話：在Android開發(fā)，Timer幾乎所有的使用場景都有對應(yīng)的Android API可以替換，所以非特殊情況，還是別用比較好。
