前言
从刚开始做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可以替换，所以非特殊情况，还是别用比较好。
