小程序是一種運(yùn)行在快手生態(tài)內(nèi)，無(wú)需下載安裝、即用即走的輕量級(jí)應(yīng)用。其中，模擬器是快手開(kāi)發(fā)者所使用的工具中最核心的模塊之一，但因性能問(wèn)題收到開(kāi)發(fā)者反饋。為此，24 年 Q2 快手啟動(dòng)了模擬器性能優(yōu)化專項(xiàng)，從線上數(shù)據(jù)看：模擬器秒開(kāi)率從 18%提升至 64%，F(xiàn)CP P90 從 4.4s 提升至 1.9s。本文詳細(xì)介紹優(yōu)化措施和成效。

一、問(wèn)題背景

小程序是快手開(kāi)放平臺(tái)對(duì)外提供的開(kāi)放能力之一， 是一種運(yùn)行在快手生態(tài)內(nèi)，無(wú)需下載安裝、即用即走的輕量級(jí)應(yīng)用。開(kāi)發(fā)者以快手小程序?yàn)檩d體，以優(yōu)質(zhì)的內(nèi)容、服務(wù)供給或內(nèi)容生產(chǎn)連接用戶。小程序接入流程可簡(jiǎn)單劃分為四步：注冊(cè)小程序、開(kāi)發(fā)調(diào)試、審核上線、線上運(yùn)營(yíng)。其中開(kāi)發(fā)調(diào)試工作主要在快手開(kāi)發(fā)者工具上進(jìn)行，而模擬器是快手開(kāi)發(fā)者工具最核心的模塊之一。

由于小程序不能直接使用瀏覽器環(huán)境運(yùn)行，我們?cè)陂_(kāi)發(fā)者工具中提供了模擬器模塊，模擬小程序在快手客戶端的表現(xiàn)。

模擬器是快手開(kāi)發(fā)者工具中開(kāi)發(fā)者使用頻率最高的模塊，最常見(jiàn)的使用場(chǎng)景是：修改代碼=>觸發(fā)編譯=>模擬器刷新=>查看效果，模擬器的加載速度直接影響開(kāi)發(fā)者的開(kāi)發(fā)效率。

從線上數(shù)據(jù)看，模擬器性能確實(shí)比較差：FCP P90 只有 4.4s，秒開(kāi)率只有 18%，開(kāi)發(fā)者也多次反饋期望優(yōu)化模擬器的性能。

注：本文提到的 FCP 指編譯完成后模擬器收到刷新事件，到小程序首次內(nèi)容渲染所花的時(shí)間，秒開(kāi)率指在 1 秒內(nèi)完成 FCP 的比例。

二、分析解決

對(duì)于性能優(yōu)化，常見(jiàn)思路是：理清各階段耗時(shí)->找出耗時(shí)原因->制定相應(yīng)優(yōu)化方案。第一步，我們先要統(tǒng)計(jì)各階段耗時(shí)。

2.1 如何統(tǒng)計(jì)模擬器啟動(dòng)各階段耗時(shí)？

對(duì)于常規(guī)前端項(xiàng)目，很容易想到使用 performance 錄制火焰圖來(lái)分析耗時(shí)，但小程序模擬器比較特殊，無(wú)法使用 performance 錄制。

2.1.1 為什么模擬器不能使用 performance 錄制

快手小程序采用了雙線程架構(gòu)，分為邏輯層與渲染層。在模擬器中，渲染層使用 Electron Webview（獨(dú)立進(jìn)程）承載，一個(gè)頁(yè)面對(duì)應(yīng)一個(gè) iframe；邏輯層使用 Electron BrowserView（獨(dú)立進(jìn)程）承載。

因?yàn)閳?zhí)行信息分布在兩個(gè)進(jìn)程中，但調(diào)試器 performance 錄制的只能對(duì)接一個(gè)進(jìn)程，這導(dǎo)致了不能直接使用 performance 錄制功能，所以只能先在代碼中手動(dòng)打點(diǎn)來(lái)記錄啟動(dòng)時(shí)各階段耗時(shí)。

2.2 手動(dòng)打點(diǎn)分析，確定主要優(yōu)化方向

通過(guò)在代碼中手動(dòng)打點(diǎn)，我們觀察到容器準(zhǔn)備階段的耗時(shí)比較長(zhǎng)，再加上不能用 performance 錄制，無(wú)法細(xì)致的統(tǒng)計(jì)加載執(zhí)行階段中的耗時(shí)，所以一開(kāi)始我們優(yōu)先考慮優(yōu)化容器準(zhǔn)備階段耗時(shí)。

