自定义MoreAccurateCountDownTimer的onTick()仅触发一次问题求助

嗨，我之前在自定义CountDownTimer扩展暂停、精度优化功能的时候，也碰到过一模一样的问题！onTick只触发一次就没动静了，大概率是你的计时循环逻辑或者剩余时间计算出了问题，我整理几个最常见的坑和修复方案，你可以对照着排查：

1. 核心问题：Handler没有持续发送下一次计时消息 #

原生CountDownTimer的核心逻辑是每次onTick后，Handler会判断剩余时间，然后发送下一个延迟消息。如果你的自定义实现里，在handleMessage方法中处理完第一次onTick后，没有继续发送下一个消息，那自然只会触发一次回调。

修复示例： #

检查你的Handler实现，确保处理完onTick后，只要剩余时间大于0，就继续发送延迟消息：

private static final int MSG = 1;
private Handler mHandler = new Handler(Looper.getMainLooper()) {
    @Override
    public void handleMessage(Message msg) {
        synchronized (MoreAccurateCountDownTimer.this) {
            if (mIsPaused) {
                // 暂停时记录剩余时间，终止本次消息循环
                mRemainingMillis = mMillisInFuture - (SystemClock.elapsedRealtime() - mStartTime);
                return;
            }

            long now = SystemClock.elapsedRealtime();
            // 计算到下一次tick的延迟时间，保证精度（避免累计误差）
            long delay = mInterval - (now - mStartTime) % mInterval;
            long nextTickTime = now + delay;
            long remaining = mMillisInFuture - (nextTickTime - mStartTime);

            if (remaining <= 0) {
                // 倒计时结束，触发onFinish
                onFinish();
            } else {
                // 触发onTick，并发送下一次计时消息
                onTick(remaining);
                sendMessageDelayed(obtainMessage(MSG), delay);
            }
        }
    }
};

2. 剩余时间计算错误，提前触发onFinish #

如果你的剩余时间计算逻辑出错，比如误用了System.currentTimeMillis()（会受系统时间修改影响），或者计算时出现负数/零，就会导致第一次onTick后直接走到onFinish，不再触发后续回调。

正确的计算方式： #

一定要用SystemClock.elapsedRealtime()来计算已流逝的时间，它是从系统启动开始的毫秒数，不受用户修改系统时间的影响：

// 计算已流逝的时间
long elapsedTime = SystemClock.elapsedRealtime() - mStartTime;
// 剩余时间 = 总时长 - 已流逝时间
long remainingTime = mMillisInFuture - elapsedTime;

3. 暂停/恢复功能的逻辑漏洞 #

如果你加了暂停功能，很可能是暂停或恢复的代码没写对，比如暂停时没有正确保存剩余时间，或者恢复时没有重置开始时间，导致恢复后剩余时间直接为0，只触发一次onTick就结束。

完整的暂停/恢复实现参考： #

private long mRemainingMillis; // 暂停时保存的剩余时间
private boolean mIsPaused = false;
private long mStartTime; // 计时开始的系统时间戳

// 暂停计时
public void pause() {
    synchronized (this) {
        if (mIsPaused) return;
        mIsPaused = true;
        // 保存当前剩余时间
        mRemainingMillis = mMillisInFuture - (SystemClock.elapsedRealtime() - mStartTime);
        // 移除未处理的计时消息
        mHandler.removeMessages(MSG);
    }
}

// 恢复计时
public void resume() {
    synchronized (this) {
        if (!mIsPaused) return;
        mIsPaused = false;
        // 重置开始时间为当前时间
        mStartTime = SystemClock.elapsedRealtime();
        // 更新总时长为暂停时的剩余时间
        mMillisInFuture = mRemainingMillis;
        // 重新发送计时消息
        mHandler.sendMessage(obtainMessage(MSG));
    }
}

4. 额外注意：避免Handler线程问题 #

如果你的CountDownTimer是在子线程初始化的，一定要确保该线程有Looper（主线程默认有Looper，所以如果是UI相关的计时，尽量在主线程创建Handler）。另外，在宿主组件（比如Activity、Fragment）销毁时，记得调用cancel()方法停止计时，避免内存泄漏和消息无法处理：

public void cancel() {
    mHandler.removeMessages(MSG);
    mIsPaused = false;
}

你可以先从检查Handler的消息循环逻辑开始，这是最常见的原因！

内容的提问来源于stack exchange，提问作者IntersectGlasses