導航渲染流程

通過這篇文章當你被問到從URL輸入到頁面展示都發生了什么的時候，基本都能對答如流，甚至可以一直深入的說，說到面試官閉麥哈哈哈~

以下是本文的思維導圖，直接拿圖「點個贊」再走吧 ~ 求求了 ???

(手機端可能看不清)獲取高清PDF，請在微信公眾號【小獅子前端Vue】回復【導航渲染流程】

從輸入到頁面渲染這個過程其實可以說得非常復雜，我這里總結的只是我通過在某網站上學習的課程【瀏覽器】所總結出來的，包括了兩大步驟，一個是導航流程另一個是渲染流程；

---

一、導航流程

1.用戶輸入URL

不考慮用戶輸入搜索關鍵字的情況， 如果用戶輸入的內容符合URL規則，瀏覽器就會根據URL協議，在這段內容上加上協議合成合法的URL

2.loading狀態

用戶輸入完內容，按下回車鍵，瀏覽器導航欄顯示loading狀態，但是頁面還是呈現前一個頁面，這是因為新頁面的響應數據還沒有獲取到。

3.瀏覽器請求

瀏覽器進程瀏覽器構建請求行信息，會通過進程間通信(IPC)將URL請求發送給網絡進程

GET?/index.html?HTTP1.1

4.網絡進程處理

網絡進程接收到url請求后檢查本地緩存是否緩存了該請求資源：

• 如果有緩存文件
  • 攔截請求，直接200返回
• 無緩存文件
  • 進入網絡請求過程

請求DNS(返回對應IP端口)

• 緩存過當前域名信息
  • 直接返回緩存信息
• 未緩存
  • 發起請求獲取根據域名解析出來的IP和端口號

5.TCP三次握手建立連接

Chrome 有個機制，同一個域名同時最多只能建立 6 個TCP 連接，如果在同一個域名下同時有 10 個請求發生，那么其中 4 個請求會進入排隊等待狀態，直至進行中的請求完成。如果當前請求數量少于6個，會直接建立TCP連接。

TCP三次握手建立連接，http請求加上TCP頭部——包括源端口號、目的程序端口號和用于校驗數據完整性的序號，向下傳輸http請求加上TCP頭部向下傳輸三次握手建立連接詳細過程

6.數據傳輸過程

「網絡層、傳輸層」在數據包上加上IP頭部，繼續向下傳輸到底層，底層通過物理網絡傳輸給目的服務器主機

• [ ] 網絡層在數據包上加上IP頭部——包括源IP地址和目的IP地址，繼續向下傳輸到底層

「目的服務器主機」

• 網絡層，解析出IP頭部，識別出數據部分
• 傳輸層獲取到數據包，解析出TCP頭部，識別端口

「應用層HTTP解析請求頭和請求體」應用層HTTP解析請求頭和請求體，如果需要重定向，HTTP直接返回HTTP響應數據的狀態code301或者302，同時在請求頭的Location字段中附上重定向地址，瀏覽器會根據code和Location進行重定向操作；

如果不是重定向，首先服務器會根據 請求頭中的If-None-Match 的值來判斷請求的資源是否被更新，如果沒有更新，就返回304狀態碼，相當于告訴瀏覽器之前的緩存還可以使用，就不返回新數據了；

否則，返回新數據，200的狀態碼，并且如果想要瀏覽器緩存數據的話，就在相應頭中加入字段：Cache-Control:Max-age=2000

• 重定向 HTTP直接返回HTTP響應數據的狀態code301或者302同時在請求頭的Location字段中附上重定向地址
• 不是重定向If-None-Match,沒有更新，就返回304狀態碼;否則，返回新數據，200的狀態碼Cache-Control,想要瀏覽器緩存數據

「響應數據」又順著應用層——傳輸層——網絡層——網絡層——傳輸層——應用層的順序返回到「網絡進程」

7.傳輸完成，TCP四次揮手

8.網絡進程(數據包解析)

「Content-type」

網絡進程將獲取到的數據包進行解析，根據響應頭中的Content-type來判斷響應數據的類型

• 如果是字節流類型，就將該請求交給下載管理器，該導航流程結束，不再進行

• 如果是text/html類型，就通知瀏覽器進程獲取到文檔準備渲染

9.渲染進程(渲染進程的主進程)

瀏覽器會發出“提交文檔”的消息給渲染進程，渲染進程收到消息后，會和網絡進程建立傳輸數據的“管道”，文檔數據傳輸完成后，渲染進程會返回“確認提交”的消息給瀏覽器進程

• 網絡進程建立傳輸數據的“管道”
• 確認提交給瀏覽器進程

10.瀏覽器(更新頁面狀態)

瀏覽器收到“確認提交”的消息后，會更新瀏覽器的頁面狀態，包括了安全狀態、地址欄的 URL、前進后退的歷史狀態，并更新web頁面，此時的web頁面是空白頁

