百度小程序框架性能優(yōu)化實踐

發(fā)表時間：2021-1-5

發(fā)布人：葵宇科技

瀏覽次數(shù)：67

今天給大家講的題目是《百度開源小程序框架架構(gòu)演進和性能優(yōu)化實踐》。本次分享包含兩部分，第一部分是百度智能小程序整體的框架及演進，主要講百度小程序開發(fā)全流程概況、百度智能小程序框架，以及百度小程序多宿主運行保障；第二部分是百度小程序框架的性能優(yōu)化，主要講整個小程序的啟動過程，以及從開發(fā)者角度，有哪些重要的優(yōu)化點。

百度智能小程序整體框架及演進

整個移動互聯(lián)網(wǎng)一直是在 NA 和 H5 之間尋找權(quán)衡，NA 的性能好、能力強；H5 靈活性更高。我認為渲染分為兩派，一派就是 NA 渲染派，一派叫做 H5 渲染派。

NA 渲染派，比較有代表性的如 RN、Flutter；
Web 渲染派，比如百度的輕應(yīng)用，以及之后做的小程序。

1. 開發(fā)全流程概覽

百度曾經(jīng)做過的 Web 渲染派的三個代表產(chǎn)品，分別是輕應(yīng)用、直達號和小程序。

輕應(yīng)用，是 H5 + 端能力。它是一個標準的 H5，增加了一些 NA 的 API，比如定位等。
直達號，在技術(shù)層面跟輕應(yīng)用是一樣的。
小程序，本質(zhì)上是一個受限的 H5 + 大量豐富的 API + UI 組件?，F(xiàn)在我們給小程序提供的 API 有 300 多個，組件有 30 多個，組件是有界面的。比如，視頻、地圖。

為什么小程序要受限，主要有兩個原因：

保持體驗的一致性。H5 太過靈活，JS 隨時可以去改變界面。
安全考慮。因為我們提供了大量 API 和組件，且這些都是很底層的一些能力，比如電話號碼、賬號，肯定不能輕易開放給大家。

怎么受限，主要有兩點：

編寫語言，不再是直接寫 HTML ，而是用自定義語言 swan 來編寫。
runtime 層有兩個棧，一個是渲染棧，一個是 JS 執(zhí)行棧，這兩個棧從物理上隔離，以保障安全性。

2. 智能小程序框架

（1）開發(fā)運行全流程

先簡單介紹一下整個百度智能小程序的開發(fā)流程。

首先開發(fā)者用 swan 寫布局；
接著通過開發(fā)者工具打包，上傳到我們的小程序 B 端服務(wù)器；
然后是小程序的審核流程，有機審、人審；
最后是用戶點擊小程序時，客戶端請求小程序 C 端服務(wù)器，C 端服務(wù)器再從 B 端服務(wù)器獲取小程序包。整個過程都是加密傳輸，可以保證代碼的安全。

（2）百度智能小程序框架 -SWAN

上圖是一個百度智能小程序的框架，我們內(nèi)部命名為 SWAN。

分層結(jié)構(gòu)如下：

最上層是開發(fā)者基礎(chǔ)庫，命名為 swan-js ，開發(fā)者直接和這層打交道。swan-js 負責(zé)兩件事情：（1）swan 代碼轉(zhuǎn)為 HTML，變成 WebView 可運行程序；（2）客戶端端能力的封裝暴露。
再下一層是 swan-native。這里面最核心的是 API 和組件的 NA 實現(xiàn)。其中雙棧管理也在這一層，另外標紅的 Extension 用于開發(fā)者宿主自身能力擴展使用，比如，貼吧宿主期望增加個發(fā)帖能力，就可以通過此機制。
再下面這層叫 Porting Layer。這層是百度小程序為了實現(xiàn)開源，增加的一層與宿主的接口層。
最下面這一層是宿主基礎(chǔ)能力層。如果宿主沒有這些能力，可以參考百度開源的參考實現(xiàn)，可直接集成到宿主使用。

3. 核心結(jié)構(gòu)

（1）前端角度

我們從前端的視角來看看雙棧結(jié)構(gòu)。一個宿主客戶端可以運行多個小程序，并且在一段時間內(nèi)保持存活狀態(tài)，每個小程序都有一個 master 執(zhí)行框架 JS 和小程序開發(fā)者的 JS，一個 master 對應(yīng)多個 slave（slave 代表一個用戶可見的界面）。

