秒開率從 18% 到 64%，我們對小程序模擬器做了什么？ 原創(chuàng)
小程序是一種運行在快手生態(tài)內(nèi)，無需下載安裝、即用即走的輕量級應(yīng)用。其中，模擬器是快手開發(fā)者所使用的工具中最核心的模塊之一，但因性能問題收到開發(fā)者反饋。為此，24 年 Q2 快手啟動了模擬器性能優(yōu)化專項，從線上數(shù)據(jù)看：模擬器秒開率從 18%提升至 64%，F(xiàn)CP P90 從 4.4s 提升至 1.9s。本文詳細(xì)介紹優(yōu)化措施和成效。
一、問題背景
小程序是快手開放平臺對外提供的開放能力之一， 是一種運行在快手生態(tài)內(nèi)，無需下載安裝、即用即走的輕量級應(yīng)用。開發(fā)者以快手小程序為載體，以優(yōu)質(zhì)的內(nèi)容、服務(wù)供給或內(nèi)容生產(chǎn)連接用戶。小程序接入流程可簡單劃分為四步：注冊小程序、開發(fā)調(diào)試、審核上線、線上運營。其中開發(fā)調(diào)試工作主要在快手開發(fā)者工具上進行，而模擬器是快手開發(fā)者工具最核心的模塊之一。
由于小程序不能直接使用瀏覽器環(huán)境運行，我們在開發(fā)者工具中提供了模擬器模塊，模擬小程序在快手客戶端的表現(xiàn)。
模擬器是快手開發(fā)者工具中開發(fā)者使用頻率最高的模塊，最常見的使用場景是：修改代碼=>觸發(fā)編譯=>模擬器刷新=>查看效果，模擬器的加載速度直接影響開發(fā)者的開發(fā)效率。
從線上數(shù)據(jù)看，模擬器性能確實比較差：FCP P90 只有 4.4s，秒開率只有 18%，開發(fā)者也多次反饋期望優(yōu)化模擬器的性能。
注：本文提到的 FCP 指編譯完成后模擬器收到刷新事件，到小程序首次內(nèi)容渲染所花的時間，秒開率指在 1 秒內(nèi)完成 FCP 的比例。
二、分析解決
對于性能優(yōu)化，常見思路是：理清各階段耗時->找出耗時原因->制定相應(yīng)優(yōu)化方案。第一步，我們先要統(tǒng)計各階段耗時。
2.1 如何統(tǒng)計模擬器啟動各階段耗時？
對于常規(guī)前端項目，很容易想到使用 performance 錄制火焰圖來分析耗時，但小程序模擬器比較特殊，無法使用 performance 錄制。
2.1.1 為什么模擬器不能使用 performance 錄制
快手小程序采用了雙線程架構(gòu)，分為邏輯層與渲染層。在模擬器中，渲染層使用 Electron Webview（獨立進程）承載，一個頁面對應(yīng)一個 iframe；邏輯層使用 Electron BrowserView（獨立進程）承載。
因為執(zhí)行信息分布在兩個進程中，但調(diào)試器 performance 錄制的只能對接一個進程，這導(dǎo)致了不能直接使用 performance 錄制功能，所以只能先在代碼中手動打點來記錄啟動時各階段耗時。
2.2 手動打點分析，確定主要優(yōu)化方向
通過在代碼中手動打點，我們觀察到容器準(zhǔn)備階段的耗時比較長，再加上不能用 performance 錄制，無法細(xì)致的統(tǒng)計加載執(zhí)行階段中的耗時，所以一開始我們優(yōu)先考慮優(yōu)化容器準(zhǔn)備階段耗時。
2.2.1 優(yōu)化容器準(zhǔn)備階段耗時
雙進程改為單進程：
在當(dāng)前的模擬器方案中，每次模擬器刷新，都需要銷毀并重建邏輯層容器，重新加載框架文件以及基礎(chǔ)庫（因為需要重新加載基礎(chǔ)庫、執(zhí)行用戶代碼，重新走一遍小程序的生命周期），這些操作耗費了比較多的時間。我們的優(yōu)化思路是盡可能減少需要重新加載執(zhí)行的資源（進程資源、文件資源），有三個方案：
三個方案運行邏輯簡述如下：
BrowserView + IFrame：
webworker:
IFrame：
綜合評估：計劃采用 IFrame 方案。
- 從內(nèi)存占用、可移植性來看，webworker、IFrame 方案比較好；
- IFrame 刷新速度略快于 webworker，webworker 運行時性能更好：
- webworker 方案會新開一個線程，運行時性能優(yōu)與 IFrame，但由于是在 PC 端，單線程帶來性能影響比起在移動端更小，也能接受。
- 模擬器主要場景是刷新看效果，而不是操作使用模擬器中的小程序，所以刷新速度比運行時性能優(yōu)先級更高
- 從時間成本看，IFrame 方案更小，且改動點在能夠被 webworker 復(fù)用，后期即便考慮 webworker 方案也能成本也更小一些。
將邏輯層通過一個 IFrame 來承載，并且將其至于模擬器容器進程下，與頁面 IFrame 同級，這樣就可以拿掉一個進程，并且得益于同源特性，IFrame 還可以復(fù)用父進程的線程資源，刷新速度會更快。
模塊緩存復(fù)用：
由于邏輯層、渲染層調(diào)整后變成了同級的 IFrame，可以共享 parent window，在此基礎(chǔ)上，我們可以將邏輯 / 渲染層框架文件一些比較獨立的、業(yè)務(wù)無關(guān)的功能模塊提取至父容器里面，通過 parent window 調(diào)用，以降低框架文件包體積，提升加載速度。
2.3 performance 錄制統(tǒng)計更精細(xì)耗時
模擬器改為單進程后帶來另一個好處是能夠使用調(diào)試器的 performance 錄制功能了，因為渲染層跟邏輯層改成了 IFrame 來承載，處于同一個進程中，執(zhí)行信息可以由調(diào)試器直接采集到。
2.3.1 編譯產(chǎn)物優(yōu)化為按需加載
通過觀察火焰圖，發(fā)現(xiàn)模擬器在啟動時就將小程序代碼中所有頁面的編譯產(chǎn)物加載了，這一段邏輯耗費了比較多的時間，但其實每次模擬器刷新并不需要把所有的頁面編譯產(chǎn)物都加載進來，只需加載當(dāng)前頁面所需編譯產(chǎn)物即可。
我們將編譯產(chǎn)物調(diào)整為了按需加載：當(dāng)基礎(chǔ)庫需要執(zhí)行對應(yīng)編譯產(chǎn)物時再去加載。加載方式也由之前的 script 標(biāo)簽異步加載，替換成了 readFileSync + eval（基礎(chǔ)庫限制只能使用同步方式加載），readFileSync 讀取文件內(nèi)容，eval 完成加載。
但調(diào)整為按需加載之后，發(fā)現(xiàn)了一個新的問題：如果斷點所指向代碼的執(zhí)行時機比較靠前（如 onLoad 階段），則有可能導(dǎo)致斷點失效。
為什么斷點失效了？
經(jīng)過 debug，發(fā)現(xiàn)斷點失效跟編譯產(chǎn)物的加載方式有關(guān)。原先使用 script 標(biāo)簽加載，調(diào)試器可以將代碼與 script 標(biāo)簽的 src 地址指向文件直接關(guān)聯(lián)上，而優(yōu)化后使用了 eval，無法直接將代碼與文件關(guān)聯(lián)上，從而導(dǎo)致斷點失效。
全量加載（優(yōu)化前）：
斷點設(shè)置流程：第一次收到路由事件后先使用 script 標(biāo)簽全量加載所有頁面編譯產(chǎn)物，調(diào)試器根據(jù) script src 屬性指向的文件路徑找到并通知內(nèi)核設(shè)置斷點。
加載流程：
按需加載（優(yōu)化后）:
斷點設(shè)置流程：eval 加載執(zhí)行代碼時，調(diào)試器開始解析 sourcemap，解析完成后通知內(nèi)核設(shè)置斷點。
加載流程：
但我們還發(fā)現(xiàn)一個現(xiàn)象是：如果斷點指向代碼執(zhí)行時機比較靠后，則可以斷點成功。這是因為編譯產(chǎn)物文件中有 sourcemap，sourcemap 解析完成后調(diào)試器也能將 eval 的代碼跟對應(yīng)文件關(guān)聯(lián)上，找到對應(yīng)文件相關(guān)斷點并通知內(nèi)核設(shè)置斷點，所以此時能斷點成功。
通過 #sourceURL 解決
問題主要原因在于，調(diào)試器無法在一開始將 eval 的代碼與源文件關(guān)聯(lián)上，雖然 sourcemap 解析完也能關(guān)聯(lián)上，但 sourcemap 解析是耗時的，也就導(dǎo)致了調(diào)試器通知模擬器內(nèi)核設(shè)置斷點時，斷點指向代碼已經(jīng)執(zhí)行過了，導(dǎo)致斷點不生效，所以不能完全依賴 sourcemap。
有沒有辦法不依賴 sourcemap 的情況下能讓 eval 與源文件直接關(guān)聯(lián)上？我們在 Chrome 官方文檔中找到了 #sourceURL 這個配置：
通過這個配置可以讓調(diào)試器將 eval 的代碼跟文件直接關(guān)聯(lián)上，無需等待解析 sourcemap 完成，即可直接根據(jù) sourceURL 配置查找并通知內(nèi)核設(shè)置斷點。
所以我們給源碼加上了 #sourceURL 注釋再進行 eval。
優(yōu)化后的斷點設(shè)置流程：
2.4 performance 錄制為什么會影響模擬器性能？
在使用 performance 錄制功能時，發(fā)現(xiàn)開啟錄制狀態(tài)下模擬器的啟動速度要快一些。
經(jīng)過實測，performance 錄制確實讓模擬器啟動速度變快了，且差距明顯。
考慮到調(diào)試器與模擬器主要是通過 CDP 消息進行交互，我推測是開啟錄制后某條 CDP 消息導(dǎo)致了模擬器性能大幅提升。
2.4.1 CDP 是什么？
CDP 全稱是 Chrome DevTools Protocol，是供 Chrome Devtools 使用的一個協(xié)議，簡單說下 Chrome Devtools 的原理：
- 加載一個 web 頁面時，瀏覽器會為該頁面起一個 Websocket Server，在打開這個頁面的 Devtools 時與該 Server 建立 Websocket 連接，以這種方式實現(xiàn)通信。
- 在某些關(guān)鍵事件發(fā)生時（如網(wǎng)絡(luò)請求，用戶調(diào)用 console api），瀏覽器內(nèi)核會向 devtools 發(fā)送 CDP 消息；devtools 也可以向瀏覽器內(nèi)核發(fā)送消息，來命令頁面執(zhí)行某些操作(如在 console 面板中輸入代碼并執(zhí)行)。二者之間的通信遵循 Chrome Devtool Porotol。
一條 CDP 消息示例
2.4.2 開啟 performance 錄制后，調(diào)試器對模擬器做了什么？
我們可以通過 Protocol Monitor 面板看到開啟錄制后調(diào)試器往模擬器發(fā)送了哪些 CDP 消息（圖中紅框部分，大多是 xx.disable：禁用某些功能）
簡單的方法是將這些消息直接挨個攔截測試一下就能知道哪些消息提升了性能，不過由于這里用的是 Electron Webview 自帶的原生調(diào)試器，沒辦法直接攔截原生調(diào)試器發(fā)送至模擬器內(nèi)核的 CDP 消息，還是需要從開發(fā)者工具自己實現(xiàn)的調(diào)試器入手。
但開發(fā)者工具中的調(diào)試器未實現(xiàn) performance 功能，所以也不能直接測試。我嘗試將開發(fā)者工具中調(diào)試器與原生調(diào)試器都關(guān)閉后，模擬器性能達到了開啟 performance 錄制后的效果，這能得出一個結(jié)論是「模擬器性能下降是由開發(fā)者工具調(diào)試器造成的」。
2.4.3 優(yōu)化調(diào)試器相關(guān)邏輯
經(jīng)過調(diào)試，我們發(fā)現(xiàn)可以對調(diào)試器的部分 CDP 消息做相關(guān)優(yōu)化：對一些在啟動階段用不上的調(diào)試器功能，先暫時關(guān)閉（緩存相關(guān) CDP 消息），等實際用到對應(yīng)功能或模擬器加載完成時再打開（發(fā)送所有緩存消息），來達到提升模擬器加載速度的效果。
最終方案如下圖所示：
出于穩(wěn)定性考慮，我們也為這個優(yōu)化加了開關(guān)
三、總結(jié)
本文介紹了我們在對模擬器進行性能優(yōu)化過程中，做了哪些事情。首先通過手動打點分析耗時，確定了主要優(yōu)化方向，將模擬器的雙進程架構(gòu)改成了單進程架構(gòu)。在單進程架構(gòu)下，通過增加緩存復(fù)用層，進一步提升了加載速度。同時單進程架構(gòu)也使得我們可以使用 performance 錄制工具進行更精細(xì)的耗時分析，針對性的對編譯產(chǎn)物做了按需加載優(yōu)化，并通過「#sourceURL 注釋」解決了斷點失效的問題。此外，我們也對調(diào)試器相關(guān)邏輯進行了優(yōu)化，并取得不錯的效果。
經(jīng)過本次優(yōu)化后，模擬器秒開率從 18%提升至 64%，F(xiàn)CP P90 從 4.4s 提升至 1.9s，在開發(fā)者滿意度調(diào)研中也獲得了好評。模擬器的性能與開發(fā)者體驗、開發(fā)效率息息相關(guān)，而提高開發(fā)者的開發(fā)體驗與開發(fā)效率，是我們團隊的首要任務(wù)。未來，我們將繼續(xù)努力，不斷優(yōu)化和完善模擬器的各項功能，為開發(fā)者提供更好的支持。