2.2.1 優(yōu)化容器準(zhǔn)備階段耗時(shí)

雙進(jìn)程改為單進(jìn)程：

在當(dāng)前的模擬器方案中，每次模擬器刷新，都需要銷毀并重建邏輯層容器，重新加載框架文件以及基礎(chǔ)庫(kù)（因?yàn)樾枰匦录虞d基礎(chǔ)庫(kù)、執(zhí)行用戶代碼，重新走一遍小程序的生命周期），這些操作耗費(fèi)了比較多的時(shí)間。我們的優(yōu)化思路是盡可能減少需要重新加載執(zhí)行的資源（進(jìn)程資源、文件資源），有三個(gè)方案：

三個(gè)方案運(yùn)行邏輯簡(jiǎn)述如下：

BrowserView + IFrame：

webworker:

IFrame：

綜合評(píng)估：計(jì)劃采用 IFrame 方案。

• 從內(nèi)存占用、可移植性來(lái)看，webworker、IFrame 方案比較好；
• IFrame 刷新速度略快于 webworker，webworker 運(yùn)行時(shí)性能更好：

1. webworker 方案會(huì)新開(kāi)一個(gè)線程，運(yùn)行時(shí)性能優(yōu)與 IFrame，但由于是在 PC 端，單線程帶來(lái)性能影響比起在移動(dòng)端更小，也能接受。
2. 模擬器主要場(chǎng)景是刷新看效果，而不是操作使用模擬器中的小程序，所以刷新速度比運(yùn)行時(shí)性能優(yōu)先級(jí)更高

• 從時(shí)間成本看，IFrame 方案更小，且改動(dòng)點(diǎn)在能夠被 webworker 復(fù)用，后期即便考慮 webworker 方案也能成本也更小一些。

將邏輯層通過(guò)一個(gè) IFrame 來(lái)承載，并且將其至于模擬器容器進(jìn)程下，與頁(yè)面 IFrame 同級(jí)，這樣就可以拿掉一個(gè)進(jìn)程，并且得益于同源特性，IFrame 還可以復(fù)用父進(jìn)程的線程資源，刷新速度會(huì)更快。

模塊緩存復(fù)用：

由于邏輯層、渲染層調(diào)整后變成了同級(jí)的 IFrame，可以共享 parent window，在此基礎(chǔ)上，我們可以將邏輯 / 渲染層框架文件一些比較獨(dú)立的、業(yè)務(wù)無(wú)關(guān)的功能模塊提取至父容器里面，通過(guò) parent window 調(diào)用，以降低框架文件包體積，提升加載速度。

2.3 performance 錄制統(tǒng)計(jì)更精細(xì)耗時(shí)

模擬器改為單進(jìn)程后帶來(lái)另一個(gè)好處是能夠使用調(diào)試器的 performance 錄制功能了，因?yàn)殇秩緦痈壿媽痈某闪?IFrame 來(lái)承載，處于同一個(gè)進(jìn)程中，執(zhí)行信息可以由調(diào)試器直接采集到。

2.3.1 編譯產(chǎn)物優(yōu)化為按需加載

通過(guò)觀察火焰圖，發(fā)現(xiàn)模擬器在啟動(dòng)時(shí)就將小程序代碼中所有頁(yè)面的編譯產(chǎn)物加載了，這一段邏輯耗費(fèi)了比較多的時(shí)間，但其實(shí)每次模擬器刷新并不需要把所有的頁(yè)面編譯產(chǎn)物都加載進(jìn)來(lái)，只需加載當(dāng)前頁(yè)面所需編譯產(chǎn)物即可。

我們將編譯產(chǎn)物調(diào)整為了按需加載：當(dāng)基礎(chǔ)庫(kù)需要執(zhí)行對(duì)應(yīng)編譯產(chǎn)物時(shí)再去加載。加載方式也由之前的 script 標(biāo)簽異步加載，替換成了 readFileSync + eval（基礎(chǔ)庫(kù)限制只能使用同步方式加載），readFileSync 讀取文件內(nèi)容，eval 完成加載。

但調(diào)整為按需加載之后，發(fā)現(xiàn)了一個(gè)新的問(wèn)題：如果斷點(diǎn)所指向代碼的執(zhí)行時(shí)機(jī)比較靠前（如 onLoad 階段），則有可能導(dǎo)致斷點(diǎn)失效。

