秒開之路——百度百科小程序性能優(yōu)化實(shí)踐
導(dǎo)語：作為頭部小程序，百度百科的用戶體驗(yàn)對(duì)于百度智能小程序生態(tài)的用戶體驗(yàn)有重要的作用。頁面加載速度是影響用戶搜索體驗(yàn)的一個(gè)重要因素。百度APP對(duì)用戶行為的研究表明，頁面首屏的加載時(shí)間在1秒以內(nèi)的站點(diǎn)或小程序，用戶的留存率會(huì)越高，更符合用戶對(duì)快捷搜索體驗(yàn)的期待。本文是智能小程序直播課的文字版本，將為大家詳細(xì)講解百度百科小程序（以下簡(jiǎn)稱“百科”）在達(dá)到“秒開”方面做了哪些方面的優(yōu)化，視頻版本請(qǐng)看直播回放：https://live.baidu.com/m/media/pclive/pchome/live.html?room_id=4959977629&source=h5pre。
一、百科小程序概況
百科小程序主要的頁面有詞條頁，首頁，秒懂視頻feed頁面，個(gè)人中心以及相關(guān)二級(jí)頁。
默認(rèn)圖片
圖1：百科明星loft特型詞條
百科小程序編譯后代碼總大小1119.8k，其中主包大小856k，代碼總行數(shù)20.3w行，頁面總數(shù)有59個(gè)，其中8個(gè)頁面在主包內(nèi)。在這些頁面中，詞條頁流量占居首位，高達(dá)87.7%，其他主要頁面，秒懂視頻頁占比4.7%，圖片頁占比3.5%，首頁占比0.2%，剩余的其他頁面一共占比3.9%，從流量占比我們可以看出，詞條頁是百科小程序的主要流量頁面，所以百科小程序的性能優(yōu)化，詞條頁就成為了重點(diǎn)優(yōu)化頁面。
百科小程序采用的是Okam小程序框架，在Okam框架和小程序原生組件的基礎(chǔ)上，通過VUE及VUE組件實(shí)現(xiàn)的頁面功能，包括公共組件和私有組件，然后后端數(shù)據(jù)是通過異步API請(qǐng)求到前端的。Okam代碼再通過編譯器生成小程序原生代碼，最終展現(xiàn)給用戶。Okam框架的的優(yōu)勢(shì)主要提現(xiàn)在開發(fā)效率和維護(hù)上，Okam把小程序原生的目錄結(jié)構(gòu)js，json，css，dom等文件合成了一個(gè)VUE文件，這樣的話，在開發(fā)階段是比較便捷的，開發(fā)效率快，代碼也比較容易維護(hù)。另外，Okam可以編譯成多個(gè)小程序，這樣一套代碼就可以實(shí)現(xiàn)多個(gè)平臺(tái)的小程序，節(jié)約成本，大家如果對(duì)Okam感興趣可以看一下官方文檔詳細(xì)了解一下。
默認(rèn)圖片
圖2：百科小程序架構(gòu)示意圖
二、性能優(yōu)化詳解
在介紹優(yōu)化手段之前，我們一起來看一下小程序的啟動(dòng)流程，用戶點(diǎn)擊打開小程序后，進(jìn)行小程序包的下載，下載后邏輯層和渲染層首先并行執(zhí)行，然后在initData處改為串聯(lián)執(zhí)行，大概的過程，邏輯層依次執(zhí)行加載動(dòng)態(tài)庫和插件、加載邏輯代碼、執(zhí)行onLaunch，與此同時(shí)，渲染層依次執(zhí)行加載模板和樣式文件（包括app.css，page.css和page.swan等相關(guān)文件）、然后加載SJS（SJS是智能小程序的一套自定義腳本語言）、加載當(dāng)前頁面所有使用到的自定義組件（包括動(dòng)態(tài)庫和插件）。渲染層完成以上執(zhí)行后，會(huì)用邏輯層收集到的initData進(jìn)行首次內(nèi)容繪制（也就是FCP），其中initData主要包含了小程序App、頁面和自定義組件的初始數(shù)據(jù)。首次內(nèi)容繪制完成后，渲染層向邏輯層發(fā)送firstRendered事件，邏輯層開始執(zhí)行生命周期onLoad等，完成以上所有流程后，會(huì)觸發(fā)首次有意義的渲染，也就是FMP。
默認(rèn)圖片
圖4：百度小程序啟動(dòng)流程
接下來，我們一起來看一下百科小程序性能優(yōu)化的主要優(yōu)化手段，這些優(yōu)化手段分成了4大類：
第一類，包體積優(yōu)化；
第二類請(qǐng)求優(yōu)化，其中包含以下5點(diǎn)。
1. 改造request，之所以要改造是分析發(fā)現(xiàn)之前百科的request的實(shí)現(xiàn)多處對(duì)小程序原生異步接口的處理都用Promise包了一層，一共有4個(gè)地方，這樣其實(shí)使用上方便了，但是實(shí)際上增加了處理耗時(shí)，針對(duì)這個(gè)問題，百科進(jìn)行了request腳本的重寫，把4個(gè)promise優(yōu)化成了1個(gè)，這里也提醒一下大家在首屏渲染前盡量少用Promise。
2. 是關(guān)于小程序入口結(jié)果卡的，主要是結(jié)果卡前置prelink時(shí)機(jī)，這里開發(fā)者們不需要關(guān)注太多，只需要在app.js配置一下prelink的地址即可（https://baikeapi.baidu.com/smartapp/prelink?app=baike），這個(gè)操作能讓小程序盡早的對(duì)業(yè)務(wù)請(qǐng)求建立鏈接。
3. 動(dòng)態(tài)庫支持preload，百科目前主要用到了評(píng)論組件動(dòng)態(tài)庫。
4. 請(qǐng)求提前。
5. 是后端接口的優(yōu)化，主要包括精簡(jiǎn)詞條頁首屏接口數(shù)據(jù)和星圖接口耗時(shí)的優(yōu)化
第三類，渲染優(yōu)化；
第四類，編譯優(yōu)化，主要包括兩點(diǎn)，一是全量?jī)?yōu)化包，其中包含app.js優(yōu)化和自定義組件拆分優(yōu)化等。二是接入css module。編譯優(yōu)化的這兩點(diǎn)開發(fā)者幾乎沒有什么代碼上的工作量，只需要申請(qǐng)開啟白名單，然后進(jìn)行小程序效果回歸，最后灰度上線觀察沒問題后全量即可。
接下來會(huì)對(duì)以上優(yōu)化手段中的包體積優(yōu)化、請(qǐng)求提前、渲染優(yōu)化進(jìn)行詳細(xì)介紹。這三點(diǎn)也是對(duì)于百科小程序來說優(yōu)化收益比較明顯的。
2.1 包體積優(yōu)化
結(jié)合前面介紹的小程序啟動(dòng)流程，小程序包的下載與解析是整個(gè)啟動(dòng)過程中的一個(gè)重要階段，這個(gè)階段的耗時(shí)與小程序包大小呈正相關(guān)，將直接影響到邏輯層initData 完成收集的時(shí)間，從而影響到首屏渲染。因此，包體積的優(yōu)化能減小 initData 的準(zhǔn)備時(shí)間，提前首屏渲染的起始點(diǎn)，進(jìn)而減小首屏渲染時(shí)長(zhǎng)，也就是FMP。
在包體積優(yōu)化上，百科主要做了以下三件事。
1. 主包大小減到極致，減到最小，進(jìn)行合理分包。
整體來看，百科小程序的包大概分為主包和分包，分包主要有三個(gè)，分別是subPage，，general，editor。主包有8個(gè)頁面，主要有詞條頁，秒懂視頻頁，首頁，圖片頁，無網(wǎng)絡(luò)提示頁。劃分依據(jù)：按pv分，靠前的頁面，或者有對(duì)外合作而不能輕易更改路徑的頁面。subPage包主要有36個(gè)頁面，主要有圖冊(cè)頁，演員表頁，星圖頁，AR頁，參考資料頁，百科貢獻(xiàn)者頁，音樂專輯頁以及參演電影頁等，劃分依據(jù)：pv少，功能獨(dú)立單一，一般是詞條頁等頁面的二級(jí)頁。general包主要有14個(gè)頁面，主要有搜索頁，個(gè)人中心頁，社區(qū)帖子頁等，劃分依據(jù)：一些常用的頁面，頁面入口一般存在于topbar、bottombar等公共組件里，即多個(gè)頁面都有入口的放在本包內(nèi)。最后一個(gè)editor包，目前只有一個(gè)頁面——概述圖冊(cè)編輯頁，劃分依據(jù)：編輯提交類頁面，編輯器等，比如后面小程序要實(shí)現(xiàn)文本編輯器就放入此包內(nèi)。
默認(rèn)圖片
圖5：百科小程序分包情況
1. 包內(nèi)不要放過多或者過大的文件資源。之前百科圖片資源是都放在了包內(nèi)存儲(chǔ)和維護(hù)，隨著業(yè)務(wù)功能的不斷迭代和新增，圖片等資源會(huì)越來越多，包體積將會(huì)越來越大，那么包下載就會(huì)越來越耗時(shí)，最后導(dǎo)致FMP越來越退化。所以這里建議不要把圖片等資源放到包內(nèi)存儲(chǔ)。在這點(diǎn)上，百科是把圖片資源從包內(nèi)遷移到了百度云CDN上面來存儲(chǔ)和管理，給主包瘦了個(gè)身。
2. 最后一點(diǎn)，也是跟工程意識(shí)和代碼規(guī)范相關(guān)的，要及時(shí)清理垃圾，保持項(xiàng)目的干凈，下線的功能和邏輯要?jiǎng)h除，千萬不要注釋代碼。歷史經(jīng)驗(yàn)表明，注釋的代碼一般是不會(huì)再次上線，注釋的代碼給后面的維護(hù)也會(huì)帶來困難，后面的人也不會(huì)輕易刪，這樣垃圾就一直在。所以再次強(qiáng)調(diào)，不要注釋代碼，養(yǎng)成良好的編碼習(xí)慣。
2.2 請(qǐng)求提前
從小程序生命周期原理圖中可以看到，小程序生命周期依次是app.onLaunch->app.onShow->page.onInit->page.onLoad->page.onShow->page.onReady->page.onHide-> unload-> end
默認(rèn)圖片
圖6：小程序生命周期原理圖
百科小程序在請(qǐng)求時(shí)機(jī)上，最開始是在page的onLoad里面進(jìn)行數(shù)據(jù)請(qǐng)求，然后提前到了page的onInit里面，再然后提前到了app的onLaunch中，直到現(xiàn)在提前到了app的onPrefetch。從圖中我們也明顯能看到數(shù)據(jù)請(qǐng)求從page級(jí)的生命周期提前到了app級(jí)的生命周期的初始時(shí)機(jī)，一個(gè)飛躍式的提前。這里重點(diǎn)說一下app的onPrefetch。在剛剛介紹小程序生命周期中沒有提到app的onPrefetch，onPrefetch是小程序基于百度結(jié)果卡實(shí)現(xiàn)的一個(gè)預(yù)取能力。這個(gè)預(yù)期能力的時(shí)機(jī)是可以配置的，主要有點(diǎn)擊結(jié)果卡和展現(xiàn)結(jié)果卡。對(duì)于百科結(jié)果卡這種高pv的卡顯然是不適合在展現(xiàn)的時(shí)候進(jìn)行預(yù)取，所以百科自然設(shè)置的是點(diǎn)擊時(shí)預(yù)取。
默認(rèn)圖片
圖7：百科小程序請(qǐng)求時(shí)機(jī)的歷史演變
首先我們需要建一個(gè)prefetch.js預(yù)請(qǐng)求文件，在這個(gè)文件里面主要通過onPrefetch來監(jiān)聽預(yù)取事件，然后執(zhí)行業(yè)務(wù)的數(shù)據(jù)邏輯。如圖8所示，在onPrefetch的事件監(jiān)聽里面有個(gè)lemmaRequest方法，這個(gè)就是百科詞條頁的數(shù)據(jù)請(qǐng)求方法。
默認(rèn)圖片
圖8：prefetch.js文件
在建立預(yù)請(qǐng)求文件之后，還需要在app的入口文件里面配置預(yù)取相關(guān)的配置，如圖9，主要是開關(guān)的配置、預(yù)取文件路徑的配置以及預(yù)取時(shí)機(jī)的配置，預(yù)期時(shí)機(jī)默認(rèn)為點(diǎn)擊時(shí)預(yù)取，滿足百科點(diǎn)擊預(yù)取的訴求，所以百科這里用了默認(rèn)值沒有配置，如果大家有展現(xiàn)預(yù)取的訴求，可以增加一個(gè)state的配置項(xiàng)，設(shè)置成show即可。
默認(rèn)圖片
圖9：開關(guān)、預(yù)取文件路徑以及預(yù)取時(shí)機(jī)的配置
在實(shí)現(xiàn)的過程中，也遇到了一些問題——比如，如何解決發(fā)起兩次請(qǐng)求問題，就是說在首次調(diào)起小程序時(shí)app的onPrefetch里面已經(jīng)發(fā)起了請(qǐng)求，page的onInit里面應(yīng)該不需要再次發(fā)起請(qǐng)求，直接執(zhí)行邏輯和渲染即可。對(duì)于這個(gè)問題，百科是通過緩存請(qǐng)求來解決的。具體實(shí)現(xiàn)是，先建立一個(gè)詞條頁緩存區(qū)，通過請(qǐng)求參數(shù)生成的字符串作為每次請(qǐng)求的key值，request來作為value值。當(dāng)調(diào)用請(qǐng)求方法時(shí)先根據(jù)這個(gè)key值查詢緩存區(qū)是否已經(jīng)存在此請(qǐng)求，如果存在等待數(shù)據(jù)返回后執(zhí)行邏輯和渲染，如果緩存區(qū)沒有當(dāng)前請(qǐng)求則發(fā)起請(qǐng)求。緩存的清理一般是在onInit的數(shù)據(jù)請(qǐng)求回調(diào)中和請(qǐng)求異常時(shí)。
默認(rèn)圖片
圖10：請(qǐng)求緩存的實(shí)現(xiàn)
2.3渲染優(yōu)化
詞條頁的渲染優(yōu)化，主要包含三部分：首屏分析與劃分、渲染優(yōu)化和邏輯優(yōu)化。
首先，給大家介紹一下詞條頁的首屏分析，在百度小程序里面，百科應(yīng)該屬于功能和邏輯相對(duì)比較復(fù)雜的小程序之一，單看詞條頁，種類和情況就太多了，上面三個(gè)圖的情況只是冰山一角，圖11中的三張截圖也是挑選的相對(duì)通用的三種情況。接下來，給大家介紹一下這三個(gè)圖上面包含的功能組件，左邊是明星特型loft詞條，首屏主要包含topbar，loft，權(quán)威編輯模塊，card，右側(cè)懸浮區(qū)；中間是普通詞條，首屏主要包含了topbar，topImage，card，底bar，右側(cè)懸浮區(qū)；右邊是含有星圖結(jié)構(gòu)關(guān)系的詞條，首屏主要包含topbar，頂部星圖模塊，topImage，lemmaInfo， extraInfo，權(quán)威編輯模塊，card，底bar和右側(cè)懸浮區(qū)。
默認(rèn)圖片
圖11：百科詞條首屏分析示例
根據(jù)舉例的首屏分析，我們對(duì)模塊進(jìn)行梳理，總結(jié)出覆蓋幾乎所有詞條情況的首屏模塊。圖12就是對(duì)詞條頁模塊組件的梳理以及總結(jié)出的首屏模塊，此處不做一一介紹。
默認(rèn)圖片
圖12：首屏模塊梳理
1. 分段渲染
在首屏分析和模塊梳理的基礎(chǔ)上，實(shí)現(xiàn)了分段渲染。我們把詞條頁的渲染分為了四個(gè)階段，第一階段首屏渲染，第二階段正文前內(nèi)容渲染，第三階段正文內(nèi)容渲染，第四階段正文后內(nèi)容渲染，首屏渲染又分了兩個(gè)階段的渲染，正文渲染主要還實(shí)現(xiàn)了分屏渲染。分段渲染的關(guān)鍵實(shí)現(xiàn)是在setData回調(diào)中通過改變控制渲染開關(guān)的值。
默認(rèn)圖片
圖13：分段渲染示意圖
接下來，來看一下主要代碼片段。分別是beforeContentRender(正文前內(nèi)容渲染開關(guān))和beforeContentRendered（正文內(nèi)容渲染開關(guān)) 。
默認(rèn)圖片
和contentRenderDone(正文后內(nèi)容渲染開關(guān))：
默認(rèn)圖片
然后開關(guān)通過vue的if來實(shí)現(xiàn)對(duì)dom渲染的控制：
默認(rèn)圖片
默認(rèn)圖片
首屏區(qū)域的實(shí)際劃分：
默認(rèn)圖片
2. 分屏渲染
百科詞條頁可以分成兩大類，普通詞條和loft特型詞條。普通詞條在接受到數(shù)據(jù)后先進(jìn)行第一階段的數(shù)據(jù)處理，然后通過setData進(jìn)行第一次渲染，即首屏；然后再執(zhí)行第二階段的數(shù)據(jù)處理，再執(zhí)行正文前內(nèi)容的渲染。Loft特型詞條在接受到數(shù)據(jù)返回后進(jìn)行第一階段的數(shù)據(jù)處理然后通過setData進(jìn)行第一次渲染，再進(jìn)行第二階段的數(shù)據(jù)處理（主要是loft數(shù)據(jù)的處理），通過setData進(jìn)行第二次渲染，即首屏；然后再執(zhí)行第三階段的數(shù)據(jù)處理，再執(zhí)行正文前內(nèi)容的渲染。對(duì)比看兩者的主要區(qū)別在于特型詞條首屏多了一次邏輯處理和渲染，主要是loft梳理的從處理和渲染。同樣首屏的分段還是通過setdata回調(diào)和渲染開關(guān)來控制的。
分屏渲染主要靠pageScroll和分頁元素來實(shí)現(xiàn)，在頁面滾動(dòng)里面監(jiān)聽分頁元素的高度，即判斷到達(dá)頁底，在合適的時(shí)機(jī)setData正文數(shù)據(jù)，進(jìn)而實(shí)現(xiàn)分屏渲染。
默認(rèn)圖片
默認(rèn)圖片
默認(rèn)圖片
經(jīng)過這一系列的優(yōu)化，百科小程序的Q3 FMP數(shù)據(jù)從最高點(diǎn)的1504ms降到最低點(diǎn)982ms，大概優(yōu)化了522ms，Q3季末在9月22號(hào)首次秒開，也是百科小程序歷史性的一刻，在過去，19年、20年百科小程序的FMP一度高達(dá)1800ms，當(dāng)時(shí)覺得秒開對(duì)于百科小程序來說是一件遙遠(yuǎn)而且不可能完成的事情，但是今天我們做到了。在這個(gè)優(yōu)化的過程中，我們堅(jiān)信“世上無難事，只怕有心人”，發(fā)揮極客精神，追求極致體驗(yàn)，將一直作為百科小程序的目標(biāo)。
大家有任何問題，可以在評(píng)論區(qū)與我們交流，我們會(huì)集中邀請(qǐng)作者解答。
來源：百度搜索資源平臺(tái) 百度搜索學(xué)堂
