瀏覽器-09 javascript引擎和Chromium網絡棧

語言的運行

C/C++語言

• 使用編譯器直接將它們編譯成本地代碼(機器指令)，這是由開發人員在代碼編寫完成以後實施;
• 用戶只是使用這些編譯好的本地代碼，這些本地代碼被系統的加載器加載執行，由操做系統調度CPU直接執行，無需其它額外的輔助虛擬機等;
• 這一過程基本上是從源代碼開始，而後抽象語法樹，以後中間表示，最後到本地代碼;

Python等腳本語言

• 處理腳本語言一般的作法是開發者將寫好的代碼直接交給用戶，用戶使用腳本的解釋器將腳本文件加載而後解釋執行;
• 固然，如今Python也能夠支持將腳本編譯生成中間表示;
• 因此對於腳本語言，通常須要開發人員的編譯過程；
• 這主要由於使用場景不同，它的目的不是高性能;
• 這一過程是源代碼，到抽象語法樹，再到解釋器解釋執行;

Java語言

• 其能夠理解爲比較明顯的兩個階段:
  * 首先是像C++語言同樣的編譯器，可是，同C++編譯器生成的本地代碼結果不一樣，通過編譯器編譯以後的是字節碼，字節碼是平臺無關的;
  * 在運行字節碼階段，Java的運行環境也就是Java虛擬機會加載字節碼，使用解釋執行這些字節碼;
  * 同時現代Java虛擬機通常都引入了JIT技術，也就是前面說的將字節碼轉變成本地代碼來提升執行效率;
• 這主要兩個階段，第一階段對時間要求不嚴格，第二階段則對每一個步驟所花費的時間很是敏感，時間越短越好;

JavaScript語言

• 它是一種解釋性腳本語言，可是隨着衆多工程師不斷投入資源來提升它的速度，這使得它可以使用了Java虛擬機和C++編譯器中衆多的技術;
• 同時它的工做方式也在演變:
  * 早期由解釋器來解釋它們便可，就是將源代碼轉變成抽象語法樹，而後在抽象語法樹上解釋執行;
  * 隨着將Java虛擬機的JIT技術引入，如今的作法是將抽象語法樹轉成中間表示（也就是字節碼），而後經過JIT技術轉成本地代碼，這可以大大的提升了執行效率;
  * 固然也有些作法直接從抽象語法樹生成本地代碼的JIT技術，例如V8;
• JavaScript跟Java仍是有如下一些區別：
  * JavaScript是無類型的語言，這使得對於對象的表示和屬性的訪問上比Java存在比較大的性能損失;
  * Java語言一般是將源代碼編譯成字節碼，這個同執行階段是分開的，也就是從源代碼到抽象語法樹到字節碼這段時間的長短是無所謂的，主要是儘量的生成高效的字節碼便可;而對於JavaScript，這些都是在網頁和JavaScript文件下載後同執行階段一塊兒在網頁的加載和渲染過程當中來實施的，因此對它們的處理時間也有着很高的要求;

JavaScript引擎主要包括

• 編譯器:主要工做是將源代碼編譯成抽象語法樹，而後在某些引擎中還包含將抽象語法樹轉換成字節碼;
• 解釋器:在某些引擎中，解釋器主要是接受字節碼，解釋執行這個字節碼，而後也依賴來及回收機制等;
• JIT工具:一個可以可以JIT的工具，將字節碼或者抽象語法樹轉換成本地代碼;
• 垃圾回收器和分析工具:負責垃圾回收和收集引擎中的信息，幫助改善引擎的性能和功效;

JavaScriptCore引擎和V8引擎

WebKit中的JavaScript引擎

• 在WebKit項目中，最初只有JavaScriptCore引擎;在Blink還獨立出來以前，爲了支持不一樣的JavaScript引擎，WebKit設計了一套接口能夠切換使用不一樣的JavaScript引擎（事實上，這一接口會下降性能），因此，WebKit當時能夠支持兩種類型的JavaScript引擎，那就是JavaScriptCore引擎和V8引擎;二者都是基於WebKit所提供的接口來同渲染引擎協同工做;

  JavaScriptCore引擎

• JavaScriptCore引擎是WebKit中默認的引擎;
• 在早期階段，性能不是特別突出;特別是，它只有解釋器來解釋執行JavaScript代碼,這一效率十分的低效;
• 從2008年開始,JavaScriptCore引擎開始一個新的優化工做;

• JavaScriptCore最簡單的處理部分，主要是將源代碼翻譯成抽象語法樹，以後是平臺無關的字節碼，在最初的版本中，字節碼會被JavaScriptCore引擎解釋執行;在後面的版本中，逐漸加入了JIT編譯器，將熱點函數生成本地代碼;

V8引擎

