浏览器内核与BOM对象介绍

BOM（Browser Object Model）对象介绍

我们都知道js有三部分组成，ECMAScript、DOM和BOM，根据宿主（浏览器）的不同，具体的表现形式也不尽相同，ie和其它浏览器也是风格迥异。

那么BOM和DOM有什么不同呢？

DOM是由W3C的制订，所有浏览器共同遵守的标准，描述了处理网页内容和方法的接口；BOM是各个浏览器厂商根据DOM实现与各自浏览器进行交互的方法和接口，表现为不同浏览器定义有差别，实现方式不同。

BOM主要处理浏览器容器的框架，不过通常浏览器特定的js扩展都被看做BOM的一部分，这个扩展包括：

1. 弹出新浏览器容器；
2. 移动、关闭浏览器容器以及调整窗口大小；
3. 提供web浏览器详细信息的定位对象；
4. 提供用户屏幕分辨率详细信息的屏幕对象；
5. 对cookie的支持？
6. IE扩展了BOM，加入了ActiveXObject类，可以通过Javascript实例化ActiveX对象；

工作机制

js是通过访问BOM对象来访问、控制、修改浏览器，由于BOM的window包含了document，window对象的属性和方法是直接可以使用而且被感知的，因此可以直接使用window对象的document属性访问、检索、修改XHTML文档的内容与结构。因为document对象又是DOM模型的根节点。可以说，BOM包含了DOM对象，浏览器提供出来给予访问的是BOM对象，从BOM对象再访问到DOM对象，从而js可以操作浏览器以及浏览器读取到的文档。

下面是浏览器运行Javascript时的一个鸟瞰图：

window 对象

BOM的核心是window，而window对象又具有双重角色，它既是通过js访问浏览器窗口的一个接口，又是一个Global（全局）对象。这意味着在网页中定义的任何对象，变量和函数，都以window作为其global对象。

基本属性

• window.innerHeight
• window.innerWidth
• window.outerHeight
• window.outerWidth
• 扩展内容 浏览器可视区域详解

浏览器内核

浏览器内核特征

在浏览器中，有一个最重要的模块，它主要的作用是将页面转变为可视化的图像结果，这就是浏览器内核。通常，它也被称为渲染引擎。
如下图所示：

其中浏览器渲染引擎对我们来说，这就是一个黑盒子。那么黑盒子里都放了什么东西呢？我们来看下图：

上图中只描述了渲染引擎中最基本的一些模块，下面介绍这些模块是如何一起工作以完成网页渲染过程。

下图从左至右逐次解释这一过程，先后关系由图中的实线箭头表示。从左上角开始，首先是网页内容，输入到HTML解释器，HTML解释器在解释它后构建成一棵DOM树，这期间如果遇到Javascript代码则交给Javascript引擎去处理；如果网页中包含CSS，则交给CSS解释器去解释。当DOM建立的时候，渲染引擎接收来自CSS解释器的样式信息，构建一个新的内部绘图模型。该模型由布局模块计算模型内部各个元素的位置和大小信息，最后由绘图模块完成从该模型到图像的绘制。

虚线箭头的指向含义表示在渲染过程中，每个阶段可能使用到的其它模块。在网页内容的下载中，需要使用到网络和存储，这点显而易见。但计算布局和绘图的时候，需要使用2D/3D的图形模块，同时因为要生成最后的可视化结果，这时需要开始解码音频、视频和图片，同其它内容一起绘制到最后的图像中。

浏览器主流内核介绍（渲染引擎）

在很久以前，人们梦想能拥有一个世界性的信息库。在这个信息库中，信息不仅能被全球的人们存取，而且能轻松链接到其他地方的信息，使用户可以方便快捷地获得重要的信息。

1990年，有个外国小伙儿，他叫做蒂姆·伯纳斯·李， 他使用超文本传输协议（HTTP）为NeXT计算机创建了第一个网页浏览器和第一个网页服务器（httpd），这个网页浏览器取名叫WorldWideWeb。这个名字后来被翻译成中文被叫做万维网。

后来WorldWideWeb改为Nexus，又有人把它移植到C，并把这个浏览器改名为libwww。

1993年，美国有个州有个大学有个组织，发表了第一个可以显示图片的浏览器，命名为Mosaic。

Trident(IE内核)

由于当时一些纠纷，Mosaic浏览器卖给了望远镜娱乐公司，微软从望远镜手里买到了Mosaic授权，在这个基础上开发了大名鼎鼎的IE浏览器。
Trident内核是微软在Mosaic代码基础之上修改来的，并沿用到了IE11，Trient内核常见的浏览器包括：

• IE6、7、8（Trident4.0）
• IE9（Trident 5.0）
• IE10（Trident 6.0）
• 360安全浏览器（1.0-5.0为Trident，6.0为Trident+Webkit，7.0为Trident+Blink）
• 猎豹极轻浏览器
• 360极速浏览器（7.5之前为Trident+Webkit，7.5为Trident+Blink）
• 猎豹安全浏览器（1.0-4.2版本为Trident+Webkit，4.3及以后版本为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）
• UC浏览器（Webkit内核+Trident内核）
• 等等等等

