Android will count down to the extreme.

When developing the countdown function, we often use CountDownTimer directly or use Handler for delay for convenience. Of course, the internal package of CountDownTimer also uses Handler.

It doesn't matter if I only count down a few times or don't need accurate countdown logic. For example, I only need to count down for 1 seconds, or I request an interface in about 5 minutes.

But if I need to do accurate countdown operation, for example, my mobile phone sends a verification code for 6 seconds, there will be problems in using the existing countdown scheme. Some friends may not have noticed this, so let's briefly analyze the existing countdown problem.

this is probably the most used one, because it is convenient. But in fact, there is an error after each countdown. If you have read the source code of CountDownTimer, you will know that it is calibrated internally. (The source code is very simple, so I won't analyze it here.)

But if you have carefully tested CountDownTimer, you will find that even if it is calibrated internally, none of his rounds are biased, but the total time after his last countdown is not biased compared with the time when he started counting down.

What do you mean? It means 1 second, 2.5 seconds, 3.1 seconds ................................................................................................................................................

This is just one of the problems. You can show it by yourself with a plastic accumulation instead of its callback. However, he still has a problem. There is a probability that there will be a jump second directly, that is, for example, 3 seconds, and the next time it will be 5 seconds directly. This is the actual jump second, which is the kind of missing a callback.

if you use it directly, it may cause a big problem. You may not find it when you self-test, and when it is applied to users online, it will probably jump for a second, which will hurt your eggs.

what's wrong with using Handler instead of doing so many fancy things?

Because handler is directly used to realize it without calibration operation, there will be an error of several milliseconds in each cycle, which is better than the error of more than ten milliseconds in CountDownTimer, but the error will accumulate in the case of a large countdown, resulting in an error of several seconds between the final result and the reality. The longer the time, the greater the error.

It is the same to use Timer directly, except that the error in each round is smaller, and the error in several rounds is only one millisecond, but it is still without calibration.

since we can't use the original one directly, let's make one ourselves.

We package based on Handler. From the above, we can see that we mainly solve two problems, namely, time calibration and second skipping. The idea of writing a CountDownTimer

is to get the SystemClock.elapsedRealtime () once before the countdown starts, and get the SystemClock.elapsedRealtime () again without a round of countdown to get the error, and calibrate it according to the delay. Then use while to follow the bad to handle the operation of jumping seconds. Unlike the native CountDownTimer, if you jump for a few seconds, you will return as many callbacks as possible.