• 爲了達到高性能的JavaScript代碼執行效率從而得到更好的網頁瀏覽效果，它甚至採用直接將JavaScript編譯成本地代碼的方式;
• 首先它也是將源代碼轉變成抽象語法樹的，這一點同JavaScriptCore引擎同樣，以後兩個引擎開始不一樣；
• 不一樣於JavaScriptCore引擎，V8引擎並不將抽象語法樹轉變成字節碼或者其它中間表示，而是經過JIT編譯器的全代碼生成器從抽象語法樹直接生成本地代碼，因此沒有像Java同樣的虛擬機或者字節碼解釋器;
• 這樣作，主要是由於減小這抽象語法樹到字節碼的轉換時間，這一切都在網頁加載時候完成，雖然能夠提升優化的可能，可是這些分析可能帶來巨大的時間浪費;固然，缺點也很明顯，至少包括兩點：
  * 第一是某些JavaScript使用場景其實使用解釋器更爲合適，由於沒有必要生成本地代碼；
  * 第二是由於沒有中間表示，會減小優化的機會由於缺乏一箇中間表示層;
• 在以後的版本中，V8工程師們引入了Crankshaft編譯器，它可以對熱點的JS函數進行生成的分析和優化後再生成本地代碼，緣由在於不是全部的JavaScript代碼都合適作如此深層次的優化，由於優化自己也須要花費必定的時間;

Chromium網絡棧

概述

• 主要做用是使用網絡來下載各類類型的資源，還須要支持最新的HTML5功能WebSockets ;
• 爲了高效的網絡機制，Chromium使用了預DNS解析和資源預取等技術，極大的減小了用戶等待時間;
• Chromium又引入了SPDY和QUIC等新網絡協議，用於減小網絡傳輸時間;

調用棧

• 以HTTP協議爲例，在創建TCP的socket鏈接過程當中涉及的類;
• 首先是URLRequest被上層調用啓動請求的時候，它會根據URL的scheme來決定須要建立什麼類型的請求,例如http://，file://;還能夠是自定義的scheme，例如Android系統的file://assets/;
  * URLRequest建立的是一個URLRequestJob子類的一個對象,爲了支持自定義的scheme處理方式，它是利用工廠模式;基本的思路是，用戶能夠在該類中註冊多個工廠，當有URLRequest請求時候，先有工廠檢查它是否須要處理該scheme，若是沒有，繼續交由下一個工廠類;最後，若是沒有任何工廠可以處理的話，則交給內置的工廠來檢查和處理是不是http://，ftp://或者file://等;
• 其次，當URLRequestHttpJob被建立後，它首先從Cookie管理器中獲取跟該URL相關聯的信息;以後，一樣藉助於HttpTransactionFactory建立一個HttpTransaction類的對象來表示開啓一個HTTP鏈接的事務（不一樣於數據庫中的事務概念;
  * HttpCache類使用本地磁盤緩存機制，若是該請求對應的回覆已經在磁盤緩存中，那麼無需再創建HttpTransaction來發起鏈接，直接從磁盤中獲取;
  * 若是磁盤中沒有，同時若是目前該URL請求對應的HttpTransaction已經創建，那麼只要等待它的回覆便可;
  * 這些條件都不知足後，實際上纔會真正建立HttpTransaction;
• 而後，HttpNetworkTransaction使用HttpNetworkSession來管理鏈接會話;
  • HttpNetworkSession經過它的成員HttpStreamFactory來創建TCP Socket鏈接;
  • 以後建立HttpStream對象;HttpStreamFactory將和網絡之間的數據讀寫交給本身新建立的一個HttpStream對象來處理;
• 最後，是套接字的創建;Chromium中的跟服務器創建鏈接的套接字是StreamSocket，它是一個抽象類;同時，爲了支持SSL機制，它還有一個子類就是SSLSocket;

SPDY

• 爲了解決HTTP管線化技術的網絡延遲和安全性問題;
• 使用SPDY協議的服務器和客戶端能夠將網絡加載的時間減小64%;在HTTP2.0的草案中引入SPDY協議做爲基礎來編寫;
• SPDY協議是一種新的會話層協議，它定義在HTTP協議和TCP協議之間;

• 協議的核心思想是多路複用，僅使用一個鏈接來傳輸一個網頁中的衆多資源;
  * 它本上並無改變HTTP協議，只是將HTTP協議頭經過SPDY來封裝和傳輸;
  * 其傳輸方式也沒有發生變化，而後使用TCP/IP協議;
  * 因此，它相對比較容易的佈置，服務器只須要插入SPDY協議的解釋層，從SPDY的消息頭中獲取各個資源的HTTP頭便可;
  * SPDY協議必須創建在SSL層之上，這是一個比較大的限制，由於有不少網站不必定但願支持HTTPS;

• SPDY的工做方式有如下四個特徵：
  * 利用一個TCP鏈接來傳輸不限個數的資源請求的讀寫流，這與以前的爲每一個資源請求都創建一個TCP鏈接大大不一樣，這明顯提升了TCP鏈接的利用率，減小TCP鏈接的維護成本;
  * 根據資源請求的特性和優先級，SPDY能夠調整它們的請求這些資源的優先級，例如對JavaScript資源的優先級很高，服務器優先傳輸回覆該類型的請求;
  * 對這些請求使用壓縮技術，大大減小須要傳送的字節數;這一思想已普遍應用於各類瀏覽器中;
  * 當用戶須要瀏覽某個網頁的時候，支持SPDY協議的服務器在發送網頁內容時候能夠嘗試發送一些信息給瀏覽器，告訴後面可能須要哪些資源，瀏覽器能夠提早知道並決定是否須要下載;更極端的狀況是，服務器能夠主動發送資源;