前言
從剛開始做Android開始，就時刻謹記一條規則：如果有能實現功能的Android API，就不要用Java API。所以我很少用Timer，直到前一陣一個朋友問我：
我有一個Timer計時器，我看logcat已經啟動了，為什么沒執行呢，跟修改了時鐘有關系嗎？
當時簡單的看了一下源碼，發現Timer確實和時鐘有關系，讓他修改成Handler，昨天又想起來這個問題覺得應該好好整理一下。
正文
首先寫一個Demo：
// 點擊啟動Timer計時器
findViewById(R.id.start_timer).setOnClickListener(v -> startTimer());
// 點擊啟動Handler延時任務
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任務，所以延遲10s，在10s內修改模擬器時鐘，看看驗證的結果。
第一步：Handler delay中修改時鐘快1個小時：
第二步：Handler delay中修改時鐘慢一個小時：
第三步：Timer delay中修改時鐘快一個小時：
第四步：Timer delay中修改時鐘慢一個小時：
從測試的情況看，修改時鐘對于Handler實現的delay無影響，對于Timer實現的delay如果是把時鐘調慢，Timer不會按時執行。
Handler delay的實現
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方法內部的實現，最終使用的是SystemClock.uptimeMillis()，從該方法的注釋可以看出這個方法返回的是開機時間（不包含深度休眠的時間），所以修改了時鐘對于Handler無影響。
Timer的delay實現
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()，這個方法返回的是當前時間戳，所以修改了時鐘，必然會執行的效果有影響，所以還得看一下具體的Task執行的源碼：
private void mainLoop() {
while (true) {
try {
TimerTask task;
boolean taskFired;
synchronized(queue) {
...
task = queue.getMin();
synchronized(task.lock) {
...
// 當前時間戳
currentTime = System.currentTimeMillis();
// task執行的時間戳，就是剛剛調用schedule算出的： System.currentTimeMillis()+delay
executionTime = task.nextExecutionTime;
// task執行時間小于等于當前時間戳，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執行時間未到，需要wait對應的時間差
if (!taskFired) // Task hasn't yet fired; wait
queue.wait(executionTime - currentTime);
}
// 執行task
if (taskFired) // Task fired; run it, holding no locks
task.run();
...
}
}
為了方便理解，這里刪除了部分與分析無關的代碼，簡單的說Timer內部有一個死循環，不停的取隊列中時間最小的任務，然后對比當前時間是否已經大于了task的執行時間，如果已經大于會執行task，否則等待要執行的時間差。
所以當時鐘調快一個消失，時間戳必然大于task的執行時間，所以task可以正常執行，但是當調慢了以后，當前時間戳會小于task的執行時間，相當于delay的時間被延長了時鐘變慢的時間。例如：在delay期間，修改時鐘慢一分鐘，那么task就會在一分鐘后執行，下面是logcat截圖：
總結
從實現上對比，其實Handler和Timer的實現是類似的：隊列 + 任務 + 處理器。在性能上可能不會太大的差別。Handler的實現更適合做延時任務，Time更適合做定時器，例如服務端的定時任務，例如每天晚上的0點備份數據，節假日開啟某個配置等等。
最后總結一句話：在Android開發，Timer幾乎所有的使用場景都有對應的Android API可以替換，所以非特殊情況，還是別用比較好。
