最近一年我收到最多的私信類型不是“某個(gè)組件怎么用”而是“我們App里的小程序越來(lái)越多要不要自研一套容器”。問(wèn)的人多了我開(kāi)始意識(shí)到一個(gè)趨勢(shì)當(dāng)團(tuán)隊(duì)業(yè)務(wù)發(fā)展到一定規(guī)模市面上現(xiàn)成的跨端方案已經(jīng)填不滿需求的坑大家開(kāi)始把目光投向了一個(gè)更深水區(qū)——小程序容器。小程序容器這個(gè)東西往簡(jiǎn)單了說(shuō)就是一個(gè)能跑小程序代碼的運(yùn)行時(shí)環(huán)境它把JS邏輯、原生渲染、能力橋接幾大塊打包在一起讓一份業(yè)務(wù)代碼能在iOS、Android、甚至更多端上跑起來(lái)。往復(fù)雜了說(shuō)它是一個(gè)跨端技術(shù)的底座有了它你的App就成了一個(gè)“小操作系統(tǒng)”業(yè)務(wù)團(tuán)隊(duì)不用等發(fā)版就能上線新頁(yè)面第三方業(yè)務(wù)可以隔離運(yùn)行甚至整個(gè)App的功能模塊都能解耦成一個(gè)個(gè)可插拔的小程序。這篇文章我不會(huì)給你講“未來(lái)已來(lái)”這種虛詞而是按我自己實(shí)操過(guò)的路徑拆解整套容器的架構(gòu)設(shè)計(jì)、關(guān)鍵技術(shù)選型、通信協(xié)議和一批上線后才會(huì)遇到的坑。如果你正打算自研容器或者在做跨端動(dòng)態(tài)化方案這篇文章應(yīng)該能幫你少走半年的彎路。1. 為什么非要折騰一個(gè)“自己的”小程序容器1.1 現(xiàn)成小程序平臺(tái)解決不了的問(wèn)題很多人下意識(shí)會(huì)覺(jué)得小程序這個(gè)概念不是早就被微信做透了嗎想用小程序直接平臺(tái)上線不就好了。但這里有個(gè)關(guān)鍵的差異微信小程序是跑在微信App里的你的業(yè)務(wù)得到的只是一個(gè)入口而不是一個(gè)運(yùn)行環(huán)境。你的目標(biāo)用戶如果在自己的App里你要的是一個(gè)能嵌入自家App的運(yùn)行時(shí)讓你能把一段下發(fā)的代碼拖起來(lái)跑成界面。這套東西2024年之后市面上其實(shí)出現(xiàn)了不少商業(yè)化方案從早期的WebView套殼到后來(lái)各家推出的跨端容器SDK都能做到“遠(yuǎn)程下發(fā)一段JS和模板然后在App里渲染出原生頁(yè)面”。但問(wèn)題也隨之而來(lái)商業(yè)SDK的黑盒屬性決定了你沒(méi)法改底層。一旦遇到內(nèi)存增長(zhǎng)異常、通信丟消息、首屏速度跟不上的情況你能做的只有提工單等回復(fù)。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)線上小程序頁(yè)面在低端機(jī)上頻繁崩潰查了兩個(gè)月最后發(fā)現(xiàn)是容器SDK在特定機(jī)型上JS引擎回收不及時(shí)。這種問(wèn)題你是無(wú)法自己定位并解決的。1.2 自研容器不是一個(gè)“野心”問(wèn)題而是一個(gè)成本問(wèn)題自研容器聽(tīng)起來(lái)是個(gè)大工程動(dòng)輒幾十人年的投入很多團(tuán)隊(duì)一聽(tīng)到就先打了退堂鼓。但我說(shuō)句實(shí)在話如果你需要的只是一個(gè)“能跑自己業(yè)務(wù)代碼的動(dòng)態(tài)化頁(yè)面”那這個(gè)投入遠(yuǎn)比想象中低。最小可行容器的核心模塊就三個(gè)JS引擎、渲染層、通信橋。其他諸如包管理、灰度、調(diào)試器都是后置需求。我個(gè)人見(jiàn)過(guò)最小的可用容器是三年前一個(gè)團(tuán)隊(duì)用三個(gè)月時(shí)間搭出來(lái)的當(dāng)時(shí)的架構(gòu)很簡(jiǎn)單用JavaScriptCore承載業(yè)務(wù)邏輯用原生組件樹(shù)承載界面抹平了三端的渲染差異通信橋在JS與原生各開(kāi)一面方法是同步返回值、異步走回調(diào)圖片、導(dǎo)航、埋點(diǎn)等能力直接映射到宿主App的SDK這套東西跑起來(lái)第一版確實(shí)粗糙首屏得等個(gè)半秒crash率也談不上漂亮。但它解決了一個(gè)最核心的問(wèn)題**上線后發(fā)現(xiàn)Bug不再需要重新走App發(fā)版流程了可以直接下發(fā)新版小程序包去救火。**就這一條省下的發(fā)版人力成本就足夠覆蓋整個(gè)容器的研發(fā)投入。1.3 什么條件下才值得起這套爐灶我得勸退一部分人。如果你的業(yè)務(wù)特征是“一年不發(fā)幾次版、頁(yè)面形態(tài)穩(wěn)定、團(tuán)隊(duì)小、沒(méi)有專職基建”那自研容器大概率是得不償失的直接用現(xiàn)成的跨端框架甚至Hybrid方案就好。值得自研的判斷標(biāo)準(zhǔn)我整理下來(lái)基本是這幾條業(yè)務(wù)有高頻動(dòng)態(tài)化需求且頁(yè)面更新節(jié)奏以“天”甚至“小時(shí)”為周期你的App內(nèi)有多個(gè)獨(dú)立業(yè)務(wù)方或者是平臺(tái)型App需要相互隔離、獨(dú)立發(fā)版現(xiàn)有跨端方案解決不了核心性能痛點(diǎn)比如復(fù)雜列表滾動(dòng)、大圖渲染你的團(tuán)隊(duì)有足夠的客戶端基建人力能長(zhǎng)期維護(hù)下去如果命中兩條以上就可以接著看這篇文章了。2. 容器整體架構(gòu)一段JS到一塊屏幕的完整旅程2.1 最小可行容器由哪幾個(gè)模塊組成講架構(gòu)之前先給一張整體的模塊清單不用把它當(dāng)成映射表去背而是想清楚一件事每一個(gè)模塊的存在都是為了解決“遠(yuǎn)程下發(fā)→本地執(zhí)行→界面展示→能力調(diào)用”這條鏈路里的某一個(gè)環(huán)節(jié)。一個(gè)最小容器至少要有這五個(gè)模塊JS運(yùn)行時(shí)負(fù)責(zé)執(zhí)行小程序的邏輯代碼、管理頁(yè)面生命周期、處理事件綁定渲染層把邏輯層的“界面描述”翻譯成真實(shí)界面?？梢苑g成原生View也可以翻譯成Web頁(yè)面或者兩者混合通信橋連接JS運(yùn)行時(shí)和原生層讓邏輯層可以調(diào)用相機(jī)、定位、網(wǎng)絡(luò)等原生能力包管理負(fù)責(zé)小程序包的下載、校驗(yàn)、解壓、版本更新和回滾生命周期調(diào)度管理小程序從加載、啟動(dòng)、前臺(tái)、后臺(tái)到銷毀的完整狀態(tài)機(jī)這里面的分層思想最接近的類比是“瀏覽器之于網(wǎng)頁(yè)”瀏覽器負(fù)責(zé)把HTML/CSS/JS渲染成界面并且通過(guò)萬(wàn)維網(wǎng)提供文件獲取能力容器則把這些能力收攏到了一個(gè)App內(nèi)部只不過(guò)它要對(duì)接的不是域名而是你App內(nèi)的多個(gè)業(yè)務(wù)SDK渲染目標(biāo)不是DOM而是原生的視圖。2.2 小程序包的結(jié)構(gòu)與加載流程小程序包的載體通常就是一個(gè)zip壓縮包我見(jiàn)過(guò)的最小包體能做到幾十KB核心就是一個(gè)目錄your-app/ ├── app.json # 全局配置頁(yè)面路由、窗口樣式、權(quán)限聲明 ├── app.js # 應(yīng)用入口全局生命周期鉤子 └── pages/ ├── home/ │ ├── index.js # 頁(yè)面邏輯 │ ├── index.xml # 頁(yè)面結(jié)構(gòu)模板 │ ├── index.css # 頁(yè)面樣式 │ └── index.json # 頁(yè)面獨(dú)立配置 └── detail/ └── ...加載流程大概是這樣一個(gè)鏈路客戶端啟動(dòng)時(shí)向服務(wù)器請(qǐng)求“小程序列表”拿到版本號(hào)后與本地的版本號(hào)比對(duì)不一致就去拉新包。包下載完成會(huì)校驗(yàn)完整性MD5/簽名然后解壓到沙盒目錄。接下來(lái)JS引擎啟動(dòng)并加載app.js按app.json里配置的路由找到當(dāng)前頁(yè)面Home讀取模板和JS開(kāi)始首屏渲染。這一步有個(gè)很多人前期忽略的點(diǎn)**包下載是異步的用戶打開(kāi)小程序后可能因網(wǎng)絡(luò)差出現(xiàn)白屏。**成熟的容器必須在包管理的調(diào)度里做“預(yù)下載”和“本地兜底版本”的規(guī)劃而不是等用戶點(diǎn)到那個(gè)入口才去下載。2.3 多端運(yùn)行時(shí)的統(tǒng)一抽象層既然這套容器要跨iOS和Android未來(lái)可能還有鴻蒙那就要處理一個(gè)很現(xiàn)實(shí)的問(wèn)題三端底層完全不一樣JS引擎不一樣原生UI體系不一樣連線程模型都不一樣。為了讓上層業(yè)務(wù)代碼只寫一遍就必須畫出“統(tǒng)一抽象層”。抽象層要做的事是規(guī)定一個(gè)“中間標(biāo)準(zhǔn)”。業(yè)務(wù)代碼不關(guān)心你底層是用JavaScriptCore還是V8也不關(guān)心你渲染的最終是UIView還是Compose還是ArkUI——它只跟你抽象的接口說(shuō)話interface MiniAppRuntime { /** 在每個(gè)頁(yè)面的邏輯入口創(chuàng)建時(shí)被調(diào)用 */ createPage(config: PageConfig): PageInstance; /** 將頁(yè)面邏輯與原生視圖進(jìn)行綁定 */ attachView(pageId: string, viewToken: NativeViewToken): void; /** 調(diào)用宿主原生能力 */ invokeNative(channel: string, method: string, params: Recordstring, unknown): Promiseunknown; /** 通知原生層頁(yè)面生命周期變化 */ notifyLifecycle(pageId: string, state: PageLifecycleState): void; }底層各端自己去翻譯這些接口就好。iOS用JavaScriptCore或V8實(shí)現(xiàn)JS運(yùn)行時(shí)Android默認(rèn)也是V8或QuickJS鴻蒙初期可以接方舟引擎但上層接口對(duì)齊了整體改造量就會(huì)被壓縮得很小。3. JS引擎選型容器的發(fā)動(dòng)機(jī)決定性能上限3.1 主流JS引擎橫向?qū)Ρ菾S引擎是小程序容器的心臟它的執(zhí)行速度、內(nèi)存管理方式直接決定容器上限。主流的可嵌入引擎有JavaScriptCore、V8、Hermes、QuickJS這幾個(gè)我實(shí)際對(duì)比下來(lái)它們的差別非常大選錯(cuò)了后面會(huì)很痛苦。引擎適用平臺(tái)啟動(dòng)速度內(nèi)存占用調(diào)試支持備注JavaScriptCoreiOS原生快中等好iOS系統(tǒng)自帶集成成本最低V8Android/桌面中高極好執(zhí)行性能最強(qiáng)快照支持好HermesAndroid/iOS極快低一般為React Native定制字節(jié)碼預(yù)編譯QuickJS全平臺(tái)/嵌入式極快極低弱體積小適合受限環(huán)境這里我給一個(gè)具體的選型路徑基于我實(shí)際操作中的經(jīng)驗(yàn)iOS端直接用系統(tǒng)自帶的JavaScriptCore別折騰V8。iOS的JavaScriptCore深度集成在系統(tǒng)里內(nèi)存管控和調(diào)試支持都是系統(tǒng)級(jí)的自己編譯V8進(jìn)iOS是個(gè)大坑Apple對(duì)動(dòng)態(tài)代碼的限制和審核也容易出問(wèn)題。Android端用V8但不是裸V8而是用官方提供的V8快照機(jī)制來(lái)做平臺(tái)初始化。Android端用V8的啟動(dòng)性能優(yōu)勢(shì)非常明顯特別是復(fù)雜頁(yè)面邏輯較多時(shí)。后續(xù)要往鴻蒙、PC桌面上擴(kuò)QuickJS可以作為“輕量引擎?zhèn)溥x”在環(huán)境受限的端上跑簡(jiǎn)化版容器。雖然它的JIT能力弱但勝在嵌入極其簡(jiǎn)單而且完全不需要做平臺(tái)依賴處理。3.2 引擎實(shí)例池不能讓JS引擎裸奔新手做容器特別容易踩的一個(gè)坑每個(gè)小程序頁(yè)面啟動(dòng)時(shí)都重新創(chuàng)建一個(gè)JS引擎實(shí)例。這個(gè)做法在業(yè)務(wù)量小的時(shí)候看不出來(lái)問(wèn)題但頁(yè)面多起來(lái)后內(nèi)存和CPU都扛不住幾乎必然導(dǎo)致啟動(dòng)白屏和頻繁GC掉幀。正確的做法是維護(hù)一個(gè)引擎實(shí)例池Engine Pool。比如在App端預(yù)啟動(dòng)1到2個(gè)JS引擎實(shí)例A頁(yè)面退出后B頁(yè)面直接復(fù)用已有的引擎上下文而不需要重新編譯JS、初始化內(nèi)置對(duì)象。引擎池設(shè)計(jì)的時(shí)候有兩個(gè)細(xì)節(jié)需要提前盤算隔離與復(fù)用的平衡引擎上下文要隔離因?yàn)樾〕绦駻和B的全局變量不能串。但JS引擎本身也就是運(yùn)行時(shí)環(huán)境可以復(fù)用。對(duì)應(yīng)到代碼上就是共享JavaScriptCore的JSContextGroup但每個(gè)小程序用獨(dú)立的JSGlobalContextRef。冷熱切換內(nèi)存壓力大的時(shí)候需要把空閑引擎實(shí)例回收。用一個(gè)引用計(jì)數(shù)來(lái)標(biāo)記哪些引擎正在被頁(yè)面占用、哪些是空閑可回收的防止低端機(jī)上被系統(tǒng)殺掉。3.3 業(yè)務(wù)代碼與原生能力的安全隔離小程序容器和普通的JS執(zhí)行環(huán)境最大的區(qū)別在于它要執(zhí)行的是“遠(yuǎn)程下發(fā)的非可信代碼”。你不能讓小程序里的JS直接拿到原生的任意能力不然一個(gè)惡意頁(yè)面就能拿走用戶通訊錄。所以Js引擎和原生能力之間必須卡一道“能力白名單”。我的做法是在引擎?zhèn)茸⑷胍唤M有限的原生對(duì)象而不是把所有宿主能力全部暴露出去// 注入到小程序邏輯層的全局對(duì)象只有這些方法可以被調(diào)用 globalThis.MiniAppBridge { callNative: function(channel, method, args) { // 這里的channel和method會(huì)被原生側(cè)再做一次白名單校驗(yàn) // extra記錄調(diào)用方的pageId用于權(quán)限控制和鏈路追蹤 return nativeBridgeInvoke(this.__pageId, channel, method, args); }, on: function(eventName, callback) { // 訂閱原生事件注意卸載時(shí)要及時(shí)移除回調(diào)防止泄漏 } };這樣的設(shè)計(jì)可以理解為安檢**JS側(cè)能做任何事兒但能碰到的東西只有一把鑰匙且門衛(wèi)原生側(cè)還會(huì)再查一遍白名單。**不過(guò)要注意一個(gè)問(wèn)題原生側(cè)做白名單校驗(yàn)時(shí)建議不要用字符串比對(duì)HTTP接口路徑的做法因?yàn)殒溌返男阅芤蠓浅？量獭８玫淖龇ㄊ恰巴ǖ谰幪?hào)”每個(gè)能力預(yù)分配一個(gè)唯一整形IDJS側(cè)調(diào)用時(shí)帶上ID原生側(cè)直接最佳匹配。省掉了字符串哈希的時(shí)間高峰期這個(gè)優(yōu)化非常有用。4. Native Bridge設(shè)計(jì)雙線程通信的協(xié)議與陷阱4.1 通信鏈路從JS調(diào)用原生方法的一次完整握手小程序容器里的JS邏輯和原生UI線程天然是不在同一線程的。JS引擎跑在自己的線程上我們叫邏輯線程原生UI跑在主線程上。這兩個(gè)線程之間的對(duì)話就是Native Bridge要解決的事。一次最簡(jiǎn)單的調(diào)用“獲取當(dāng)前網(wǎng)絡(luò)狀態(tài)”完整鏈路如下JS代碼里調(diào)用MiniAppBridge.callNative(device, getNetworkState, {})Bridge層把參數(shù)對(duì)象拍平成JSON字符串為了方便跨線程傳遞通過(guò)線程消息隊(duì)列把數(shù)據(jù)包發(fā)到主線程主線程上的Bridge處理中心解包找到device通道對(duì)應(yīng)的原生處理器原生處理器調(diào)用系統(tǒng)能力拿到網(wǎng)絡(luò)狀態(tài)把結(jié)果封裝成回調(diào)包包含調(diào)用ID和數(shù)據(jù)發(fā)回邏輯線程JS側(cè)根據(jù)調(diào)用ID匹配Promiseresolve結(jié)果這段鏈路里最容易被忽視的就是回調(diào)ID的匹配。因?yàn)镴S的調(diào)用是異步的你發(fā)100個(gè)網(wǎng)絡(luò)請(qǐng)求出去哪個(gè)先回來(lái)、哪個(gè)后回來(lái)都是不可控的。所以每個(gè)調(diào)用發(fā)出時(shí)都要帶一個(gè)自增的唯一調(diào)用IDcallId原生側(cè)返回時(shí)帶上這個(gè)IDJS側(cè)才能把結(jié)果交付給對(duì)應(yīng)那次調(diào)用的Promise。沒(méi)有這套機(jī)制異步場(chǎng)景全部會(huì)錯(cuò)亂。4.2 大圖片、長(zhǎng)列表數(shù)據(jù)的傳輸優(yōu)化通信橋是容器里最大的性能瓶頸位置尤其是大數(shù)據(jù)的搬運(yùn)。如果你在JS側(cè)直接把一張base64圖片丟給原生去顯示那通信報(bào)文會(huì)膨脹三分之一以上首屏卡到?jīng)]法看。這里不能圖省事得做幾層處理通道分級(jí)把數(shù)據(jù)分成控制通道和媒體通道?？刂仆ǖ雷哳l繁小包媒體通道走專用的大包傳遞甚至可以直接把圖片的先讀地址傳給原生讓原生直接從本地讀取根本不必經(jīng)過(guò)Bridge做一次數(shù)據(jù)拷貝。二進(jìn)制序列化有些團(tuán)隊(duì)圖方便直接用JSON字符串但遇到ArrayBuffer、二進(jìn)制數(shù)據(jù)時(shí)就抓瞎了。建議協(xié)議層支持二進(jìn)制塊用一個(gè)頭部標(biāo)記標(biāo)識(shí)數(shù)據(jù)類型而不是一刀切字符串。節(jié)流與批量長(zhǎng)列表渲染時(shí)每次滑動(dòng)都觸發(fā)幾十個(gè)通信小包的場(chǎng)景很常見(jiàn)。直接把幾十個(gè)更新合并成一個(gè)數(shù)據(jù)包批量發(fā)過(guò)去通信次數(shù)能減少70%以上。4.3 回調(diào)風(fēng)暴、超時(shí)與異常兜底通信橋上線之后最先暴露的問(wèn)題就是“回調(diào)風(fēng)暴”。比如原生側(cè)啟動(dòng)了一個(gè)相機(jī)拍照流程如果拍照過(guò)程中用戶取消了原生側(cè)的取消回調(diào)沒(méi)處理好JS側(cè)會(huì)是這樣一個(gè)狀態(tài)發(fā)了調(diào)用一直等沒(méi)有結(jié)果回來(lái)。因?yàn)闆](méi)有超時(shí)機(jī)制Promise永遠(yuǎn)掛起內(nèi)存堆積頁(yè)面越來(lái)越卡。所以Bridge在設(shè)計(jì)之初就必須內(nèi)置三層兜底回調(diào)超時(shí)每次JS發(fā)起調(diào)用都會(huì)登記一個(gè)超時(shí)時(shí)間我習(xí)慣設(shè)500ms網(wǎng)絡(luò)類操作單獨(dú)設(shè)長(zhǎng)一些超時(shí)就自動(dòng)reject。異?；卣{(diào)響應(yīng)包里帶error和code字段原生側(cè)即使崩潰了也要回傳一個(gè)格式統(tǒng)一的錯(cuò)誤對(duì)象不能直接不給回音。調(diào)用鏈追蹤每一條調(diào)用都帶有全局唯一的traceId線上排查問(wèn)題的時(shí)候可以一鍵串起來(lái)這條命令從哪個(gè)頁(yè)面發(fā)出、原生側(cè)哪個(gè)模塊處理的、耗時(shí)多少、失敗在哪一步。5. 渲染方案取舍原生渲染、WebView與同層渲染5.1 三條技術(shù)路線的優(yōu)劣對(duì)比容器把JS邏輯I哎呀思后怎么把界面畫出來(lái)這個(gè)小程序容器相比“純JS解釋器”的最大區(qū)別。主流方案就三條路線各有各的坑。路線渲染速度動(dòng)態(tài)樣式能力實(shí)現(xiàn)復(fù)雜度內(nèi)存占用典型場(chǎng)景原生樹(shù)渲染極快弱需預(yù)置組件高低強(qiáng)交互、長(zhǎng)列表、地圖WebView渲染中強(qiáng)跟網(wǎng)頁(yè)一致低高營(yíng)銷頁(yè)、富文本展示同層渲染中高中極高中混合場(chǎng)景頁(yè)面里同時(shí)存在原生視頻和網(wǎng)頁(yè)富文本我實(shí)際項(xiàng)目里的經(jīng)驗(yàn)是**主力頁(yè)面用原生樹(shù)渲染營(yíng)銷內(nèi)容多、排版需求不確定的頁(yè)面用WebView承載同層渲染只在高度定制化的頁(yè)面里使用。**這就好比蓋房子框架結(jié)構(gòu)用鋼筋混凝土隔斷可以用輕鋼龍骨但你不能用輕鋼龍骨當(dāng)承重墻來(lái)用。5.2 原生樹(shù)渲染下的View層級(jí)同步用原生樹(shù)渲染時(shí)JS層擁有的是一棵“虛擬節(jié)點(diǎn)樹(shù)”它不是真實(shí)界面只是一堆描述數(shù)據(jù)。每次狀態(tài)變化JS層需要把這棵樹(shù)的變化同步給原生層原生層拿到JSON后去增刪改真實(shí)的原生View。這套機(jī)制最關(guān)鍵的兩個(gè)字diff。你不能每次狀態(tài)變化都把整棵樹(shù)發(fā)給原生那樣頁(yè)面一變就全量重建View性能直接被打穿。需要自己做一層虛擬DOM diff算出哪些節(jié)點(diǎn)增刪、哪些屬性變了然后只把增量操作發(fā)給原生層。具體到工程實(shí)現(xiàn)上我建議這樣組織// 虛擬節(jié)點(diǎn)描述 const vnode { type: view, props: { id: header, style: { flex-direction: row }, onClick: handleHeaderTap }, children: [ { type: text, props: { value: Hello MiniApp } } ] };原生側(cè)拿到這棵樹(shù)后建立一套“節(jié)點(diǎn)ID ? 原生View”的映射表。diff產(chǎn)生的操作是createNode、updateNode、deleteNode三種每條操作都帶上節(jié)點(diǎn)ID原生側(cè)定位到對(duì)應(yīng)View去處理。這張映射表是原生渲染模塊的核心數(shù)據(jù)結(jié)構(gòu)它處理得好不好決定了嵌套深級(jí)頁(yè)面會(huì)不會(huì)出現(xiàn)內(nèi)存混亂。注意虛擬DOM的diff計(jì)算是在JS引擎線程里執(zhí)行的這本身就是耗時(shí)邏輯。我見(jiàn)過(guò)push數(shù)據(jù)更新后三屏長(zhǎng)列表diff計(jì)算耗時(shí)超過(guò)200ms的案例。優(yōu)化手段只有兩個(gè)方向縮小diff范圍只diff變化的靜態(tài)區(qū)塊或者把diff計(jì)算放到子線程去。前期架構(gòu)設(shè)計(jì)時(shí)就得把這根弦繃住。5.3 混合渲染的橋接邊界實(shí)際業(yè)務(wù)不會(huì)這么單純。一個(gè)餐廳詳情頁(yè)上半段是原生速度快、體驗(yàn)好的菜單列表下半段是運(yùn)營(yíng)放上去的活動(dòng)說(shuō)明富文本——這就要在原生渲染的頁(yè)面里嵌入一塊WebView。混合渲染本質(zhì)就是在原生ViewTree上挖一個(gè)坑把一個(gè)WebView或WKWebView放進(jìn)去。但這里有個(gè)邊界問(wèn)題這塊WebView里的事件怎么跟外層JS通信我試過(guò)幾種方案最可靠的是直接通過(guò)Bridge的“跨通道消息轉(zhuǎn)發(fā)”來(lái)實(shí)現(xiàn)。webview里的頁(yè)面向小程序邏輯JS發(fā)了個(gè)postMessageBridge把它包成一個(gè)普通的消息包按原生→邏輯的方向傳回去邏輯層統(tǒng)一處理。這樣對(duì)開(kāi)發(fā)者來(lái)說(shuō)嵌入的富文本內(nèi)容和原生組件沒(méi)有本質(zhì)區(qū)別都是下發(fā)數(shù)據(jù)、接收事件而已。6. 上線后的排障記錄白屏、卡頓、內(nèi)存增長(zhǎng)的排查鏈路6.1 首次啟動(dòng)白屏包解壓與引擎預(yù)熱的競(jìng)速線上收到的第一波用戶反饋集中在“第一次打開(kāi)需要等很久”。這個(gè)問(wèn)題的根因是首啟時(shí)鏈路太長(zhǎng)了——下載新包、解壓、校驗(yàn)、啟動(dòng)引擎、編譯JS、加載首屏一整套流程全在用戶點(diǎn)擊觸發(fā)的瞬間串行執(zhí)行。后面我們的解法是三步。第一步把“下載解壓預(yù)編譯”拿到App啟動(dòng)階段去做。用戶在前一個(gè)頁(yè)面停留的平均時(shí)長(zhǎng)遠(yuǎn)高于我們做后臺(tái)預(yù)熱的耗時(shí)必須利用這段時(shí)間把未來(lái)的小程序包準(zhǔn)備好。第二步預(yù)啟動(dòng)JS引擎實(shí)例。前文提到的引擎池在這里派上用場(chǎng)App啟動(dòng)后預(yù)熱1個(gè)引擎小程序打開(kāi)時(shí)直接把編譯好的字節(jié)碼快照丟進(jìn)引擎上下文省掉了解析和編譯時(shí)間。實(shí)測(cè)這一步可以直接把首屏?xí)r間優(yōu)化約40%。第三步首屏不發(fā)整包而是先下沉發(fā)一個(gè)精簡(jiǎn)版的啟動(dòng)快照只有app.js和小首頁(yè)相關(guān)頁(yè)面后續(xù)頁(yè)面按需加載。這個(gè)思路很像網(wǎng)頁(yè)的“按需引入”讓首屏依賴的模塊數(shù)量最少。6.2 頁(yè)面退出后內(nèi)存不見(jiàn)回落Context泄漏排查鏈路第二個(gè)高頻線上問(wèn)題是用戶逛完幾個(gè)小程序頁(yè)面后App整體內(nèi)存漲上去了退回首頁(yè)也不回落。這里先說(shuō)結(jié)論絕大多數(shù)泄漏的根因在于JS引擎的Context釋放不徹底。JSContext不僅裝著JS變量還通過(guò)Bridge握著大量原生對(duì)象的引用。頁(yè)面退出了原生對(duì)象沒(méi)有被JS側(cè)的全局變量回收兩者互相引用整個(gè)內(nèi)存圖就死了GC根本收不掉。排查鏈路我也走了一遭給各位后來(lái)人留個(gè)標(biāo)把小程序邏輯層的內(nèi)存快照導(dǎo)出來(lái)在Chrome DevTools里看heap snapshot用Memory分析工具反復(fù)進(jìn)出頁(yè)面三到五次對(duì)比快照里哪些對(duì)象是“新增且未釋放”的命中最多的就是兩個(gè)點(diǎn)全局事件監(jiān)聽(tīng)器沒(méi)有移除、原生端注冊(cè)的回調(diào)沒(méi)有被反注冊(cè)根治的方法是在頁(yè)面銷毀的生命周期鉤子onUnload里把事件監(jiān)聽(tīng)和Bridge調(diào)用全部反注冊(cè)。同時(shí)在容器原生側(cè)設(shè)置一個(gè)強(qiáng)制回收開(kāi)關(guān)頁(yè)面退出超過(guò)30秒后把JSContext和原生交互對(duì)象之間的強(qiáng)引用徹底斷開(kāi)讓兩個(gè)側(cè)的內(nèi)存都可以獨(dú)立回收。6.3 滾動(dòng)掉幀長(zhǎng)列表的渲染同步瓶頸第三個(gè)大坑是長(zhǎng)列表滾動(dòng)掉幀。原理不復(fù)雜頁(yè)面滾動(dòng)時(shí)最少有50%的滑動(dòng)事件要去JS線程計(jì)算然后diff出增量、再同步給原生線程。鏈路這么長(zhǎng)掉幀其實(shí)怪不得任何單方。我們優(yōu)化的核心是把“同步渲染”改成“異步分片渲染”。滾動(dòng)過(guò)程不讓JS線程全量參與而是把一個(gè)邏輯層的“滾動(dòng)事件”轉(zhuǎn)化為最精簡(jiǎn)的“首尾可見(jiàn)區(qū)問(wèn)”只渲染可視區(qū)前后各擴(kuò)大一段preload窗口的節(jié)點(diǎn)離屏的節(jié)點(diǎn)直接虛擬化。原生層配上View復(fù)用機(jī)制滾動(dòng)時(shí)沒(méi)有新建View只有位置和內(nèi)容更新掉幀問(wèn)題就煙消云散了。這里我再多說(shuō)一句長(zhǎng)列表優(yōu)化沒(méi)有銀彈。不同容器的處理差異很大程度上決定了你最終的用戶體驗(yàn)。所以架構(gòu)選型階段一定提前確定好“滾動(dòng)性能”這條紅線別等頁(yè)面堆到一定程度再去補(bǔ)。7. 從容器到生態(tài)調(diào)試器、DSL轉(zhuǎn)換與跨端擴(kuò)展7.1 完善調(diào)試器是遲早要補(bǔ)的課如果自研容器只跑內(nèi)部業(yè)務(wù)不做調(diào)試工具其實(shí)勉強(qiáng)能用但生態(tài)伙伴一旦接入沒(méi)有調(diào)試器就是災(zāi)難。業(yè)務(wù)方不能一上來(lái)就跟你說(shuō)“請(qǐng)?jiān)谌罩纠镎乙幌隆倍切枰艽驍帱c(diǎn)、能看邏輯層變量、能檢查原生的視圖層級(jí)。調(diào)試器的技術(shù)本質(zhì)就是把JS引擎暴露的調(diào)試協(xié)議比如V8的Inspector協(xié)議、JSC的REPL接到開(kāi)發(fā)工具上去。容器側(cè)要做的是開(kāi)啟調(diào)試模式下把當(dāng)前引擎實(shí)例暴露到本地的調(diào)試端口然后在開(kāi)發(fā)工具里配置代理讓工具與引擎之間走一遍遠(yuǎn)距離調(diào)試握手。這個(gè)過(guò)程實(shí)際上比聽(tīng)起來(lái)簡(jiǎn)單真正花時(shí)間的是把通信鏈路和現(xiàn)有的Bridge協(xié)議統(tǒng)一起來(lái)不能搞一套獨(dú)立通道否則后面維護(hù)成本翻倍。7.2 讓上層業(yè)務(wù)用Vue/React語(yǔ)法寫小程序直接讓業(yè)務(wù)團(tuán)隊(duì)用純JS加原生標(biāo)簽寫小程序接受度普遍不高。要讓容器成為生態(tài)最理想的狀態(tài)是上層開(kāi)發(fā)者用自己熟悉的框架開(kāi)發(fā)Vue或React打包工具最終編譯出一棵樹(shù)讓容器運(yùn)行時(shí)來(lái)渲染。這條路有成熟范式可借鑒寫一個(gè)編譯器插件把Vue組件編譯成我們?nèi)萜鞯腣Node也就回到了第5.2節(jié)講的原生渲染模型里。Vue組件的data就是邏輯層的狀態(tài)render函數(shù)對(duì)應(yīng)生成虛擬節(jié)點(diǎn)樹(shù)事件綁定直接映射到節(jié)點(diǎn)props里的onClick。業(yè)務(wù)開(kāi)發(fā)寫的是Vue組件等到這一層之后完全被化進(jìn)了容器體系。這一步做完了容器就不再是自己的玩具而是團(tuán)隊(duì)技術(shù)規(guī)范的統(tǒng)一出口。7.3 鴻蒙、桌面端與硬件端的容器平移容器架構(gòu)一旦設(shè)計(jì)成“核心運(yùn)行時(shí) 平臺(tái)適配層”跨端平移的工作量就變得可控了。平臺(tái)適配層要處理的只有三塊JS引擎的接入方式、原生View體系的翻譯、宿主能力SDK的橋接。拿鴻蒙舉例適配層要做的事非常清晰——通過(guò)N-API接入方舟引擎View體系從UIView/ViewGroup翻譯成ArkUI的Column和Row每個(gè)原生的API調(diào)用重新映射一遍就好了。同樣的道理也適用于未來(lái)的PC桌面端甚至嵌入式設(shè)備里如果跑得動(dòng)QuickJS這套架構(gòu)可以原樣搬過(guò)去跑。我在遷移過(guò)程中最深的感受是**架構(gòu)前期所有的抽象工作在后期都會(huì)變成平移時(shí)的福報(bào)。**如果你現(xiàn)在的容器沒(méi)有明確分“核心和適配”兩層這個(gè)教訓(xùn)是早晚要交的。寫到最后我想說(shuō)一點(diǎn)個(gè)人的體會(huì)。小程序容器最迷人的不只是那套技術(shù)棧而是它帶來(lái)的思維方式轉(zhuǎn)變你不再做一個(gè)個(gè)獨(dú)立的App頁(yè)面而是造一個(gè)能讓業(yè)務(wù)自己生長(zhǎng)、自己演進(jìn)的東西。這個(gè)轉(zhuǎn)變會(huì)倒逼你從架構(gòu)層面去思考能力邊界、性能上限、生態(tài)建設(shè)這些都是普通業(yè)務(wù)開(kāi)發(fā)里難得機(jī)會(huì)。如果團(tuán)隊(duì)已經(jīng)決定邁出這一步我給的建議是**第一版不要追求大而全先把“包下載、跑JS、渲染簡(jiǎn)單組件、調(diào)用原生能力”這四件事打通就好。**其他的等用戶反饋出來(lái)了再說(shuō)。容器這套東西是逐步長(zhǎng)出來(lái)的不是一次設(shè)計(jì)出來(lái)的。