（2）客戶端角度

從客戶端角度來看雙棧結(jié)構(gòu)，如上圖所示，master 負責(zé)執(zhí)行 JS，可以有兩種實現(xiàn)方式，WebView 或 JS 引擎（V8/jscore），JS 引擎的效率更高；slave 的展現(xiàn)有 WebView，為了加快 WebView 的創(chuàng)建速度，設(shè)置 cache；master 和 slave 的通信通過消息總線。

master 不支持 BOM、DOM 和 WEB-API，小程序只能調(diào)用對外開放的能力。

（3）小程序 NA 組件與界面關(guān)系

從體驗上看，小程序的體驗要好于 H5，其中有一點就是小程序會把一些 NA 的能力和 UI 融合到小程序里面去。小程序的主體渲染還是基于 H5 技術(shù)，接下來我們講一下 NA 元素如何融入 UI 界面。

NA 元素與 H5 的關(guān)系有兩種，貼片關(guān)系、同層關(guān)系。

貼片關(guān)系：NA 元素在 H5 不在同一層，NA 浮在 H5 之上，H5 所有元素都不可以放到 NA 元素之上。因為不在一層，就需要處理滾動聯(lián)動，當檢測到 WebView 滾動 n 個像素， NA 元素也需要滾動 n 個像素。
同層關(guān)系：NA 元素在 H5 這一層，H5 的原生可以壓在 NA 元素之上。

貼片、同層的界面層級樹如上。

我們舉一個視頻組件同層的例子。視頻組件比較復(fù)雜，有 4 層。第 1 層是視頻層，即原始視頻的圖像，第 2 層是彈幕層，第 3 層是用于視頻控制的控件層（比如，開始、暫停按鍵），第 4 層 Slot 層，視頻上面漂的 H5 元素將被放到這層。

同層處理機制，先在 H5（開發(fā)者寫的 swan 會被轉(zhuǎn)為 H5）上打一個特殊的標記先占位，屬性 inline；瀏覽內(nèi)核把這個區(qū)域的 surface 拿出來給到 NA 層，然后，小程序框架會把這個區(qū)域 surface 塞給播放器，讓播放器直接在 surface 上面繪制，達到同層。上面的彈幕、控件、Slot，都是 swanjs 層 H5 實現(xiàn) ，Slot 層可以認為是一個容器，例如寫一個 video，其所有的子元素都會放在 Slot。

NA 的組件同層的技術(shù)方案還不太一樣，安卓和 iOS 也是有些區(qū)別的。像在 iOS 上，如果有些組件設(shè)置 over-flow ，它會天然支持這一套東西，但是安卓就需要瀏覽器內(nèi)核來支持。

4. 小程序多宿主運行保障

百度智能小程序是開放系統(tǒng)，可以運行在多宿主之上，那如何在多宿主上保證小程序運行體驗的一致性呢？

各個宿主集成了我們的小程序框架后，首先要跑 CTS 測試，通過之后才可以拿到小程序列表進行分發(fā)。

對于可選能力部分，各個宿主不是所有的能力都需要實現(xiàn)。比如，一些 AI 能力、push 能力。

如果一個小程序用到了可選能力怎么辦？

兩個辦法，一是小程序和宿主之間的雙向選擇機制，小程序可以選擇我要分發(fā)到哪些平臺，宿主也有權(quán)利選擇要分發(fā)到哪些宿主。二是，小程序做兼容。

上圖所示，標紅的是 Extension 機制，當宿主有一些定制化的要求時，可以使用此機制。作為宿主，需要做兩件事情，一是在 JS 層需要寫一套接口。二是在 Porting Layer 接口實現(xiàn)層實現(xiàn)一套能力。如果宿主覺得這個能力是通用的，可以反饋提案，審核通過后，百度小程序團隊會將提案合并到開源框架里。

5. 章節(jié)小結(jié)

百度智能小程序框架性能優(yōu)化實踐

首先從用戶視角看看一個小程序的加載過程。

1. 百度智能小程序加載分階段過程

拿微博舉例，如上圖所示。

首先小程序被啟動后，先是一個 Loading 的過程，上面的 title 和下面的 tab（框架 NA 實現(xiàn)）顯示出來。
第二張圖片我們定義為 FP（First Paint ）階段。
第三張圖下面有搜索框了，這其實是小程序包里面的內(nèi)容。它是通過 initdate 接口初始化渲染出來的，此階段我們定義為 FCP（ First Contentfull Paint ）階段。
第四張圖，是小程序從網(wǎng)上拉到了實時的內(nèi)容，然后更新到界面，我們將其定義為 FMP（First Meaningful Paint）階段。
最后一張圖，所有的元素都已經(jīng)拉下來并展示了，用戶可以操作任何一個位置，我們將其定義為 TTI (Time to Interative) 階段。