為什么斷點(diǎn)失效了？

經(jīng)過(guò) debug，發(fā)現(xiàn)斷點(diǎn)失效跟編譯產(chǎn)物的加載方式有關(guān)。原先使用 script 標(biāo)簽加載，調(diào)試器可以將代碼與 script 標(biāo)簽的 src 地址指向文件直接關(guān)聯(lián)上，而優(yōu)化后使用了 eval，無(wú)法直接將代碼與文件關(guān)聯(lián)上，從而導(dǎo)致斷點(diǎn)失效。

全量加載（優(yōu)化前）：

斷點(diǎn)設(shè)置流程：第一次收到路由事件后先使用 script 標(biāo)簽全量加載所有頁(yè)面編譯產(chǎn)物，調(diào)試器根據(jù) script src 屬性指向的文件路徑找到并通知內(nèi)核設(shè)置斷點(diǎn)。

加載流程：

按需加載（優(yōu)化后）:

斷點(diǎn)設(shè)置流程：eval 加載執(zhí)行代碼時(shí)，調(diào)試器開(kāi)始解析 sourcemap，解析完成后通知內(nèi)核設(shè)置斷點(diǎn)。

加載流程：

但我們還發(fā)現(xiàn)一個(gè)現(xiàn)象是：如果斷點(diǎn)指向代碼執(zhí)行時(shí)機(jī)比較靠后，則可以斷點(diǎn)成功。這是因?yàn)榫幾g產(chǎn)物文件中有 sourcemap，sourcemap 解析完成后調(diào)試器也能將 eval 的代碼跟對(duì)應(yīng)文件關(guān)聯(lián)上，找到對(duì)應(yīng)文件相關(guān)斷點(diǎn)并通知內(nèi)核設(shè)置斷點(diǎn)，所以此時(shí)能斷點(diǎn)成功。

通過(guò) #sourceURL 解決

問(wèn)題主要原因在于，調(diào)試器無(wú)法在一開(kāi)始將 eval 的代碼與源文件關(guān)聯(lián)上，雖然 sourcemap 解析完也能關(guān)聯(lián)上，但 sourcemap 解析是耗時(shí)的，也就導(dǎo)致了調(diào)試器通知模擬器內(nèi)核設(shè)置斷點(diǎn)時(shí)，斷點(diǎn)指向代碼已經(jīng)執(zhí)行過(guò)了，導(dǎo)致斷點(diǎn)不生效，所以不能完全依賴 sourcemap。

有沒(méi)有辦法不依賴 sourcemap 的情況下能讓 eval 與源文件直接關(guān)聯(lián)上？我們?cè)?Chrome 官方文檔中找到了 #sourceURL 這個(gè)配置：

通過(guò)這個(gè)配置可以讓調(diào)試器將 eval 的代碼跟文件直接關(guān)聯(lián)上，無(wú)需等待解析 sourcemap 完成，即可直接根據(jù) sourceURL 配置查找并通知內(nèi)核設(shè)置斷點(diǎn)。

所以我們給源碼加上了 #sourceURL 注釋再進(jìn)行 eval。

優(yōu)化后的斷點(diǎn)設(shè)置流程：

2.4 performance 錄制為什么會(huì)影響模擬器性能？

在使用 performance 錄制功能時(shí)，發(fā)現(xiàn)開(kāi)啟錄制狀態(tài)下模擬器的啟動(dòng)速度要快一些。

經(jīng)過(guò)實(shí)測(cè)，performance 錄制確實(shí)讓模擬器啟動(dòng)速度變快了，且差距明顯。

考慮到調(diào)試器與模擬器主要是通過(guò) CDP 消息進(jìn)行交互，我推測(cè)是開(kāi)啟錄制后某條 CDP 消息導(dǎo)致了模擬器性能大幅提升。

2.4.1 CDP 是什么？

CDP 全稱是 Chrome DevTools Protocol，是供 Chrome Devtools 使用的一個(gè)協(xié)議，簡(jiǎn)單說(shuō)下 Chrome Devtools 的原理：

