瀏覽器之基礎/緩存/渲染（問答）

目前準備到了瀏覽器這部分，加上以前面試過程當中，關於這部分的問題都答的不好，因此把一些自認爲有價值的知識點整理了出來。

---

什麼是跨域？爲何瀏覽器要使用同源策略？你有幾種方式能夠解決跨域問題？瞭解預檢請求嘛？

瀏覽器的同源策略致使了跨域，同源策略屬於瀏覽器的安全機制，若是協議、域名、端口有一個不一樣就是跨域，請求會失敗。
同源策略主要是用於防範CSRF攻擊的。簡單點說，CSRF 攻擊是利用用戶的登陸態發起惡意請求。
 
解決跨域的方法： JSONP/CORS/代理服務

1.JSONP

JSONP 的原理很簡單，就是利用 <script> 標籤沒有跨域限制的漏洞。經過 <script> 標籤指向一個須要訪問的地址並提供一個回調函數來接收數據當須要通信時。JSONP 使用簡單且兼容性不錯，可是隻限於 get 請求。

<script src="http://domain/api?param1=a&param2=b&callback=jsonp"></script>
<script>
    function jsonp(data) {
        console.log(data)
    }
</script>  

 
2.CORS

CORS 須要瀏覽器和後端同時支持。瀏覽器會自動進行 CORS 通訊，實現 CORS 通訊的關鍵是後端。只要後端實現了 CORS，就實現了跨域。
服務端設置 Access-Control-Allow-Origin 就能夠開啓 CORS。 該屬性表示哪些域名能夠訪問資源，若是設置通配符則表示全部網站均可以訪問資源。
雖然CORS和前端沒什麼關係，可是須要知道經過這種方式解決跨域問題的話，發送的請求會分別爲簡單請求和複雜請求。
對於複雜請求來講，首先會發起一個預檢請求，該請求是 option 方法的，經過該請求來知道服務端是否容許跨域請求。
 
3.代理
經過代理把前端請求的域名轉發到後端域名上，隱藏真實的服務端。可經過webpack或nigix實現。

---

有幾種方式能夠實現存儲功能，分別有什麼優缺點？什麼是 Service Worker？

cookie，localStorage，sessionStorage，indexDB皆可實現存儲

特性	cookie	localStorage	sessionStorage	indexDB
數據生命週期	通常由服務器生成，能夠設置過時時間	除非被清理，不然一直存在	頁面關閉	除非被清理，不然一直存在
數據存儲大小	4K	5M	5M	無限

 

對cookie使用時須要注意安全性

屬性	做用
value	若是用於保存用戶登陸態，應該將該值加密，不能使用明文的用戶標識
http-only	不能經過 JS 訪問 Cookie，減小 XSS 攻擊
secure	只能在協議爲 HTTPS 的請求中攜帶
same-site	規定瀏覽器不能在跨域請求中攜帶 Cookie，減小 CSRF 攻擊

 
 
Service Worker 是運行在瀏覽器背後的獨立線程，通常能夠用來實現緩存功能。使用 Service Worker的話，傳輸協議必須爲 HTTPS。由於 Service Worker 中涉及到請求攔截，因此必須使用 HTTPS 協議來保障安全。實現緩存功能通常分爲三個步驟：

• 首先須要先註冊 Service Worker，
• 而後監聽到 install 事件之後就能夠緩存須要的文件，
• 在下次用戶訪問的時候就能夠經過攔截請求的方式查詢是否存在緩存，存在緩存的話就能夠直接讀取緩存文件，不然就去請求數據。

---

事件的觸發過程是怎麼樣的？知道什麼是事件代理嘛？

 

事件觸發有三個階段：

1. window 往事件觸發處傳播，遇到註冊的捕獲事件會觸發
2. 傳播到事件觸發處時觸發註冊的事件
3. 從事件觸發處往 window 傳播，遇到註冊的冒泡事件會觸發

 
通常來講，若是咱們只但願事件只觸發在目標上，這時候可使用 stopPropagation 來阻止事件的進一步傳播。
 