此時的web頁面是空白頁，以下列舉了三種狀態更新

• 安全狀態
• 地址欄的 URL
• 前進后退的歷史狀態

二、渲染流程(可以看成步驟9的補充)

導航被提交后又會怎么樣呢？就進入了渲染階段。

主線程

1.DOM樹

HTML通過HTML解析器解析輸出DOM樹。下面的HTML代碼會被解析成上面這種瀏覽器可以理解的DOM樹結構：

2.Style樣式計算

• 把 CSS 轉換為瀏覽器能夠理解的結構--「styleSheets」。這里一CSDN為例可以看到它最新的styleSheets，會包含引用的外部 CSS 文件、標記內的 CSS、以及內嵌的 CSS；

• 標準化樣式表屬性值 將所有值轉換為渲染引擎容易理解的、標準化的計算值，這個過程就是屬性值標準化。 1em 被解析成 1px，red 被解析成了 rgb(255,0,0)等等。

• 計算 DOM 樹每個節點的具體樣式 最終的樣式可以通過控制臺element的Computed查看，關于是怎么計算，涉及繼承規則和層疊規則，這里就不細講了。

3.Layout 布局樹

• 創建布局樹：遍歷 DOM 樹中的所有可見節點，加到布局樹中。對display：none的就忽略不加。
• 布局計算：計算布局樹節點的坐標位置。

4.layer 圖層繪制列表

瀏覽器的頁面實際上被分成了很多圖層，這些圖層疊加后合成了最終的頁面。通常情況下，并不是布局樹的每個節點都包含一個圖層，如果一個節點沒有對應的層，那么這個節點就從屬于父節點的圖層。

進入Layer頁面，操作按鈕從左至右功能依次為：平移、旋轉、復位。見圖：

5.Pain 圖層繪制

可以想象你畫畫，先畫遠處再畫近處，圖層繪制也是這種原理。圖層繪制階段，輸出待繪制列表。

合成線程

6.柵格化(tiles圖塊、raster光柵化)

在有些情況下，有的圖層很大，但是通過視口，用戶只能看到頁面的很小一部分，所以在這種情況下，要繪制所有圖層內容的話，就會產生太大的開銷，而且也沒有必要。

也是因為這個原因，合成線程會將圖層進行分塊劃分為「圖塊」然后再「柵格化」，將圖塊轉換為位圖，而渲染進程通常不做或者做不來格柵化，需要跨進程，使用 GPU 來加速生成，使用 GPU 生成位圖的過程叫快速柵格化，或者 GPU 柵格化，生成的位圖被保存在 GPU 內存中。

7.Display 合成和顯示

圖塊都被光柵化，合成線程就會生成一個繪制圖塊的命令——“「DrawQuad」”提交給瀏覽器進程。

瀏覽器進程接收 DrawQuad 命令，根據 DrawQuad 命令，將其頁面內容繪制到內存中，最后再將內存顯示在屏幕上。

至此頁面就被渲染出來了~~完結撒花???

---

渲染流程總結

貼心的我又對上述難理解的知識做了總結，并且還準備了圖，確定不點個贊??支持一下嘛~

渲染頁面主要做的事：

• 1.將瀏覽器無法直接理解和使用的HTML，轉換為瀏覽器能夠理解的結構--「DOM 樹」。
• 2.把 CSS 轉換為瀏覽器能夠理解的結構--「styleSheets」，并轉換樣式表中的屬性值，使其標準化，計算出 DOM 樹中每個節點的具體樣式(根據繼承規則和層疊規則)。
• 3.確定DOM 元素的幾何位置信息--「布局樹」，遍歷 DOM 樹中的所有可見節點，加入到布局樹(display：none不包含)，并計算布局樹節點的坐標位置。
• 4.如果頁面有復雜的效果，如常見的頁面滾動，或者使用 z 軸排序等，為了更加方便地實現這些效果，渲染引擎還需要為特定的節點生成專用的圖層，并生成一棵對應的「圖層樹」(LayerTree)。
• 5.圖層繪制，把一個圖層的繪制拆分成很多小的繪制指令，然后再把這些指令按照順序組成一個「待繪制列表」(聯想自己畫畫)。
• 6.tiles：將圖層轉換成圖塊。
• 7.光柵化：通過進程實現圖塊轉換成位圖。
• 8.display：瀏覽器進程拿到DrawQuad信息生成頁面顯示。

DOM 和 HTML 內容幾乎是一樣的，但是和 HTML 不同的是，DOM 是保存在內存中樹狀結構，可以通過 JavaScript 來查詢或修改其內容。

貼心的我也為你們做了一張圖：

總結

以上是生活随笔為你收集整理的html将页面分成三块_导航渲染流程你真的知道从输入URL到页面展示发生了什么吗？（内附思维导图）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。