国内很多浏览器厂商号称双核或者多核，都是这样来的，其中一个是Trident，这叫做“兼容浏览模式”；再添加一个其它内核，这叫做“高速浏览模式”。

Gecko

Mosaic浏览器被卖给了望远镜娱乐公司后，Mosaic的开发团队重新撰写浏览器代码并改名为网景浏览器（netscape）。后来微软的IE浏览器发布之后，网景浏览器一落千丈，竞争失败后，网景开放了浏览器源码，成立非正式组织Mozilla并开发出了功能和稳定性上更出色的新一代网络就用软件套装“Mozilla Application Suite”，它所采用的新排版引擎被网景市场部门命名为“Gecko”。

Gecko的特点是代码完全公开，因此，其可开发程度很高，全世界的程序员都可以为其编写代码，增加功能。因为这是个开源内核，因此受到许多人的青睐，Gecko内核的浏览器也很多，这也是Gecko内核虽然年轻但市场占有率能够迅速提高的重要原因。

事实上，Gecko引擎的由来跟IE不无关系，前面说过IE没有使用W3C的标准，这导致了微软内部一些开发人员的不满；他们与当时已经停止更新了的 Netscape的一些员工一起创办了Mozilla，以当时的Mosaic内核为基础重新编写内核，于是开发出了Gecko。不过事实上，Gecko 内核的浏览器仍然还是Firefox (火狐) 用户最多，所以有时也会被称为Firefox内核。此外Gecko也是一个跨平台内核，可以在Windows、 BSD、Linux和Mac OS X中使用。

使用Gecko内核的浏览器包括：

• Mozilla Firefox（火狐浏览器）
• Netscape 6.0和以上
• 其它的都不认识，不写了。

Presto

这个是Opera12.17及之前版本使用的内核，该内核在2003年的Opera7中首次被使用，该款引擎的特点就是渲染速度的优化达到了极致，然而代价是牺牲了网页的兼容性。该内核现在已经停止开发并废弃。Opera现在使用的是Google Chrome的Blink内核；

Webkit

Webkit最早是由苹果公司开发的内核，也是safari浏览器上使用的内核。webkit引擎包含webCore排版引擎和JavascriptCore解析引擎。

webkit前身是KDE小组的KHTML引擎，可以说webkit是KHTML的一个开源分支，当年苹果在比较了Gecko和KHTML后，选择后者来做引擎开发，因为kHTML拥有清晰的源码结构和极快的渲染速度。

使用webkit的浏览器包括：

• Apple Safari
• Chrome(13年之前)
• 还有一些国产浏览器在Trident内核已经写过了

Blink

2008 年，谷歌公司发布了大名鼎鼎的 chrome浏览器，浏览器使用的内核被命名为 chromium。

chromium fork 自开源引擎 webkit，却把 WebKit 的代码梳理得可读性提高很多，所以以前可能需要一天进行编译的代码，现在只要两个小时就能搞定。因此 Chromium 引擎和其它基于 WebKit 的引擎所渲染页面的效果也是有出入的。所以有些地方会把 chromium 引擎和 webkit 区分开来单独介绍，而有的文章把 chromium 归入 webkit 引擎中，都是有一定道理的。

谷歌公司还研发了自己的 Javascript 引擎，V8，极大地提高了 Javascript 的运算速度。

chromium 问世后，带动了国产浏览器行业的发展。一些基于 chromium 的单核，双核浏览器如雨后春笋般拔地而起，例如 搜狗、360、QQ浏览器等等，无一不是套着不同的外壳用着相同的内核。

然而 2013 年 4 月 3 日，谷歌在 Chromium Blog 上发表 博客，称将与苹果的开源浏览器核心 Webkit 分道扬镳，在 Chromium 项目中研发 Blink 渲染引擎（即浏览器核心），内置于 Chrome 浏览器之中。

webkit 用的好好的，为何要投入到一个新的内核中去呢？

Blink 其实是 WebKit 的分支，如同 WebKit 是 KHTML 的分支。Google 的 Chromium 项目此前一直使用 WebKit(WebCore) 作为渲染引擎，但出于某种原因，并没有将其多进程架构移植入Webkit。

后来，由于苹果推出的 WebKit2 与 Chromium 的沙箱设计存在冲突，所以 Chromium 一直停留在 WebKit，并使用移植的方式来实现和主线 WebKit2 的对接。这增加了 Chromium 的复杂性，且在一定程度上影响了 Chromium 的架构移植工作。

基于以上原因，Google 决定从 WebKit 衍生出自己的 Blink 引擎（后由 Google 和 Opera Software 共同研发），将在 WebKit 代码的基础上研发更加快速和简约的渲染引擎，并逐步脱离 WebKit 的影响，创造一个完全独立的 Blink 引擎。这样以来，唯一一条维系 Google 和苹果之间技术关系的纽带就这样被切断了。

