浏览器的组件、网页引擎、渲染流程等

浏览器内核：1.Webkit内核；2.Chrominum内核；3.Blink内核。
四大渲染引擎在线：WebKit、Blink、Trident 和Gecko。
> 不同的浏览器及内核
  目前是互联网上最流行的排版引擎： Internet Explorer；世界之窗浏览器；Avant；腾讯TT；NetCaptor； Sleipnir； GOSURF； GreenBrowser
1.KKman
  现在有四大渲染引擎在线：WebKit、Blink、Trident 和Gecko。对于用户来说，渲染引擎的差异化意味着他们在使用不同浏览器打开同一网页时将得到不同的结果——在移动设备上尤其如此。

2.Gecko
  是Netscape6开始采用的内核，后来的Mozilla FireFox也采用了该内核，Gecko的特点是代码完全公开，是个开源内核，因此受到许多人的青睐。

3.Trident
  是Windows搭载的网页浏览器即IE的内核。1997年在IE4中使用。采用的排版引擎(俗称内核)为Trident。
IE6、IE7、IE8（Trident 4.0）、IE9（Trident 5.0）、IE10（Trident 6.0）；
猎豹安全浏览器（1.0-4.2版本为Trident+Webkit，4.3版本为Trident+Blink）；
360安全浏览器（1.0-5.0为Trident，6.0为Trident+Webkit，7.0为Trident+Blink）；
360极速浏览器（7.5之前为Trident+Webkit,7.5为Trident+Blink）；
傲游浏览器（傲游1.x、2.x为IE内核，3.x为IE与Webkit双核）；
百度浏览器（早期版本）；
世界之窗浏览器[2] （最初为IE内核，2013年采用Chrome+IE内核）；
2345浏览器、腾讯TT、淘宝浏览器；
搜狗高速浏览器（1.x为Trident，2.0及以后版本为Trident+Webkit）；
阿云浏览器（早期版本）、瑞星安全浏览器；
闪游浏览器、海豚浏览器（iPhone/iPad/Android）；
UC浏览器（Blink内核+Trident内核）；

4.Blink
  由Google和Opera Software开发的浏览器排版引擎。至于js引擎，想必Chrome依旧使用自己的V8引擎。
  在2013年4月，Google计划将这个渲染引擎作为Chromium计划的一部分。这一渲染引擎是开源引擎WebKit中WebCore组件的一个分支。并且在Chrome（28及往后版本）、Opera（15及往后版本）中使用。此举，谷歌称称将与苹果的开源浏览器核心Webkit分道扬镳。

5.Presto
  是Opera12.10至Opera7中采用的内核，现已停止开发并废弃，由于这是商业引擎（非开源），所以在发展上有了限制。这篇里面，我有写到，在Opera12.10版本以后使用Blink作为其内核。

> 浏览器的主要组件有以下几部分：
 1.用户界面，除了用来显示浏览器主窗口之外的浏览器的其他部分，例如书签目录，地址栏，前进后退……。
 2.浏览器引擎，这里说，浏览器引擎是查询及操作渲染引擎的接口。我在网上搜的时候也大都是默认为渲染引擎。
 3.渲染引擎，用来显示请求的内容，如果请求内容为html，那么负责解析html、及css并将解释后的结果显示出来。还可以解析xml文件。
 4.js引擎，用来解释执行js代码。
 5.网络，用来完成网络调用，如http请求。
 6.Native UI，用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口。
 7.数据存储，属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据。

