关于浏览器渲染原理的读后感

今天刚刚看了一篇关于浏览器渲染原理的文章，受益匪浅，给自己带来了很多感悟。同时也发现了自己在这之前，进行网页开发中的许多错误。

关于浏览器渲染原理，我觉得是前端开发人员必备的东西。如果一个前端开发人员连浏览器渲染原理都没有搞懂，那么就无异于一个剑士还没学会舞剑。

我在这里简单地说一下浏览器的渲染原理（虽然这不是我这篇博文想讲的重点，但是我还是打算让自己巩固一下刚刚掌握的知识，如果有错误的地方还请各位指出）。

首先，浏览器会对页面分成三个部分处理，第一部分是html/svg/xhtml部分，这部分主要是负责生产DOM树；第二部分是CSS部分，这部分主要是生产一个叫CSS规则数，也就是CSS RULE TREE。第三部分自然是必不可少的JS了，这部分主要是通过解析JS来操控DOM树和CSS规则树。

其后，浏览器会通过DOM树和CSS规则树的融合来构造出RENDER TREE也就是渲染树，当渲染树构造完毕之后，浏览器会进行layout/reflow过程。当layout/reflow过程完毕后，浏览器最后就会调用操作系统的Native GUI的API对页面进行绘制。

以上就是浏览器大致的渲染全过程。

其实我在这里更关注的是layout/reflow过程。因为这个过程很有意思，因为它不仅仅会发生在页面初始化的时候，它还会发生在很多涉及到页面重绘的时候。接下来我会针对这个问题展开讨论。

在这里有两个概念，第一个是repaint，第二个是reflow。这两个都是属于重绘，只不过repaint是当整个页面的布局流没有受到影响的前提下发生的，而reflow发生于页面布局发生了变化的时候。而这两种重绘对浏览器会造成相当的负荷，所以在处理页面的时候，我们一定需要考虑到这个问题。

好吧，接下来针对这两种重绘我提一些小技巧（绝无抄袭，是本人总结的一些实用技巧哦！）

1.TAB控件的细节

很多人都喜欢用TAB控件，的确，TAB控件能够使页面很美观很友好地将内容呈现出来。但是，许多人在写TAB控件的时候常常不注意一个问题：当TAB控件在切换TAB页的时候的处理。

不理解？不要紧，我们知道当从一个TAB页到另一个TAB页很可能要用到display: block;和display: none;这个属性，但是要知道的是当一个元素的显现和另一个元素的隐藏的过程是要进行两次重绘的（自己想一下），虽然目前一些浏览器会对这一块进行优化（合并两次重绘为一次），但是这样的处理显然会对页面造成不良的影响，毕竟如果页面内容多的话，CPU要承受挺大的负荷的。

所以，我建议大家把TAB页的position属性设置为absolute。这样所有tab页的重叠可以占用一样的空间，而且当position为fixed或absolute时，元素是脱离DOM树的，所以当元素尺寸改变不会造成整个RENDER TREE的重新渲染。

2.Toolbar的合理运用

工具栏的合理运用至关重要，如今许多页面的工具栏采用了类似于position: fixed;的方式让用户方便进行操作。但是，工具栏的构造要注意要做到不能太过复杂，因为当浏览器进行滚动的时候，浏览器要对页面内容进行像素上移，由于有FIXED住的元素存在，所以浏览器除了对元素上移进行渲染之外，还得“留意”你FIXED的元素，所以倘若你的TOOLBAR有个很酷炫的背景或者动画效果，那么对浏览器来说是一件痛苦的事情。

3.尽量少在table中修改样式

有部分帅哥美女用table显示数据时还额外添加了一些酷炫效果：悬停字体变大或变粗、悬停改变布局等。我觉得这是不对的。Table内的元素一旦发生reflow，就会造成整个table元素的重绘。这对浏览器来说花销是很大的。而且如果不是必要，我也不推荐使用table。

4.JS动画效果要注意的

页面中难免要用JS来对元素样式进行一些动态的修改。但是，我建议大家要：集中地，批量地去修改元素的样式，尽量避免长时间地影响页面的布局。

5.其它

这里还有一些我看完文章之后学习到的一些小技巧：

1.reflow的开销永远是比repaint要大的，如果不能避免重绘，那么请尽量把开销降低到最少。

2.尽量做到修改元素的ClassName而不是直接修改其样式。

3.倘若要对某个大布局进行较大修改，建议先将其display: none掉之后再修改然后再display: block;显示出来。

4.尽量直接使用CLASS或ID，避免用标签选择器等迭代地去匹配元素。

好吧，今天就写到这儿，这篇东西其实属于个人笔记，有理解不到位之处还请原谅。