2. 百度智能小程序

（1）性能基線

百度小程序在 2019 年底建立了 FMP 指標，它在開發(fā)者平臺展示的名字為“上屏?xí)r間”。

我們統(tǒng)計了線上的一個 80 分位點，耗時是 1.9s。(什么是 80 分位點？比如，有 100 個請求過來了，然后我們把請求的耗時排序，第 80 個請求的耗時，我們就認為是 80 分位點。)

（2）性能歷史曲線

如上圖所示， 2019 年百度小程序性能優(yōu)化的歷史曲線。FP 框架層從接近 3s 一直優(yōu)化了現(xiàn)在的 1.1s 左右。百度小程序的目標是讓小程序無線接近 NA 體驗。

3. 啟動流程

接下來，我們從開發(fā)者角度看，還能優(yōu)化什么？我們先看一下啟動流程，所有的啟動邏輯簡單串行羅列（實際是有一些步奏是并行的）。

4. 性能優(yōu)化

開發(fā)者能夠做的性能優(yōu)化主要有兩部分。一是小程序包的體積，二是業(yè)務(wù)數(shù)據(jù)。接下來，我用三點來說明開發(fā)者可以做什么。

（1）包體積優(yōu)化

建議包體積保持在 1M 以內(nèi)，為什么呢？

因為我們統(tǒng)計了一下，如果打開當次需要下載包，則這次的啟動時長會占到我們整個時長的 60%。1M 的包，80 分位速度需要 1s+ 才能下載完成。所以要控制自己的包的體積。而且我們現(xiàn)在還只是看 80 分位，當我們拉到 90 分位，99 分位，這個是一個非常陡的曲線，惡化很嚴重。

包體優(yōu)化機制有兩個技術(shù)：一是分包技術(shù)和獨立分包技術(shù)，二是資源壓縮。

分包技術(shù) & 獨立分包技術(shù)
分包技術(shù)

一個小程序有很多頁面，但不是所有的頁面都是高 PV 頁面。很多頁面是用戶很少點到的，可以把這些頁面放到我們的分包去，主包放我們高 PV 的頁面。

分包不能夠獨立運行，比如，從搜索 feed 分發(fā)過去，它運行時需要把我們主包下載下來，但是因為它的概率低，不會影響絕大多數(shù)情況。簡而言之，就是用分包技術(shù)把非關(guān)鍵的頁面剝離出去。

用分包技術(shù)把非關(guān)鍵的頁面剝離出去之后小程序包的體積還是大的話怎么辦？

獨立分包技術(shù)

所謂獨立，就是說下載完這個包之后就可以運行，無需下載主包。此時的主包和獨立分包的區(qū)別就是，小程序總要有一個入口，這個入口的獨立分包，我們就命名為主包。

通過這兩項技術(shù)來減小我們的包體大小，將其保持在在 1M 以內(nèi)。

資源壓縮

我們分析過一些小程序，發(fā)現(xiàn)有的包體里包含 PC 圖片，這無疑增加了包的體積。建議如下：

把圖片放到服務(wù)器，不要放在包里面。
壓縮圖片體積，比如，把 png 改為 jpeg 格式這樣體積可以減少 90%（不考慮透明度情況）。
剔除無用資源。

App-js 需要通過分包來解決，最終我們要達到什么目標？

單個包控制在 1M 以內(nèi)。
文件數(shù)控制在 200 個以內(nèi)。

(2) 數(shù)據(jù)拉取

數(shù)據(jù)拉取的目的是快速讓界面有內(nèi)容，減少用戶的白屏?xí)r間。即使用戶是斷網(wǎng)的，也給他離線緩存一些數(shù)據(jù)。

如上圖所示，這里面提到了業(yè)務(wù)骨架屏和框架骨架屏?，F(xiàn)在很多小程序都會參考 H5 的實現(xiàn)，把 H5 的漸進式加載骨架屏用到我們的小程序里面，用了這種技術(shù)之后，反而會讓真實的內(nèi)容展示的速度變慢，我們統(tǒng)計大概有 300ms 延遲。