> 浏览器基本认识
  网页浏览器的排版引擎也被称为页面渲染引擎，它负责取得网页的内容（HTML、XML、图象等等）、整理信息（例如加入CSS等），以及计算网页的显示方式然后会输出至显示器或打印机。所有网页浏览器、电子邮件客户端以及其它需要编辑、显示网络内容的应用程序都需要排版引擎。
  KHTML及KJS，khtml为排版引擎即渲染引擎，kjs为JS引擎。
  KHTML，是HTML网页排版引擎之一，由KDE所开发，符合GPL(由他为基础开发的软件也为开源软件)。KHTML拥有速度快捷的优点，但对错误语法的容忍度则比Mozilla产品所使用的Gecko引擎小。苹果电脑于2002年采纳了KHTML，作为开发Safari浏览器之用。WebCore及WebKit引擎均是KHTML的衍生产品；WebKit是Mac OS X v10.3及以上版本所包含的软件框架，WebKit是Mac OS X的Safari网页浏览器的基础。 
  Webkit包括webcore排版引擎与JavaScriptCore解析引擎，均是苹果从KDE的KHTML及KJS引擎衍生而来。是苹果公司自己的内核，也是Safari浏览器使用的内核，但是符合GPL条款，所以webkit为开源的，但是Safari浏览器为部分开源，自己公司的某些接口未对外开源。在Chrome 28之前，google使用webkit中webcore与自己的javascript V8引擎。那时也统称为webkit引擎。
  WebKit 是一个开源的浏览器引擎。WebKit 也是苹果Mac OS X 系统引擎框架版本的名称-即苹果KDE的KHTML及KJS引擎衍生而来，主要用于Safari，Dashboard，Mail 和其他一些Mac OS X 程序。WebKit 所包含的 WebCore排版引擎和 JSCore引擎来自于 KDE 的 KHTML 和KJS，当年苹果比较了 Gecko 和 KHTML 后，仍然选择了后者，就因为它拥有清晰的源码结构、极快的渲染速度。 WebKit是开源的Web浏览器引擎，苹果的Safari、谷歌的Chrome浏览器都是基于这个框架来开发的。WebKit 还支持移动设备和手机，包括iPhone和Android手机都是使用WebKit做为浏览器的核心。

   Webkit已成新的宠儿，它的幕后推手是当今科技界炙手可热的两家公司—苹果和谷歌（2013年谷歌宣布停止使用WebKit作为Chrome浏览器的渲染引擎，并开发自己的网页渲染引擎“Blink”）和。  Google 宣布将在未来的 Google Chrome/Chromium 中使用基于 WebKit 的 fork Web 渲染引擎：Blink。同时 Opera 表示也将跟进 Google Chrome/Chromium 的步伐。着重改善 DOM 架构，将使用 JavaScript 实现 DOM。值得注意的是，Webkit内核浏览器的增长，对应的便是IE浏览器的份额流失。有意思的是，连微软自己都在探讨在IE中引入Webkit的可能性，微软CEO鲍尔默曾表示“将可能使用开源引擎Webkit来拓展IE”。即便这是鲍尔默的烟雾弹，也可以肯定的是，依旧占据统治地位的IE无法忽视Webkit可能带来的威胁。
   这一举措意味着，现在有四大渲染引擎在线：WebKit、Blink、Trident 和Gecko。对于用户来说，渲染引擎的差异化意味着他们在使用不同浏览器打开同一网页时将得到不同的结果——在移动设备上尤其如此。

> 网页引擎，不同浏览器有不同的JS引擎：
WebKit,Safari浏览器--SquirrelFish Extreme；
Firefox --TraceMonkey引擎；
Google Chrome--V8引擎，（C++）；
Opera--Carakan；
Mozilla--SpiderMonkey(C语言);Mozilla--Rhino( Java);Mozilla--JaegerMonkey；

浏览器内核，渲染引擎、js引擎- http://blog.csdn.net/BonJean/article/details/78453547
  Mozilla将其排版引擎（Gecko）作为独立于浏览器的一个配件，Gecko是套开放源代码的、以C++编写的网页排版引擎。Gecko是跨平台的，能在Microsoft Windows、Linux和Mac OS X等主要操作系统上运行。
  SEE (Simple ECMAScript Engine) C语言开发的轻量级的 ECMAScript (JavaScript) 解析器和实时运行环境.
  一个浏览器页面至少存在三个线程:js引擎线程(处理js)、GUI渲染线程(渲染页面)、浏览器事件触发线程(控制交互)。即使是线程模式，浏览器多个页面的时候也存在为数众多的线程。
  考虑当前的浏览器主要有两个对性能要求较高的两个部分：
  1.JS引擎，对于JS引擎，较旧的引擎一般都是单线程的，新的引擎都开始支持多线程的实现了，例如chrome的JS引擎中的webwork调度单元就是以多线程为基础的。
  2.Render引擎，对于Render引擎，涉及的面就更复杂，特别是最进HTML5中WebGL引入之后，涉及到的模块就跟多。 

> 渲染流程
  解析器的类型：解析器有两种基本类型——自上而下解析器和自下而上解析器。主观上可以认为自上而下的解析器从上层句法结构开始尝试匹配句法；自下而上的则从输入开始，慢慢转换成句法规则，从底层规则开始，直到上层规则全部匹配。

  渲染引擎在取得内容之后的基本流程：解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树
-- 浏览器会解析三个东西： 
（1）HTML/SVG/XHTML，解析这三种文件会产生一个 DOM Tree。 
（2）CSS，解析 CSS 会产生 CSS 规则树。 
（3）JavaScript脚本，主要是通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree.

-- 网页渲染流程: 
 1.浏览器解析html源码，然后创建一个 DOM树。
在DOM树中，每一个HTML标签都有一个对应的节点，并且每一个文本也都会有一个对应的文本节点。DOM树的根节点就是 documentElement，对应的是html标签。
 2.浏览器解析CSS代码，计算出最终的样式数据。
