- 2020-05-12 02:15:07
When Html5 and css3 have gradually become the mainstream, I am quite used to using js to do some simple animations. Because on desktop browsers, not all of them support css3. The user is also very strange, the user habit is not every user can be cultivated. There are always a lot of people who think win7.win8 is not as good as xp. On mobile, however, the browser's support for html5 and css3 is good. But the phone's hardware processing power is limited. In the 4 - core, 8 - core mobile phone rampant today, there are still like me to use dual-core or single-core mobile phone. Although js is good, the single touch is not much, adjust that kind of feeling. One simple page slide, running 10 shunts on i7's pc, but on my dual-core phone it's just card, ton, card, ton. Depressing. For this reason, I have been looking for a long time and have seen a lot. Finally, I found a relatively easy way to use css3 to perform animation.
In the past, in addition to Jquery's animate and other animation functions, setTimeout and setInterval were mostly used for animation. In this way, the attributes of margin, width and top of one element were changed in a cycle. That's why I'm so confused.
First of all, setTimeout,setInterval doesn't mean you can set 0ms and it will do it one straight line. I stumbled across this secret while debugging in iscroll. The original Timer delay was calculated using the browser's built-in clock, and the accuracy of the clock was determined by how often the clock was updated. IE8 and its predecessor, IE, are updated at an interval of 15.6 milliseconds. That's it. I think it's 10ms performing a 1px shift, and it's not going to be able to do it on time.
And what about the card? Card, because the code is bad. After all, js is single-threaded, and once there is a time-consuming action, UI may not be responsive. Although we used setTimeout, it was setTimeout that made it look like the interface wasn't dead but it wasn't flowing. Since after this setTimeout execution, another time-consuming action is likely to occur in the middle interval before the next one, the execution of setTimeout will be infinitely delayed. And then what? Card! However, there is another reason that a card can accidentally trigger the browser Layout when changing the original property. It's not time consuming, it's time consuming, it's time consuming, it's time consuming, and a lot of times it's negligible. But a lot of times it can't be ignored.
In addition to the above two paragraphs, there is also a problem, is on many mobile phones always feel 1 frame 1 frame, but also may be 1 frame long 1 frame short. This is the kind of rhythm that makes people waste. Why is this so? It still has a definite relationship with the delay of settimeout. Lost frames. This problem has to do with the refresh rate of the display. It's too complicated.
Finally, CSS3 and js are selected to dynamically change the attributes of the elements, and transition is used to control the execution time of the animation. Here's an example:
<div id="test" style="transition:all 1s ease; width:100px;" ></div>
So after 1 second the width of this div is going to be 200px. Not sun wukong change peach 1 kind of instant become big, slowly rush foot, not a card not a ton. And the advantage of using the css animation is that it is not affected by the time taken by js. Although the UI thread and the js thread are mutually exclusive in the browser, this point does not apply to the css animation, and many browsers enable hardware acceleration (e.g., Chrome). Although browser relayout is not obvious in the normal case, it should be avoided as much as possible. so adds -webkit-transform: translateZ(0); Or - webkit - transform: translate3d (0, 0); The browser will render the layer independently. Even if the rearrangement is unavoidable, the area is smaller. And replacing margin with translate is a really smart 10.
Finally, I have attached some common properties that trigger relayout when changed: