在运行的时候即使是在电脑浏览器上也会隐约觉得动画的运行并不流畅,更不要提在移动端达到60fps的流畅效果了。这是因为top和left的改变会触发浏览器的reflow和repaint,整个动画过程都在不断触发浏览器的重新渲染,这个过程是很影响性能的。
为了解决这个问题,我们使用transform中的translate()来替换top和left
这个时候我们就会发现整个动画效果流畅了很多,在动画移动的过程中也没有发生repaint和reflow。那么为什么transform没有出发repaint呢?原因就是transform动画由GPU控制,支持硬件加速,并不需要软件方面的渲染。
浏览器收到页面文档后,会将文档中的标记语言解析为DOM树,DOM和CSS结合后形成浏览器构建页面的渲染树,渲染树中包含了大量的渲染元素,每一个渲染元素会被分到一个图层中,每个又会被加载到GPU形成渲染纹理,而图层在GPU中transform是不会触发repaint的,这一点非常类似3D绘图功能,最终这些使用transform的图层都会使用独立的合成器进程进行处理,移动时的变化也是独立的,不会影响到页面的其他元素,造成重排重绘是因为影响到页面的其他图层元素导致的,可以理解为其他元素都是在一个图层空间,所以一个图层移动其他的也会收到影响,而transform创建了一个新的复合图层,它会被GPU独立执行transform操作,跟其他图层互不影响,所以不会引起重排重绘。
此时,你也许会问浏览器什么时候会创建一个独立的复合图层呢?事实上一般是在以下几种情况下:
因为GPU进程会为其开启一个新的复合图层,不会影响默认复合图层(就是普通文档流),所以并不会影响周边的 DOM 结构,而属性的改变也会交给 GPU 处理,不会进行重排。使 GPU 进程开启一个新的复合图层的方式还有 3D 动画,过渡动画,以及 opacity 属性,还有一些标签,这些都可以创建新的复合图层。这些方式叫做硬件加速方式。你可以想象成新的复合图层和默认复合图层是两幅画,相互独立,不会彼此影响。降低重排的方式:要么减少次数,要么降低影响范围,创建新的复合图层就是第二种优化方式。绝对布局虽然脱离了文档流,但不会创建新的复合图层,因此当绝对布局改变时,不会影响普通文档流的 render tree,但是依然会绘制整个默认复合图层,对普通文档流是有影响的。普通文档流就是默认复合图层,不要介意我交换使用它们如果你要使用硬件加速方式降低重排的影响,请不要过度使用,创建新的复合图层是有额外消耗的,比如更多的内存消耗,并且在使用硬件加速方式时,配合 z-index 一起使用,尽可能使新的复合图层的元素层级等级最高。
(1)transform
(2)opacity
(3)filter
(1)内存。如果GPU加载了大量的纹理,那么很容易就会发生内存问题,这一点在移动端尤为明显。
(2)使用GPU渲染会影响字体的抗锯齿效果。这是因为GPU和CPU具有不同的渲染机制,即使最终硬件加速停止了,文本还是会在动画期间显示的很模糊。
1、transform会使用GPU硬件加速,性能更好,position + top/left会触发大量的重排重绘,性能影响较大。
2、硬件加速的工作原理是创建一个新的复合图层,然后使用合成线程进行渲染
3、3D和2D动画的区别,2D动画会在动画开始和动画结束时触发2次重新渲染
4、使用了GPU可以优化动画小故宫但是不要滥用,会有内存问题
5、理解强制触发硬件加速的transform技巧,使用对GPU友好的CSS属性
参考文章: https://zhuanlan.zhihu.com/p/78230297
el-scrollbar是elementui自带的页面滚动条,如果用页面滚动条,我们发现在ie浏览器下卡顿很明显,但是用el-scrollbar滚动页面就会感觉会流畅很多,因为页面滚动会引发重排重绘,但是el-scrollbar是用transform不会引起,所以用el-scrollbar会感觉流畅很多,转订单去掉overflow:hidden就会流畅是因为这个样式会覆盖el-scrollbar的样式,
document.write重排整个页面
innerHTML可以重绘页面的一部分
1、构建DOM树(parse):渲染引擎解析HTML文档,首先将标签转换成DOM树中的DOM node(包括js生成的标签)生成内容树(Content Tree/DOM Tree);
2、构建渲染树(construct):解析对应的CSS样式文件信息(包括js生成的样式和外部css文件),而这些文件信息以及HTML中可见的指令(如<b></b>),构建渲染树(Rendering Tree/Frame Tree);
3、布局渲染树(reflow/layout):从根节点递归调用,计算每一个元素的大小、位置等,给出每个节点所应该在屏幕上出现的精确坐标;
4、绘制渲染树(paint/repaint):遍历渲染树,使用UI后端层来绘制每个节点。
重绘(repaint或redraw):当盒子的位置、大小以及其他属性,例如颜色、字体大小等都确定下来之后,浏览器便把这些原色都按照各自的特性绘制一遍,将内容呈现在页面上。重绘是指一个元素外观的改变所触发的浏览器行为,浏览器会根据元素的新属性重新绘制,使元素呈现新的外观。
触发重绘的条件:改变元素外观属性。如:color,background-color等。
重排(重构/回流/reflow):当渲染树中的一部分(或全部)因为元素的规模尺寸,布局,隐藏等改变而需要重新构建, 这就称为回流(reflow)。每个页面至少需要一次回流,就是在页面第一次加载的时候。
重绘和重排的关系:在回流的时候,浏览器会使渲染树中受到影响的部分失效,并重新构造这部分渲染树,完成回流后,浏览器会重新绘制受影响的部分到屏幕中,该过程称为重绘。
重排必定会引发重绘,但重绘不一定会引发重排。
触发重排的条件:任何页面布局和几何属性的改变都会触发重排,比如:
1、页面渲染初始化;(无法避免)
2、添加或删除可见的DOM元素;
3、元素位置的改变,或者使用动画;
4、元素尺寸的改变——大小,外边距,边框;
5、浏览器窗口尺寸的变化(resize事件发生时);
6、填充内容的改变,比如文本的改变或图片大小改变而引起的计算值宽度和高度的改变;
7、读取某些元素属性:(offsetLeft/Top/Height/Width, clientTop/Left/Width/Height, scrollTop/Left/Width/Height, width/height, getComputedStyle(), currentStyle(IE) )
重绘发生的情况:
重绘发生在元素的可见的外观被改变,但并没有影响到布局的时候。比如,仅修改DOM元素的字体颜色(只有Repaint,因为不需要调整布局)
重绘重排的代价:耗时,导致浏览器卡慢。
1、浏览器自己的优化:浏览器会维护1个队列,把所有会引起回流、重绘的操作放入这个队列,等队列中的操作到了一定的数量或者到了一定的时间间隔,浏览器就会flush队列,进行一个批处理。这样就会让多次的回流、重绘变成一次回流重绘。
2、我们要注意的优化:我们要减少重绘和重排就是要减少对渲染树的操作,则我们可以合并多次的DOM和样式的修改。并减少对style样式的请求。
(1)直接改变元素的className
(2)display:none;先设置元素为display:none;然后进行页面布局等操作;设置完成后将元素设置为display:block;这样的话就只引发两次重绘和重排;
(3)不要经常访问浏览器的flush队列属性;如果一定要访问,可以利用缓存。将访问的值存储起来,接下来使用就不会再引发回流;
//例如myElement元素沿对角线移动,每次移动一个像素。到500*500像素的位置结束。timeout循环体中可以这么做
//显然这种方法低效,每次移动都要查询偏移量,导致浏览器刷新渲染队列而不利于优化。好的办法是获取一次起始位置的值,然后赋值给一个变量。如下
(4)使用cloneNode(true or false) 和 replaceChild 技术,引发一次回流和重绘;
(5)将需要多次重排的元素,position属性设为absolute或fixed,元素脱离了文档流,它的变化不会影响到其他元素;
(6)如果需要创建多个DOM节点,可以使用DocumentFragment创建完后一次性的加入document;
(7)尽量不要使用table布局。
不管页面发生了重绘还是重排,它们都会影响性能(最可怕的是重排 ,应尽量避免)
DOM:描述该页面的结构
render:描述 DOM 节点 (nodes) 在页面上如何呈现
当 DOM 元素的属性发生变化 (如 color) 时, 浏览器会通知 render 重新描绘相应的元素, 此过程称为 repaint。
如果该次变化涉及元素布局 (如 width), 浏览器则抛弃原有属性, 重新计算并把结果传递给 render 以重新描绘页面元素, 此过程称为 reflow。
这两个过程是很耗费浏览器性能的, 从 IE 系列和 Chrome 渲染页面速度上的差距即可看出渲染引擎计算对应值和呈现并不一定高效, 而每次对元素的操作都会发生 repaints 或 reflow, 因此编写 DOM 交互时如果不注意就会导致页面性能低下.
页面渲染的过程如下:
原文:
https://blog.csdn.net/sinat_37328421/article/details/54575638
https://blog.csdn.net/sophia_little/article/details/79613990
https://blog.csdn.net/qq_34255080/article/details/86235234