沈雅

達(dá)達(dá)集團(tuán)是中國領(lǐng)先的本地即時零售與配送平臺，達(dá)達(dá)快送小程序作為公司重要的ToC業(yè)務(wù)入口，對外提供幫取幫送、跑腿幫買、幫排隊(duì)等服務(wù)，承擔(dān)了ToC業(yè)務(wù)較高部分的訂單量。對于小程序而言，性能至關(guān)重要。但是用戶打開率偏低，以微信平臺為例，打開率是指在小程序冷啟動的情況下，點(diǎn)擊小程序到首屏渲染完成的百分比。代碼包越大啟動耗時越長、白屏?xí)r間越久，用戶越可能因?yàn)槭ツ托亩顺鲂〕绦颍谵D(zhuǎn)化率不變的情況下，訂單量越低。如果性能不達(dá)標(biāo)會帶來以下兩點(diǎn)影響：

影響小程序流量獲??；

影響用戶體驗(yàn)，進(jìn)而降低用戶留存。

不同平臺小程序性能指標(biāo)構(gòu)成不盡一致，但主要有3個維度考慮：啟動性能、網(wǎng)絡(luò)性能、運(yùn)行性能，其中網(wǎng)絡(luò)性能主要包含請求耗時及請求錯誤率，和接口質(zhì)量以及用戶網(wǎng)絡(luò)狀況強(qiáng)相關(guān)，所以此次性能優(yōu)化的重點(diǎn)放在啟動性能以及運(yùn)行性能。

碎片化優(yōu)化

碎片化主要是指優(yōu)化動作過于離散、不連貫無法形成體系。過去在啟動速度不達(dá)標(biāo)時，也會按照小程序平臺開發(fā)者工具建議優(yōu)化，額外也有些分包、縮包、圖片壓縮等動作，但有局限性無法形成合力，依舊存在無法解決的問題：

優(yōu)化效果有限，無法達(dá)到“優(yōu)秀”官方評測結(jié)果；

啟動速度在需求迭代中反彈；

過于定制化無法陳定并固化至后續(xù)需求研發(fā)中。

性能指標(biāo)難保持

增加啟動階段的理解、利用好開發(fā)者工具、借鑒官方啟動優(yōu)化實(shí)踐，通過常規(guī)動作大概率可以實(shí)現(xiàn)一段時間啟動性能指標(biāo)。但要實(shí)現(xiàn)指標(biāo)長期穩(wěn)定，依舊存在問題：

指標(biāo)監(jiān)控體系缺失：小程序后臺雖然會提供性能數(shù)據(jù)，但數(shù)據(jù)散落在各個平臺，很難在業(yè)務(wù)迭代中持續(xù)關(guān)注并跟進(jìn)。另外一旦指標(biāo)波動，用戶第一時間就會感知體驗(yàn)下降，而研發(fā)是“后知后覺”的。

業(yè)務(wù)需求迭代包體積增加：過去3個季度，達(dá)達(dá)快送小程序的發(fā)單場景由2個變成8個。

碎片化：“碎片化”的優(yōu)化實(shí)踐，不成體系無法系統(tǒng)性解決性能問題。

團(tuán)隊(duì)成員變動：相關(guān)文檔少，人員變動時無法有效沉淀。

小程序性能分析

本地開發(fā)中微信小程序提供了體驗(yàn)評分工具它會在小程序運(yùn)行過程中實(shí)時檢查，分析出一些可能導(dǎo)致體驗(yàn)不好的地方，并且定位出哪里有問題，以及給出一些優(yōu)化建議。支付寶小程序可以使用全息檢測。

除了本地開發(fā)參考官方后臺，評分工具是在本地運(yùn)行小程序代碼時進(jìn)行分析，但性能數(shù)據(jù)往往需要在真實(shí)環(huán)境和大數(shù)據(jù)量下才更有說服力。恰巧，小程序管理平臺開發(fā)者提供了大量的真實(shí)數(shù)據(jù)統(tǒng)計。

關(guān)鍵路徑

雖然不同平臺對小程序啟動耗時的各有一套定義，但往往也只是對啟動耗時終點(diǎn)定義不一致，小程序的啟動流程非常類似，大致會包含以下4步：

小程序相關(guān)信息準(zhǔn)備；

框架資源準(zhǔn)備；

業(yè)務(wù)資源準(zhǔn)備；