為了解決骨架屏導(dǎo)致的內(nèi)容展示延遲，我們做了一套框架層的骨架屏機制。按照我們這個機制來實現(xiàn)骨架屏，對性能的影響就會大大減少。策略上就是在 master 做 appjs 執(zhí)行時，就讓 slave 加載框架骨架屏，并行執(zhí)行。

自己寫的業(yè)務(wù)骨架屏，它什么時候才展示？如上圖所示，當你把 App 、page、waitNotify 通知到渲染線程，到了 Ready firstRender 的時候才會渲染自己做的業(yè)務(wù)骨架屏，這個過程當然很慢。雖然你用了骨架屏，但是骨架屏和用戶點擊的這段時間還有大量的白屏?xí)r間。用框架骨架屏，白屏?xí)r間問題就會解決。用框架骨架屏，或多或少都會耗一點時間，雖然是并行的，但是依然在搶占手機的資源。

所以整體來看，站在客戶端或者站在框架的角度，我們是不建議用，但是也不反對用。如果要用就用框架骨架屏，影響最小。

request 的優(yōu)化，我總結(jié)主要是兩點，第一要早，第二要少。

“早”又可以分兩部分來說，一是提早發(fā)，二是不阻塞。

第一是提早發(fā)，請求得太晚，展示當然比較慢了。建議把網(wǎng)絡(luò)請求放在 onlaunch 里面，這是我們給小程序開放的第一個事件，很多小程序會放到 page unload 里面，這個就比較慢了。這兩個時間在線上 80 分位，大概差 200ms～300ms。

第二個是不阻塞，經(jīng)?？吹揭恍┬〕绦颍黄饋硪院?，它要等用戶的授權(quán)、定位。通常定位涉及 XY 坐標，但是定位一旦涉及高度，就需要打開 GPS，這樣性能又會慢 2s～3s。如果不需要高度就不要去設(shè)置，否則非常慢。還有的小程序在使用的時候會讓用戶授權(quán)，如果不授權(quán)下面什么也不展示，阻塞了。如果可以的話，建議在需要授權(quán)的時候再提示用戶，這樣用戶也不反感，也能加快啟動的速度。

“少”，主要分為兩點，一是非關(guān)鍵請求延后，二是只拉取一屏數(shù)據(jù)。

一個小程序運行后，可能有幾十甚至上百個網(wǎng)絡(luò)請求，小程序除了自己的業(yè)務(wù)還要打點，這會很大程度上影響我們的網(wǎng)絡(luò)速度。因為一般的宿主在底層的網(wǎng)絡(luò)庫都會設(shè)置線程池，請求多了就要排隊。小程序框架根本不知道某個請求是核心請求還是非核心請求，只能排隊。要是一上來全是一些打點的，業(yè)務(wù)就阻塞了?？傊?，整個頁面需要顯示的數(shù)據(jù)先請求，非關(guān)鍵請求延后。

二是只拉一屏數(shù)據(jù)，分段加載。

（3）渲染

setData 操作是較為昂貴的，盡量減少數(shù)據(jù)量和次數(shù)。

如上圖所示，setData 是一個非常核心的 API，當網(wǎng)絡(luò)數(shù)據(jù)回來，只有經(jīng)過 setData 驅(qū)動渲染，內(nèi)容才能顯示到界面上。

上圖是一個優(yōu)化前和優(yōu)化后的對比。我們可以看到，即使是 1K 的數(shù)據(jù)，也需要 20ms 左右的時間。如果 js 是用 WebView 來執(zhí)行，首先一個 JS string，到了瀏覽器有 Renderer 線程、Browser 線程，變?yōu)?C 層的 string，然后再到我們 NA ，通過 Java interface，變成一個 Java string。然后到了 slave 以后還要再反過來，所以快不了。雖然我們做了一些優(yōu)化，通過內(nèi)核讓它變成一個內(nèi)存指針優(yōu)化切換，但是還是很昂貴。

發(fā)現(xiàn)有些小程序在使用的過程中， setData 使用有很多不當之處，以下是使用 setdata 要注意的幾點。

減少調(diào)用 setData 次數(shù)。goodcase：將多次 setData 合并成一次 setData 調(diào)用。
減少 setData 數(shù)據(jù)量。badcase：新一頁數(shù)據(jù)添加上之前頁面數(shù)據(jù)后再調(diào)用 setData。
變量變化只更新變量不更新對象。