标签:
本文章为综合其它资料所得。
根据Google Developer,Chromium项目里,渲染线程分为main thread和compositor thread。
如果CSS动画只是改变transforms
和opacity
,这时整个CSS动画得以在compositor thread完成(而JS动画则会在main thread执行,然后触发compositor进行下一步操作)
在JS执行一些昂贵的任务时,main thread繁忙,CSS动画由于使用了compositor thread可以保持流畅,可参考adobe的博客。
在主线程中,维护了一棵Layer树(LayerTreeHost),管理了TiledLayer,在compositor thread,维护了同样一颗LayerTreeHostImpl,管理了LayerImpl,这两棵树的内容是拷贝关系。因此可以彼此不干扰,当Javascript在main thread操作LayerTreeHost的同时,compositor thread可以用LayerTreeHostImpl做渲染。当Javascript繁忙导致主线程卡住时,合成到屏幕的过程也是流畅的。
为了实现防假死,鼠标键盘消息会被首先分发到compositor thread,然后再到main thread。这样,当main thread繁忙时,compositor thread还是能够响应一部分消息,例如,鼠标滚动时,加入main thread繁忙,compositor thread也会处理滚动消息,滚动已经被提交的页面部分(未被提交的部分将被刷白)。
CSS动画比JS流畅的前提:
参考CSS Triggers,只有如下属性的修改才符合“仅触发Composite,不触发layout或paint”:
所以只有用上了3D加速或修改opacity时,才有机会用得上CSS动画的这一优势。
因此,在大部分应用场景下,效率角度更值得关注的还是下列问题。
那么Chromium以外的其他浏览器呢?CSSTrick里比较了一次效率。
Animated properties | JS-based Animation更快 | CSS-based Animation更快 |
top, left, width, height | Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS 6), iPad 3 (iOS7), Samsung Galaxy Tab 2, Chrome, Firefox, Safari, Opera, Kindle Fire HD, IE11 | (none) |
translate, scale | Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS7), Samsung Galaxy Tab 2, Firefox, Opera, IE11 | iPad 3 (iOS6), Safari, Chrome |
可以看到,Chromium以外的其他浏览器没有这方面的CSS动画效率的优化。尽管MSDN提到“它可提供更好的呈现性能”,但测试并没有支持这一点。
现今CSS动画和JS动画主要的不同点是
@keyframes
不支持递归定义,如果有多种类似的动画过程,需要调节多个参数来生成的话,将会有很大的冗余(比如jQuery Mobile的动画方案),而JS则天然可以以一套函数实现多个不同的动画过程@keyframes
的动画粒度粗,而JS的动画粒度控制可以很细TransitionEnd
、AnimationEnd
,但是它们都需要针对浏览器加前缀),JS则需要自己写事件标签:
原文地址:http://www.cnblogs.com/kirachen/p/4614803.html