前言
作為一名前端er，日常工作打交道最多（之一）的莫過于熟悉而又陌生的瀏覽器了，熟悉是每天都會基于瀏覽器的應用層面之上碼業務，陌生是很多人可能跟我一樣不熟悉其內部運行原理，比如js是怎樣運行的呢？精美樣式頁面是怎樣渲染到電腦屏幕的呢？在開放的互聯網它又是怎樣保證我們個人信息安全的呢？帶著種種疑云開始肝李兵老師的《瀏覽器基本原理與實踐》，下面就（非常非常）簡單總結一下。
Chrome 架構：僅僅打開了 1 個頁面，為什么有 4 個進程
線程和進程區別：
多線程可以并行處理任務，線程不能單獨存在，它是由進程來啟動和管理的。一個進程是一個程序的運行實例。
線程和進程的關系：
1、進程中任意一線程執行出錯，都會導致整個進程的崩潰。
2、線程之間共享進程中的數據。
3、當一個進程關閉后，操作系統會回收進程所占用的內存。
4、進程之間的內容相互隔離。
單進程瀏覽器：
1、不穩定。單進程中的插件、渲染線程崩潰導致整個瀏覽器崩潰。
2、不流暢。腳本（死循環）或插件會使瀏覽器卡頓。
3、不安全。插件和腳本可以獲取到操作系統任意資源。
多進程瀏覽器：
1、解決不穩定。進程相互隔離，一個頁面或者插件崩潰時，影響僅僅時當前插件或者頁面，不會影響到其他頁面。
2、解決不流暢。腳本阻塞當前頁面渲染進程，不會影響到其他頁面。
3、解決不安全。采用多進程架構使用沙箱。沙箱看成時操作系統給進程上來一把鎖，沙箱的程序可以運行，但是不能在硬盤上寫入任何數據，也不能在敏感位置讀取任何數據。
多進程架構：
分為 瀏覽器進程、渲染進程、GPU 進程、網絡進程、插件進程。
缺點：
1、資源占用高。
2、體系架構復雜。
面向服務架構：
把原來的各種模塊重構成獨立的服務，每個服務都可以在獨立的進程中運行，訪問服務必須使用定義好的接口，通過 IPC 通訊，使得系統更內聚、松耦合、易維護和拓展。
TCP 協議：如何保證頁面文件能被完整送達瀏覽器HTTP 請求流程：為什么很多站點第二次打開速度會很快導航流程：從輸入 URL 到頁面展示這中間發生了什么
網絡進程解析響應流程：
準備渲染進程
傳輸數據、更新狀態
渲染流程（上）：HTML、CSS 和 是如何變成頁面的渲染流程（下）：HTML、CSS 和 是如何變成頁面的變量提升： 代碼是按順序執行的嗎調用棧：為什么 代碼會出現棧溢出塊級作用域：var 缺陷以及為什么要引入 let 和 const作用域鏈和閉包：代碼中出現相同的變量， 引擎如何選擇this：從 執行上下文視角講 this
當執行 new 的時候， 引擎做了四件事：
this 的使用分為：
棧空間和堆空間：數據是如何存儲的
動態語言：在使用時需要檢查數據類型的語言。
弱類型語言：支持隱式轉換的語言。
中的 8 種數據類型，它們可以分為兩大類——原始類型和引用類型。
原始類型數據存放在棧中，引用類型數據存放在堆中。堆中的數據是通過引用與變量關系聯系起來的。
從內存視角了解閉包：詞法掃描內部函數，引用了外部函數變量，堆空間創建一個“closure”對象，保存變量。
垃圾回收：垃圾數據如何自動回收編譯器和解析器：V8 如何執行一段 代碼的消息隊列和事件循環：頁面是怎么活起來的webapi： 是怎么實現的webpai： 是怎么實現的宏任務和微任務：不是所有的任務都是一個待遇使用 Promise 告別回調函數
function?Bromise(executor)?{
??var?_onResolve?=?null
??this.then?=?function?(onResolve)?{
????_onResolve?=?onResolve
??}
??function?resolve(value)?{
????setTimeout(()?=>?{
??????_onResolve(value)
????},?0)
??}
??executor(resolve,?null)
}
async await 使用同步方式寫異步代碼頁面性能分析：利用 chrome 做 web 性能分析DOM 樹： 是如何影響 DOM 樹構建的渲染流水線：CSS 如何影響首次加載時的白屏時間？分層和合成機制：為什么 CSS 動畫比 高效頁面性能：如何系統優化頁面虛擬 DOM：虛擬 DOM 和真實 DOM 有何不同PWA：解決 web 應用哪些問題：像搭積木一樣構建 web 應用HTTP1：HTTP1 性能優化HTTP2：如何提升網絡速度HTTP3：甩掉 TCP、TCL 包袱，構建高效網絡同源策略：為什么 不能跨域請求跨站腳本攻擊 XSS：為什么 cookie 中有 屬性CSRF 攻擊：陌生連接不要隨便點沙盒：頁面和系統之間的隔離墻HTTPS：讓數據傳輸更安全