← All notes
Electron Webview Pool（下）：三段 IPC、Pool 實作與一籮筐踩過的雷
上篇講了 webview 為什麼慢。這篇接著拆 main ↔ renderer ↔ webview 三段 IPC 怎麼接、Pool 的程式碼長什麼樣、為什麼 `about:blank` 預載比直接載真實 URL 聰明、partition 怎麼決定資料隔離邊界、preload 為什麼必須 idempotent、`dom-ready` 跟 `did-finish-load` 該等哪一個——還有記憶體 tradeoff 的真實數字。內部使用。
承接上篇——我們知道 webview 為什麼慢（1.3 秒裡有 700 ms 是 process fork + V8 init + Blink 暖機 + preload 執行，跟使用者的 URL 無關），知道 webview 在 Electron 多進程模型裡的位置（每個 webview = 一個獨立 renderer process），知道它的優缺點跟替代方案。
這篇講「怎麼解」。順序：
- 三段 IPC：main、host renderer、guest webview 之間的通訊路徑。Pool 管理層要知道訊息怎麼跑，才能決定誰拿 reference、誰負責中繼。
- Pool 實作：spawn、acquire、release、warm 四個動作的程式碼，加上幾個關鍵設計決策（
about:blank預載、dom-ready訊號、MIN/MAX 雙閾值）。 - 常見地雷：partition 共用洩漏、preload 重複註冊、dirty state 殘留、crash 自我修復、z-index、keyboard / focus / SSL。
- 記憶體 tradeoff：Pool 換來的速度代價是多少 RAM，怎麼按機種決定 pool size。