加載渲染。

以微信小程序?yàn)槔瑔雍臅r指標(biāo)統(tǒng)計的終點(diǎn)是生命周期onReady作為時間的結(jié)束，比較趨近于First Contentful Paint（FCP）指標(biāo)。而支付寶小程序則更加趨近于Time to Interactive（TTI）指標(biāo)。

FCP：首次繪制任何文本、圖像、非空白canvas或SVG的時間點(diǎn)。

TTI：度量從頁面開始加載到主要的子資源加載完成并且能夠快速可靠地響應(yīng)用戶交互的時間。

啟動性能指標(biāo)是個綜合結(jié)果體現(xiàn)，不同階段會受用戶、平臺以及小程序本身的影響。因此我們以支付寶平臺提供的全息檢測工具，梳理了各個細(xì)分階段影響因素。

階段定義

setUp：應(yīng)用初始化，主要是db查詢時間。

Update：查詢更新信息，對比差異。

offine：下載離線包。

waitLoadApp：解壓，等待渲染。

分析各個階段影響因素確定4個核心優(yōu)化思路：

靜態(tài)資源優(yōu)化，控制總包、主包、分包大?。?/p>

接口聚合，合并接口并盡可能串行改并行，縮短最短請求路徑；

啟動頁模塊調(diào)整，分析啟動頁功能模塊，在不影響業(yè)務(wù)流程前提下，優(yōu)化交互方式，提升頁面渲染性能；

沉淀傳承，總結(jié)歸納優(yōu)秀實(shí)踐，持續(xù)保持優(yōu)秀性能指標(biāo)。

靜態(tài)資源優(yōu)化

如上文所述，資源包體積對小程序包下載、包解壓、代碼注入等的多個啟動階段都有不同程度的影響。而且小程序平臺對包體積大小也有明確限制。

所以資源包體積大小對啟動性能也尤為重要，因此選擇“靜態(tài)資源優(yōu)化”作為第一步優(yōu)化動作。

包體積優(yōu)化

核心思路：從包加載時機(jī)和包體積大小2個維度思考。對應(yīng)動作分別是：預(yù)加載、縮包、分包異步化。

預(yù)加載：主要指微信小程序平臺，通過平臺提供的預(yù)拉取能力，在不影響主包的情況下將分包加載時機(jī)提前，提升分包頁面的加載速度。

縮包

分包：將相對獨(dú)立的頁面和組件拆分到分包，可以解決主包體積受限問題。但隨著業(yè)務(wù)的迭代實(shí)際開發(fā)中會遇到主包即使頁面很少也會過大，經(jīng)過長期的實(shí)踐沉淀出一套適合我們的分包策略。

無用文件、函數(shù)、樣式剔除：業(yè)務(wù)迭代無法避免會產(chǎn)生無用文件，小程序可以入lazy Code Loading：required Components（在開啟“按需注入”特性的前提下，“用時注入”可以指定一部分自定義組件不在小程序啟動時注入，而是在真正渲染的時候才進(jìn)行注入），我們也可以用工具分析沒有用到的文件和依賴，進(jìn)行刪除。

延遲加載：分包一定程度可以縮減主包體積，但也會遇到“插件無法實(shí)現(xiàn)分包處理”和“多業(yè)務(wù)的分包難以劃分”。所以采用了分包異步化（該能力目前只在微信小程序中有）使用componentPlaceholder占位，異步拉取分包加載，完成分包下載和注入后，將占位組件替換成真正的組件。

圖片資源處理

壓縮圖片：上傳的圖片可以使用2倍圖（當(dāng)設(shè)備像素比很大時，圖片會被放大，而放大會讓圖片看起來模糊。為此，可以使用2二倍圖的方式來提高圖片的清晰度）并且壓縮，大圖片不要超過100 KB。利用一些壓縮技術(shù)對圖片進(jìn)行壓縮，壓縮尺寸可觀，但對圖片顯示質(zhì)量影響甚微。

小圖片使用IconFont：避免小圖片作為CDN的情況，因?yàn)镠TTP一個域名下有請求并發(fā)限制，過多圖片會造成隊(duì)頭阻塞?？梢允褂肐conFont和base64等方式。

