Electron Webview Pool（上）：為什麼開一個 webview 要 1.3 秒？從 Chromium 多進程講起

桌面交易應用裡每一個分頁底下都掛著一個 webview，使用者點切換要等 1.3 秒才看到內容——體驗已經輸了。要解這個問題，得先知道這 1.3 秒到底花在哪裡。這篇從 Electron 的多進程模型講起，把 webview 跟它的兄弟（BrowserWindow、WebContentsView）擺在一起比較，最後解釋為什麼 1.3 秒裡有 700 ms 是可以提前燒掉的。下篇接著拆 IPC 跟 Pool 的實作。內部使用。

#electron#chromium#webview#multi-process#performance#binance#interview-prep#面試系列#private

桌面交易應用裡每一個分頁底下都掛著一個 webview，使用者點切換的瞬間如果要等 1.3 秒才看到內容，那體驗已經輸了。當時的解法是 Webview Pool——預先燒掉建立 webview 的成本，把使用者實際感受到的延遲壓到 0.7 秒。

整個故事很長，分成上下兩篇：

本篇（上）：講「為什麼這麼慢」。先拆 1.3 秒花在哪裡，再講 Electron 的多進程模型（renderer / main / utility 是什麼、<webview> 跟 BrowserWindow 在這張圖裡是什麼角色），最後比較四種容器（BrowserWindow / BrowserView / WebContentsView / <webview>）該怎麼選。
下篇：Webview Pool（下）：三段 IPC、Pool 實作與一籮筐踩過的雷。講 main ↔ renderer ↔ webview 三段通訊怎麼接、Pool 怎麼設計、會踩什麼坑。

當查閱手冊用——遇到對應問題直接跳區段。