据说 Blink 删除了 880w 行 webkit 代码。

Q：上面提到 Chrome 是基于 WebKit 的分支，而 WebKit 又由渲染引擎 "WebCore" 和 JS 解释引擎 "JSCore" 组成，可能会让你搞不清 V8 和 JSCore 的关系？

A：你可以这样理解—— WebKit 是一块主板，JSCore 是一块可拆卸的内存条，谷歌实际上认为 Webkit 中的 JSCore 不够好！！，才自己搞了一个 V8 JS 引擎，这就是 Chrome 比 Safari 在某些 JS 测试中效率更高的原因。

目前在使用Blink内核的浏览器

• Chrome 渲染引擎（Blink）以及Javascript引擎（V8）
• Opera （现已改为Blink内核）
• 还有一些国产浏览器在Trident内核已经写过了

理解Chrome内核背景，解释Chrome中的几个概念

WebCore

WebCore是苹果公司开发的排版引擎，它是在另外一个排版引擎“KHTML”的基础上而来的。使用WebCore的主要有Safari，此外还有OmniWeb、Shiira、Swift等。Safari现支持Windows，但效果不如iOS上的。

KHTML

KHTML，是HTML网页排版引擎之一，由KDE所开发。

KDE系统自KDE2版起，在档案及网页浏览器使用了KHTML引擎。该引擎以C++编程语言所写，并以LGPL授权，支援大多数网页浏览标准。由于微软的Internet Explorer的占有率相当高，不少以FrontPage制作的网页均包含只有IE才能读取的非标准语法，为了使KHTML引擎可呈现的网页达到最多，部分IE专属的语法也一并支援。

KHTML拥有速度快捷的优点，但对错误语法的容忍度则比Mozilla产品所使用的Gecko引擎小。

苹果电脑于2002年采纳了KHTML，作为开发Safari浏览器之用，并发布所修改的最新及过去版本源代码。后来发表了开放源代码的WebCore及WebKit引擎，它们均是KHTML的衍生产品，在开发网站列出引擎改变内容，并会传回至KDE计划。由于两个衍生产品各走不同路线，使两者源代码偏离，在与KDE交换更新会出现困难。其中一个原因，是苹果在对外公开源代码之前，以一年时间编修他们的KHTML。另外，苹果传送更新至KDE计划的方式，多是一口气把大量改动一起传送，KDE在整理资料也出现一定的困难，及后苹果表示会以CVS格式来传送。再者，苹果所作出的改动包括Mac OS X系统独有的事物，如Objective-C、KWQ等，在Linux及KHTML是没有的。但KDE方面仍透过这些改动，为KHTML加入新功能及加快其排版速度。
基于KHTML内核的内核：WebKit、WebCore。

关于移动端内核

• Iphone和ipad等苹果IOS平台主要使用webkit
• Android4.4之前的系统浏览器内核是webkit
• android4.4系统浏览器切换到chromium，内核是blink
• windows phone8系统浏览器内核是Trident

Javascript引擎

简单来讲，就是能够将 Javascript 代码处理并执行的运行环境。

JavaScript 语言是一种解释性脚本语言，因此在运行时，需要先将代码转变成抽象语法树，然后在抽象语法树上解释执行。

当然为了提高 js 的执行速度，同时随着 JIT （Just In Time）的技术引入，现在的 js 引擎大多会做一些性能优化，就是在执行前会将抽象语法树再转成一个中间表示（这个中间表示可能是字节码，也可能是直接转成本地代码）。这样就会极大的提高代码的执行速度。

不过 js 从抽象语法树转成中间表示的过程都是处在代码执行阶段的（解释性语言并不像编译性语言那样，编译和执行是分开的），所以在代码执行阶段进行额外的转换本身也是需要开销的。

综上描述，一个 JavaScript 引擎一般需要包括以下几个部分：

编译器。主要工作是将源代码编译成抽象语法树，在某些引擎可能还包含了将抽象语法树转换成中间表示（字节码）。

解释器。在某些引擎中，解释器主要是接收字节码，解释执行这个字节码，同时也依赖垃圾回收机制等。

JIT 工具。一个能够 JIT 的工具，将字节码或者抽象语法树转换成本地代码。

垃圾回收器和分析工具。它们负责垃圾回收和收集引擎中的信息，帮助改善引擎的性能和功效。

Q：目前都有哪些javascript引擎？

A：打开百度搜索“javascript引擎 百度百科 ” 查看介绍。^_^

JavaScript 引擎和渲染引擎

之前在说 DOM 树的构建的时候，了解过在 HTML 解释器的工作过程中，可能会有 JavaScript 代码需要执行，而渲染引擎主要负责渲染页面。js 引擎提供调用接口给渲染引擎，以便让渲染引擎使用 js 引擎来处理 js 代码并获取结果。渲染引擎同时需要提供桥接接口让 js 可以访问 DOM。它们之间属于互相调用的关系。