瀏覽器內核與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。它們之間屬於互相調用的關係。