大圖片統(tǒng)一使用CDN：在圖片處理中，因?yàn)橛龅降那闆r是大部分都是運(yùn)營配置的圖片，可以在配置的后臺限制大小，自動轉(zhuǎn)化成webp格式（webp它可讓網(wǎng)頁圖檔有效進(jìn)行壓縮，同時又不影響圖片格式兼容與實(shí)際清晰度，進(jìn)而讓整體網(wǎng)頁下載速度加快）。

懶加載圖片：屏幕外的圖片可以使用懶加載，只有下拉之后才去加載對應(yīng)的圖片。

接口聚合&時序優(yōu)化

在小程序中，發(fā)起網(wǎng)絡(luò)請求是利用wx.request來發(fā)送的，不同于瀏覽器一個域名并發(fā)的限制，wx.request調(diào)用的并發(fā)限制為10。超出限制的請求會被阻塞。所以針對接口主要采取的舉措有：

實(shí)時性較低的接口緩存結(jié)果：可以采用的策略是，頻繁使用的數(shù)據(jù)緩存到內(nèi)存，實(shí)時性較低的結(jié)果緩存到本地，下次啟動可以讀取到內(nèi)存中繼續(xù)使用，也可以給緩存設(shè)置一個時效，更新本地緩存；

減少接口串行：接口沒有依賴關(guān)系的可以考慮使用Promise.all；

預(yù)拉取首屏資源：預(yù)拉取能夠在小程序冷啟動的時候提前向第三方服務(wù)器拉取業(yè)務(wù)數(shù)據(jù)，當(dāng)代碼包加載完時可以更快地渲染頁面，減少用戶等待時間；

接口合并，優(yōu)化速度：分析接口詢問后端是否可以合并接口，優(yōu)化稍慢的接口；

小結(jié)：在分析接口層面時，我們整理了小程序首頁的接口調(diào)用的時序圖；

優(yōu)化前：總共用戶進(jìn)入小程序后21個（埋點(diǎn)接口和個端差異接口未計算在內(nèi)）；

優(yōu)化后：總共用戶進(jìn)入小程序后17個（埋點(diǎn)接口和個端差異接口未計算在內(nèi)）；

對比優(yōu)化的結(jié)果由原來的串行長度為10加少到了6，接口總數(shù)減少4個，并加入了接口緩存，預(yù)拉取，本次優(yōu)化在支付寶大約帶來了500 ms的時延下降。

啟動頁模塊調(diào)整

不管是微信還是支付寶小程序啟動速度的考量并不單單是首頁的耗時，包含所有入口頁面。達(dá)達(dá)小程序有查看訂單詳情，活動頁等都會作為啟動頁投放。我們對業(yè)務(wù)梳理針對性的做了優(yōu)化。

首頁

首頁預(yù)先拉取了金剛位，banner，廣告位等資源，因?yàn)閷?shí)際調(diào)用中獲取這些資源鏈路比較長，我們冷啟動中獲取資源在小程序啟動直接渲染，在真實(shí)調(diào)用中去比較數(shù)據(jù)的變化，增量更新，雖然首頁是千人千面，但是絕大多數(shù)內(nèi)容是類似的，提前渲染可以提升總體加載時間。

對于獲取位置信息是比較耗時的，在用戶授權(quán)后緩存了結(jié)果到內(nèi)存，并且存入本地設(shè)置了一個時效，在用戶下次打開時，未過期的情況下可以直接讀取本地I/O?？紤]到位置信息需要調(diào)用多個接口獲取且較慢，所以提升較大。

在分析包大小時發(fā)現(xiàn)主包存在過大的SDK，但沒有辦法去除，或者利用plugin方式加載。最后是將涉及插件的SDK拆到分包中利用分包異步化去加載。

首頁彈窗邏輯之前有5種以上，通過讓后臺承擔(dān)更多的業(yè)務(wù)邏輯，可以節(jié)省小程序前端代碼量，以前的做法是前端從不同接口獲取資源，然后通過優(yōu)先級去展示，前端做很多邏輯處理，現(xiàn)在有后端實(shí)現(xiàn)了一套廣告位系統(tǒng)，減少了接口調(diào)用和邏輯判斷。

物流詳情頁

針對天降紅包，因?yàn)樗?個接口，影響較大。我們執(zhí)行了發(fā)券用戶操作之后去加載紅包。

針對地圖的展示，去除了非必要的路徑規(guī)劃，折疊展示了地圖；本次業(yè)務(wù)流程的優(yōu)化，在支付寶小程序總體降低了400 ms時延。

