Study on Obsessive-compulsive disorder--mediaplayer playback progress bar Optimization

Study on Obsessive-compulsive disorder--mediaplayer playback progress bar Optimization

How to make a graceful, smooth and accurate playback progress bar, perhaps a lot of people feel very simple, but in fact, the problem is ignored for most of the time.

Comparison of timing methods

• Timing mode--using handler in the main thread

  – This is the simplest way to go through handler.postdealyed (..., 1000) in the main thread and continue the post message in Onhandlemessage, so that a message loop is implemented every 1000ms.

• Timing Method--using a separate timing thread

  – Create a single timed thread that emits a time tick event per second and the main thread updates the progress through the event. This way is more troublesome, but no trouble how to pretend to force it?

  How to achieve elegance and accuracy for the handler way

• Self error

In this way, if you use the handler.postdealyed (..., 1000) way to carry out the timing per second, is inaccurate, yes, there is a great error, the reason for the error is that you receive the message, When you re-send handler.postdealyed time, not instantaneous, there is a lot of logic processing time, even if there is no logic processing time, handler itself is also wear performance, so the message is not possible to follow the ideal 1000 delay to send, which leads to the accumulation of errors.

• Thread scheduling error

We know that when the music thread starts and sends a message to handler, there is a period of time when there is a process dispatch or other logical time-consuming operation that causes the two times not to occur simultaneously. So, every time we are in post, we need to compensate for the timing, but how do we do it?

Optimization for the handler mode

We know, Android has a lot of timing of the control, the first thought is digitalclock, the results found that has been abandoned, OK, see what replaced, OK, found Textclock, code a lot more, feel more awesome. We looked directly at how he dealt with the problem:

The same is found here by the programmer's sense of smell:

    privatefinalnew Runnable() {        publicvoidrun() {            onTimeChanged();            long now = SystemClock.uptimeMillis();            long next = now + (10001000);            getHandler().postAtTime(mTicker, next);        }    };

Ouch, a bit of meaning, we used to Postdelay to trigger the message event, but here the system uses Postattime, this is why? Naturally we will think of the first two lines of code, in fact, do not think too much, you take a value to try to know, if now is taken out is 1200, then next = 1200 + (1000-1200 1000) that is next= 2000. You see, although the event we were supposed to trigger in 1000 was delayed by various logic to 1200, then if you use Postdelay, the delay is accumulated, but if you use this method, the error is compensated.

Let's just call him the error compensation algorithm.

For individual timing threading methods

For a single timed thread, the timing thread will not be blocked by the main thread logic because the trigger event at the point of time and the main thread are separated, so it is OK to synchronize the start time difference as soon as it is guaranteed.

Optimizations for individual timing threading methods

In fact, for the individual timing thread said, there is no good optimization, and the advantages can be enumerated a lot:

1. Separate timing logic from UI logic for easy expansion
2. Accurate timing, the timing thread can be encapsulated, exposing the interface, easy to expand
3. Decoupling, loading and forcing

If you want to further optimize, you can use the time difference in the timing of the statistics, although there is no confusion.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Study on Obsessive-compulsive disorder--mediaplayer playback progress bar Optimization