对CSS代码中非法的语法她会直接忽略掉。解析CSS的时候会按照如下顺序来定义优先级：浏览器默认设置 < 用户设置 < 外链样式 < 内联样式 < html中的style。
 3.构建出DOM树，并且计算出样式数据后，下一步就是构建一个 渲染树（rendering tree）。渲染树和DOM树有点像，但是是有区别的。DOM树完全和html标签一一对应，但是渲染树会忽略掉不需要渲染的元素，比如head、display:none的元素等。而且一大段文本中的每一个行在渲染树中都是独立的一个节点。渲染树中的每一个节点都存储有对应的css属性。
 4.一旦渲染树创建好了，浏览器就可以根据渲染树直接把页面绘制到屏幕上。
重绘和重排（repaints and reflows）
每个页面至少在初始化的时候会有一次重排操作。
  任何对渲染树的修改都有可能会导致下面两种操作：
  1.重排就是渲染树的一部分必须要更新 并且节点的尺寸发生了变化。这就会触发重排操作。
  2.重绘部分节点需要更新，但是没有改变他的集合形状，比如改变了背景颜色，这就会触发重绘。什么情况下会触发重绘或重排。

-- How browsers work- http://taligarsiel.com/Projects/howbrowserswork1.htm
HTML页面加载和解析流程: 
 1.用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件； 
 2.浏览器开始载入html代码，发现＜head＞标签内有一个＜link＞标签引用外部CSS文件； 
 3.浏览器又发出CSS文件的请求，服务器返回这个CSS文件； 
 4.浏览器继续载入html中＜body＞部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了； 
 5.浏览器在代码中发现一个＜img＞标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码； 
 6.服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码； 
 7.浏览器发现了一个包含一行javascript代码的＜script＞标签，赶快运行它； 
 8.Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个＜div＞ （style.display=”none”）。突然少了这么一个元素，浏览器不得不重新渲染这部分代码； 
 9.终于等到了＜/html＞的到来，浏览器泪流满面…… 
 10.等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下＜link＞标签的CSS路径； 
 11.浏览器召集了在座的各位＜div＞＜span＞＜ul＞＜li＞们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。

-- 减少重绘和重排：
1.不要一个一个地单独修改属性，最好通过一个classname来定义这些修改
2.把对节点的大量修改操作放在页面之外用 documentFragment来做修改clone 节点，在clone之后的节点中做修改，然后直接替换掉以前的节点通过 display: none 来隐藏节点（直接导致一次重排和重绘），做大量的修改，然后显示节点（又一次重排和重绘），总共只会有两次重排。
3.不要频繁获取计算后的样式。如果你需要使用计算后的样式，最好暂存起来而不是直接从DOM上读取。
4.总的来说，总是考虑到渲染树得存在，考虑到你的一次修改会导致多大的绘制操作。比如绝对定位元素的动画就不会影响其他大部分元素。

-- 编写CSS时应该注意：
CSS选择符是从右到左进行匹配的。从右到左！所以，#nav li 我们以为这是一条很简单的规则，秒秒钟就能匹配到想要的元素，但是，但是，但是，是从右往左匹配啊，所以，会去找所有的li，然后再去确定它的父元素是不是#nav。，因此，写css的时候需要注意：
1.dom深度尽量浅。
2.减少inline javascript、css的数量。
3.使用现代合法的css属性。
4.不要为id选择器指定类名或是标签，因为id可以唯一确定一个元素。
5.避免后代选择符，尽量使用子选择符。原因：子元素匹配符的概率要大于后代元素匹配符。后代选择符;#tp p{} 子选择符：#tp>p{}
6.避免使用通配符，举一个例子，.mod .hd *{font-size:14px;} 根据匹配顺序,将首先匹配通配符,也就是说先匹配出通配符,然后匹配.hd（就是要对dom树上的所有节点进行遍历他的父级元素）,然后匹配.mod,这样的性能耗费可想而知.

- Javascript的加载和执行的特点： 
（1）载入后马上执行； 
（2）执行时会阻塞页面后续的内容（包括页面的渲染、其它资源的下载）。原因：因为浏览器需要一个稳定的DOM树结构，而JS中很有可能有 代码直接改变了DOM树结构，比如使用 document.write 或 appendChild,甚至是直接使用的location.href进行跳转，浏览器为了防止出现JS修 改DOM树，需要重新构建DOM树的情况，所以 就会阻塞其他的下载和呈现。

- 减少JavaScript对性能的影响的方法：
1.将所有的script标签放到页面底部，也就是body闭合标签之前，这能确保在脚本执行前页面已经完成了DOM树渲染。
2.尽可能地合并脚本。页面中的script标签越少，加载也就越快，响应也越迅速。无论是外链脚本还是内嵌脚本都是如此。
3.采用无阻塞下载 JavaScript 脚本的方法： 
（1）使用script标签的 defer 属性（仅适用于 IE 和 Firefox 3.5 以上版本）； 
（2）使用动态创建的script元素来下载并执行代码；