浏览器内核与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内核常见的浏览器包括：

• IE六、七、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。它们之间属于互相调用的关系。