• 加載一個(gè) web 頁(yè)面時(shí)，瀏覽器會(huì)為該頁(yè)面起一個(gè) Websocket  Server，在打開(kāi)這個(gè)頁(yè)面的 Devtools 時(shí)與該 Server 建立 Websocket 連接，以這種方式實(shí)現(xiàn)通信。
• 在某些關(guān)鍵事件發(fā)生時(shí)（如網(wǎng)絡(luò)請(qǐng)求，用戶調(diào)用 console api），瀏覽器內(nèi)核會(huì)向 devtools 發(fā)送 CDP 消息；devtools 也可以向?yàn)g覽器內(nèi)核發(fā)送消息，來(lái)命令頁(yè)面執(zhí)行某些操作(如在 console 面板中輸入代碼并執(zhí)行)。二者之間的通信遵循 Chrome Devtool Porotol。

一條 CDP 消息示例

2.4.2 開(kāi)啟 performance 錄制后，調(diào)試器對(duì)模擬器做了什么？

我們可以通過(guò) Protocol Monitor 面板看到開(kāi)啟錄制后調(diào)試器往模擬器發(fā)送了哪些 CDP 消息（圖中紅框部分，大多是 xx.disable：禁用某些功能）

簡(jiǎn)單的方法是將這些消息直接挨個(gè)攔截測(cè)試一下就能知道哪些消息提升了性能，不過(guò)由于這里用的是 Electron Webview 自帶的原生調(diào)試器，沒(méi)辦法直接攔截原生調(diào)試器發(fā)送至模擬器內(nèi)核的 CDP 消息，還是需要從開(kāi)發(fā)者工具自己實(shí)現(xiàn)的調(diào)試器入手。

但開(kāi)發(fā)者工具中的調(diào)試器未實(shí)現(xiàn) performance 功能，所以也不能直接測(cè)試。我嘗試將開(kāi)發(fā)者工具中調(diào)試器與原生調(diào)試器都關(guān)閉后，模擬器性能達(dá)到了開(kāi)啟 performance 錄制后的效果，這能得出一個(gè)結(jié)論是「模擬器性能下降是由開(kāi)發(fā)者工具調(diào)試器造成的」。

2.4.3 優(yōu)化調(diào)試器相關(guān)邏輯

經(jīng)過(guò)調(diào)試，我們發(fā)現(xiàn)可以對(duì)調(diào)試器的部分 CDP 消息做相關(guān)優(yōu)化：對(duì)一些在啟動(dòng)階段用不上的調(diào)試器功能，先暫時(shí)關(guān)閉（緩存相關(guān) CDP 消息），等實(shí)際用到對(duì)應(yīng)功能或模擬器加載完成時(shí)再打開(kāi)（發(fā)送所有緩存消息），來(lái)達(dá)到提升模擬器加載速度的效果。

最終方案如下圖所示：

出于穩(wěn)定性考慮，我們也為這個(gè)優(yōu)化加了開(kāi)關(guān)

三、總結(jié)

本文介紹了我們?cè)趯?duì)模擬器進(jìn)行性能優(yōu)化過(guò)程中，做了哪些事情。首先通過(guò)手動(dòng)打點(diǎn)分析耗時(shí)，確定了主要優(yōu)化方向，將模擬器的雙進(jìn)程架構(gòu)改成了單進(jìn)程架構(gòu)。在單進(jìn)程架構(gòu)下，通過(guò)增加緩存復(fù)用層，進(jìn)一步提升了加載速度。同時(shí)單進(jìn)程架構(gòu)也使得我們可以使用 performance 錄制工具進(jìn)行更精細(xì)的耗時(shí)分析，針對(duì)性的對(duì)編譯產(chǎn)物做了按需加載優(yōu)化，并通過(guò)「#sourceURL 注釋」解決了斷點(diǎn)失效的問(wèn)題。此外，我們也對(duì)調(diào)試器相關(guān)邏輯進(jìn)行了優(yōu)化，并取得不錯(cuò)的效果。

??優(yōu)化前后對(duì)比??

經(jīng)過(guò)本次優(yōu)化后，模擬器秒開(kāi)率從 18%提升至 64%，F(xiàn)CP P90 從 4.4s 提升至 1.9s，在開(kāi)發(fā)者滿意度調(diào)研中也獲得了好評(píng)。模擬器的性能與開(kāi)發(fā)者體驗(yàn)、開(kāi)發(fā)效率息息相關(guān)，而提高開(kāi)發(fā)者的開(kāi)發(fā)體驗(yàn)與開(kāi)發(fā)效率，是我們團(tuán)隊(duì)的首要任務(wù)。未來(lái)，我們將繼續(xù)努力，不斷優(yōu)化和完善模擬器的各項(xiàng)功能，為開(kāi)發(fā)者提供更好的支持。