事件代理
若是一個節點中的子節點是動態生成的，那麼子節點須要註冊事件的話應該註冊在父節點上
事件代理的方式相較於直接給目標註冊事件來講，由於不須要給子節點註銷事件，因此節省了內存。

---

瀏覽器緩存機制

 
對於一個數據請求來講，能夠分爲發起網絡請求、後端處理、瀏覽器響應 三個步驟。瀏覽器緩存能夠幫助咱們在第一和第三步驟中優化性能。好比說直接使用緩存而不發起請求，或者發起了請求但後端存儲的數據和前端一致，那麼就沒有必要再將數據回傳回來，這樣就減小了響應數據。
 
接下來的內容中咱們將經過如下幾個部分來探討瀏覽器緩存機制：
 
緩存位置：Service Worker > Memory Cache > Disk Cache > Push Cache > 網絡請求，以上表示優先級從大到小排序。

緩存策略: 強緩存和協商緩存，而且緩存策略都是經過設置 HTTP Header 來實現的。不細說了，至今還沒人問過。

實際場景應用緩存策略:
對於頻繁變更的資源：首先須要使用 Cache-Control: no-cache 使瀏覽器每次都請求服務器，而後配合 ETag 或者 Last-Modified 來驗證資源是否有效。這樣的作法雖然不能節省請求數量，可是能顯著減小響應數據大小。
 
對於代碼文件：如今都會使用工具來打包代碼，那麼咱們就能夠對文件名進行哈希處理，只有當代碼修改後纔會生成新的文件名。基於此，咱們就能夠給代碼文件設置緩存有效期一年 Cache-Control: max-age=31536000，這樣只有當 HTML 文件中引入的文件名發生了改變纔會去下載最新的代碼文件，不然就一直使用緩存。

目前還沒遇到面試官問這塊的知識點，性能優化方面仍是圍繞webpack聊的比較多。

---

瀏覽器渲染原理

不一樣的瀏覽器有不一樣的渲染引擎，這裏主要說的是Webkit渲染引擎。

當咱們打開一個網頁時，瀏覽器都會去請求對應的 HTML 文件。雖然平時咱們寫代碼時都會分爲 JS、CSS、HTML 文件，也就是字符串，可是計算機硬件是不理解這些字符串的，因此在網絡中傳輸的內容其實都是 0 和 1 這些字節數據。當瀏覽器接收到這些字節數據之後，它會將這些字節數據轉換爲字符串，也就是咱們寫的代碼。

當數據轉換爲字符串之後，瀏覽器會先將這些字符串經過詞法分析轉換爲標記（token），這一過程在詞法分析中叫作標記化（tokenization）。

那麼什麼是標記呢？簡單來講，標記仍是字符串，是構成代碼的最小單位。這一過程會將代碼分拆成一塊塊，並給這些內容打上標記，便於理解這些最小單位的代碼是什麼意思。

當結束標記化後，這些標記會緊接着轉換爲 Node，最後這些 Node 會根據不一樣 Node 以前的聯繫構建爲一顆 DOM 樹。

以上就是瀏覽器從網絡中接收到 HTML 文件而後一系列的轉換過程，過程大體以下：
字節數據 => 字符串 => 標記（Token） => Node => DOM
 
在解析 HTML 文件的時候，瀏覽器還會遇到 CSS 和 JS 文件，這時候瀏覽器也會去下載並解析這些文件，解析 CSS 文件的過程與HTML文件極爲相似，最後會生成一顆 CSSOM樹。
 
當咱們生成 DOM 樹和 CSSOM 樹之後，瀏覽器會將這兩棵樹組合爲渲染樹，而後根據渲染樹來進行佈局（也能夠叫作迴流），而後調用 GPU 繪製，合成圖層，顯示在屏幕上。

---

除此以外，還有些零碎的知識點，由於已經熟記於心就不作展開了，包括：
1.重繪（Repaint）和迴流（Reflow）
2.requestAnimationFrame API繪製動畫
3.操做 DOM 性能不好的緣由

前天拿到了一個offer，可是此次面試的體驗不好，崗位待遇也沒達到預期，三月繼續加油吧，祝我好運🍀