Android开发常见问题：为什么不要用Timer？

前言

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