前言

从刚开始做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() {@Overridepublic 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()+delayexecutionTime = task.nextExecutionTime;// task执行时间小于等于当前时间戳，taskFired为trueif (taskFired = (executionTime<=currentTime)) {if (task.period == 0) { // Non-repeating, removequeue.removeMin();task.state = TimerTask.EXECUTED;} else { // Repeating task, reschedulequeue.rescheduleMin(task.period<0 ? currentTime   - task.period: executionTime + task.period);}}}// taskFired为false，表示task执行时间未到，需要wait对应的时间差if (!taskFired) // Task hasn't yet fired; waitqueue.wait(executionTime - currentTime);}// 执行taskif (taskFired)  // Task fired; run it, holding no lockstask.run();...}
}

为了方便理解，这里删除了部分与分析无关的代码，简单的说Timer内部有一个死循环，不停的取队列中时间最小的任务，然后对比当前时间是否已经大于了task的执行时间，如果已经大于会执行task，否则等待要执行的时间差。

所以当时钟调快一个消失，时间戳必然大于task的执行时间，所以task可以正常执行，但是当调慢了以后，当前时间戳会小于task的执行时间，相当于delay的时间被延长了时钟变慢的时间。例如：在delay期间，修改时钟慢一分钟，那么task就会在一分钟后执行，下面是logcat截图：

总结

从实现上对比，其实Handler和Timer的实现是类似的：队列 + 任务 + 处理器。在性能上可能不会太大的差别。Handler的实现更适合做延时任务，Time更适合做定时器，例如服务端的定时任务，例如每天晚上的0点备份数据，节假日开启某个配置等等。

最后总结一句话：在Android开发，Timer几乎所有的使用场景都有对应的Android API可以替换，所以非特殊情况，还是别用比较好。