優(yōu)秀實(shí)踐

“突擊優(yōu)化”一定程度上能夠提升性能指標(biāo)，但持續(xù)保持性能指標(biāo)的穩(wěn)定則功在平時。因此除了固化一些專項(xiàng)優(yōu)化策略，比如：分包策略、圖片處理策略等，還需要沉淀更多實(shí)踐并傳承。

流程類：

建立指標(biāo)監(jiān)控體系：主要包含：包大小、圖片大小、啟動耗時、評測結(jié)果。過去研發(fā)對于指標(biāo)的波動是“后知后覺”的，指標(biāo)監(jiān)控利于研發(fā)盡早人員發(fā)現(xiàn)問題，減少對用戶影響。

規(guī)范發(fā)版：除了代碼包體積代碼注入、首屏渲染之外，發(fā)版頻率等因素也會影響小程序啟動耗時，通過與業(yè)務(wù)方確認(rèn)在不影響小程序正常功能迭代的前提下，約定每周2次固定發(fā)版。

代碼類：

要提升渲染性能就要了解小程序的架構(gòu)，如下圖所示。

從圖中可以看出，由于渲染層與邏輯層分開，一個小程序有多個界面，所以渲染層對應(yīng)存在多webview。這2個線程之間由Native層進(jìn)行統(tǒng)一處理。無論是線程之間的通信、數(shù)據(jù)的傳遞、網(wǎng)絡(luò)請求都由Native層做轉(zhuǎn)發(fā)。所以如何減少數(shù)據(jù)交互的頻率和大小是提升渲染性能的關(guān)鍵。

代碼類：

合并setData調(diào)用：盡可能合并setData的調(diào)用，將多次setData合并為一次，可以模仿vue的nextTick寫合并的邏輯（調(diào)用setState時提供的對象會被加入到一個數(shù)組中，當(dāng)下一次事件循環(huán)執(zhí)行的時候再把這些對象合并一起，通過setData傳遞給原生小程序），支付寶小程序可以調(diào)用batchedUpdates來批量更新，減少調(diào)用次數(shù)。

減少setData大?。簜鬏?shù)臄?shù)據(jù)量越多，線程間通信的耗時越長，渲染速度就越慢，我們的做法是將不設(shè)計渲染的數(shù)據(jù)放入_data中。

去掉不必要的屬性節(jié)點(diǎn)，綁定屬性數(shù)據(jù)大?。涸趚ml中綁定屬性data-xxx，盡量減少數(shù)據(jù)的大小，視圖層會把事件target和dataset數(shù)據(jù)傳輸給邏輯層。當(dāng)自定義數(shù)據(jù)量越大，事件通信的耗時就會越長。

JSAPI調(diào)用限制：一些同步API會阻塞渲染，啟動頁面減少使用Sync結(jié)尾的同步API，get SystemIn fo Sync，get Storage Sync，set Storage Sync。可以緩存結(jié)果，或者使用異步獲取數(shù)據(jù)。原則就是：減少使用，緩存結(jié)果。

依賴庫優(yōu)化：刪除了埋點(diǎn)框架中一些非必要的同步API的獲取操作，或者延后執(zhí)行，將頻繁調(diào)用的API結(jié)果緩存到內(nèi)存中，減少調(diào)用。

總結(jié)&規(guī)劃

我們來梳理一下整體的優(yōu)化思路，如下圖所示。

微信平臺

啟動耗時降低20 %；

過去兩個季度，啟動耗時長期維持在優(yōu)秀；

打開率提升0.5 %。

支付寶平臺

C端支付寶小程序【達(dá)達(dá)快送】啟動耗時降低40%，現(xiàn)在維持在優(yōu)秀水平。

服務(wù)競爭力指數(shù)SCI（支付寶平臺）：提升至滿分。

經(jīng)過本次優(yōu)化微信和支付寶小程序都達(dá)到了官方的優(yōu)秀指標(biāo)，優(yōu)化的經(jīng)驗(yàn)適用所有小程序。但如何監(jiān)控啟動速度，如何結(jié)合自身業(yè)務(wù)定義小程序性能指標(biāo)，出現(xiàn)問題及時告警，能夠定位具體的原因，需要建立一套自己監(jiān)控體系，持續(xù)保持小程序性能。