支付寶小程序擴(kuò)展能力 性能解決方案

名詞解釋

背景

在大體量的小程序和開(kāi)發(fā)者形態(tài)下，小程序質(zhì)量體驗(yàn)問(wèn)題逐漸成為大家的關(guān)注焦點(diǎn)，如何提高自身小程序質(zhì)量體驗(yàn)成為所有開(kāi)發(fā)者的課題，而其中性能提升更是發(fā)力重點(diǎn)，接下來(lái)將和大家介紹支付寶小程序質(zhì)量團(tuán)隊(duì)性能解決方案，同時(shí)提供工具使用說(shuō)明。

首屏?xí)r間

首屏?xí)r間定義是指用戶(hù)開(kāi)始嘗試打開(kāi)小程序到小程序首屏加載完成的時(shí)長(zhǎng)。

從支付寶性能統(tǒng)計(jì)數(shù)據(jù)中發(fā)現(xiàn)，小程序首屏耗時(shí)上漲與用戶(hù)折損率上漲呈正相關(guān)，首屏?xí)r間過(guò)長(zhǎng)將影響用戶(hù)體驗(yàn)，導(dǎo)致用戶(hù)流失率升高，降低用戶(hù)對(duì)小程序黏性。所以解決小程序性能損耗問(wèn)題是提升小程序用戶(hù)使用度、加強(qiáng)用戶(hù)黏性一項(xiàng)非常重要的手段。

說(shuō)明：建議首屏?xí)r間不超過(guò) 3s。

可優(yōu)化時(shí)機(jī)

小程序啟動(dòng)過(guò)程中需要完成 3 步工作：

step1：運(yùn)行環(huán)境準(zhǔn)備

step2：下載、注入、解壓對(duì)應(yīng)小程序離線包

step3：渲染小程序首屏

而小程序開(kāi)發(fā)者可以在 step2、step3 中來(lái)優(yōu)化性能。

業(yè)務(wù)耗時(shí)常見(jiàn)問(wèn)題

小程序質(zhì)量團(tuán)隊(duì)在解決各小程序性能問(wèn)題中，對(duì)業(yè)務(wù)上耗時(shí)常見(jiàn)問(wèn)題進(jìn)行歸整，如下表所示。

優(yōu)化建議

控制小程序資源包大小

當(dāng)用戶(hù)訪問(wèn)一個(gè)小程序時(shí)，支付寶客戶(hù)端會(huì)首先從 CDN 下載小程序資源包，所以資源包大小會(huì)影響小程序啟動(dòng)性能。

隨著小程序離線包大小的上升，耗時(shí)也會(huì)相應(yīng)增加，主包大小將決定下載耗時(shí)高低。

優(yōu)化建議

1. 及時(shí)刪除無(wú)用的圖片資源，因?yàn)閳D片資源會(huì)默認(rèn)打包；

1. 及時(shí)清理無(wú)用代碼；

1. 使用 分包 進(jìn)行包大小優(yōu)化；

說(shuō)明：建議主包大小不超過(guò) 1M

控制小程序圖片大小

圖片資源是小程序加載資源項(xiàng)中應(yīng)用范圍最廣、影響最大的一部分，除去對(duì)啟動(dòng)過(guò)程中包資源大小的影響，還體現(xiàn)在 API 網(wǎng)絡(luò)請(qǐng)求中對(duì)圖片資源的加載。

在治理過(guò)程中我們發(fā)現(xiàn)，圖片的優(yōu)化不能僅僅存在于小程序的上線環(huán)節(jié)，后續(xù)活動(dòng)的投放、運(yùn)營(yíng)圖片的變更場(chǎng)景上也存在，所以圖片資源治理建議長(zhǎng)期保持，持續(xù)對(duì)待。

優(yōu)化建議

1. 避免使用大圖，壓縮圖片大小。

說(shuō)明：建議圖片資源大小不超過(guò) 60KB。

1. 根據(jù)顯示區(qū)域大小合理控制圖片大小。

說(shuō)明：建議圖片寬高不超過(guò)實(shí)際顯示寬高的 3 倍。

1. 格式轉(zhuǎn)化，可將圖片格式轉(zhuǎn)化成 SVG/webp。

1. 大圖建議從 CDN 渠道上傳，且并發(fā)加載數(shù)量需要控制，可考慮使用雪碧圖技術(shù)或在屏幕外的圖片使用懶加載。

說(shuō)明：建議每秒發(fā)起的圖片請(qǐng)求不超過(guò) 20 個(gè)。

1. 圖片開(kāi)啟 HTTP 緩存控制，下次加載同樣圖片，直接從緩存讀取。

首屏數(shù)據(jù)緩存

官方文檔提供 my.setStorage / my.getStorage 等異步讀寫(xiě)本地緩存的能力，數(shù)據(jù)存儲(chǔ)在本地，返回的會(huì)比網(wǎng)絡(luò)請(qǐng)求快。對(duì)于部分網(wǎng)絡(luò)請(qǐng)求數(shù)據(jù)，可優(yōu)先從緩存中獲取數(shù)據(jù)來(lái)渲染視圖，等待網(wǎng)絡(luò)請(qǐng)求返回后進(jìn)行更新。

優(yōu)化建議

網(wǎng)絡(luò)請(qǐng)求影響視圖渲染的數(shù)據(jù)，可設(shè)置數(shù)據(jù)緩存，存儲(chǔ)本地。

將數(shù)據(jù)請(qǐng)求提前至 onLoad

小程序運(yùn)行中，會(huì)先觸發(fā)頁(yè)面的 onLoad 生命周期函數(shù)，再將頁(yè)面初始數(shù)據(jù)（Page data）從 worker 傳遞到 web-view 進(jìn)行一次初始渲染。

頁(yè)面初始渲染完成，從 web-view 發(fā)出通知到 worker，觸發(fā) onReady 生命周期函數(shù)。

部分小程序會(huì)在 onReady 中發(fā)出請(qǐng)求，導(dǎo)致首屏渲染延緩。

優(yōu)化建議

將數(shù)據(jù)請(qǐng)求提前到 onLoad 中。

控制接口同步調(diào)用

小程序接口使用太多的同步調(diào)用方式，也會(huì)造成加載耗時(shí)被拉長(zhǎng)。同步 API 的使用過(guò)多將造成進(jìn)程的阻塞，影響后續(xù)業(yè)務(wù)邏輯的執(zhí)行。

getSystemInfo 獲取系統(tǒng)信息、getStorage 緩存等是業(yè)務(wù)方最常見(jiàn)會(huì)引起同步調(diào)用的 API，同時(shí)還有業(yè)務(wù)相關(guān)邏輯的 getLocation、getCities 等 API 也是同步調(diào)用的 高發(fā)區(qū)。

優(yōu)化建議

API 同步執(zhí)行轉(zhuǎn)化成異步執(zhí)行。

控制接口單次耗時(shí)

接口耗時(shí)太長(zhǎng)會(huì)讓用戶(hù)一直等待甚至離開(kāi)，接口的耗時(shí)有小程序 API 調(diào)用耗時(shí)、頁(yè)面渲染耗時(shí)，同時(shí)也有服務(wù)器處理時(shí)間。

分析數(shù)據(jù)中發(fā)現(xiàn)，mtop/request/rpc 等網(wǎng)絡(luò)請(qǐng)求慢、setData 傳輸數(shù)據(jù)過(guò)多是耗時(shí)長(zhǎng)的主要原因，同時(shí)有部分 API 容易造成耗時(shí)長(zhǎng)，例如 getLocation、getSystemInfo 等。

優(yōu)化建議

1. 處理好服務(wù)器處理時(shí)間，可減少回包大小，可服務(wù)端 rpc/mtop/http 等網(wǎng)絡(luò)請(qǐng)求預(yù)加載，讓請(qǐng)求快速響應(yīng)。

說(shuō)明：建議網(wǎng)絡(luò)請(qǐng)求接口單次耗時(shí)不超過(guò) 600ms。

1. 縮短單個(gè) API 接口的耗時(shí)時(shí)長(zhǎng)。

說(shuō)明：建議小程序接口單次耗時(shí)不超過(guò) 200ms。

控制接口調(diào)用次數(shù)

數(shù)據(jù)分析中發(fā)現(xiàn)小程序啟動(dòng)過(guò)程中有相當(dāng)多接口有多次、重復(fù)以及串行調(diào)用的情況。

• 多次調(diào)用：指 API 接口前方執(zhí)行完畢后，單頁(yè)面后續(xù)繼續(xù)執(zhí)行同名 API 情況，如獲取系統(tǒng)信息（getSystemInfo）/獲取用戶(hù)授權(quán)（getAuthCode）/獲取用戶(hù)信息（getUserInfo）/獲取客戶(hù)端信息（getClientInfo）等 API 接口多次調(diào)用；
• 重復(fù)調(diào)用：指 API 接口多次調(diào)用中，存在著重復(fù)請(qǐng)求的情況，最常見(jiàn)的是多次網(wǎng)絡(luò)請(qǐng)求 request 而其中 url 相同；
• 串行調(diào)用：指 API 交替使用，該使用方式極不規(guī)范且追加無(wú)用耗時(shí)，如設(shè)置緩存（setStorage）/獲取緩存（getStorage）等 API 接口串行交替調(diào)用。

優(yōu)化建議

1. 減少單頁(yè)面同名接口調(diào)用次數(shù)。

說(shuō)明：建議單頁(yè)面業(yè)務(wù)相關(guān) API 接口調(diào)用次數(shù)不超過(guò) 3 次，網(wǎng)絡(luò)請(qǐng)求接口不超過(guò) 10 次。

1. 采用緩存方式處理，將前一執(zhí)行接口后的結(jié)果數(shù)據(jù)以緩存形式保存。

1. 杜絕 API 串行交替調(diào)用的方式，減少冗余耗時(shí)。

控制 setData 渲染節(jié)點(diǎn)數(shù)量和大小

業(yè)務(wù)請(qǐng)求返回后，會(huì)調(diào)用 setData 觸發(fā)頁(yè)面重新渲染，可參考如下執(zhí)行過(guò)程：

1. 數(shù)據(jù)從 worker 傳遞到 web-view。
2. web-view 上根據(jù)傳過(guò)來(lái)的數(shù)據(jù)構(gòu)造虛擬 DOM，并與之前做差異比較（從根節(jié)點(diǎn)開(kāi)始），然后渲染。

由于 worker 與 web-view 通信時(shí)，數(shù)據(jù)需要序列化，然后到了 web-view 需要執(zhí)行 evaluateJavascript，因此如果一次性傳輸數(shù)據(jù)太大，會(huì)影響首屏渲染性能。

另外，如果 web-view 上構(gòu)造節(jié)點(diǎn)過(guò)多，層級(jí)嵌套太深，例如有的小程序列表頁(yè)面一次性渲染超過(guò) 100 個(gè)列表項(xiàng)，每個(gè)列表項(xiàng)又有嵌套內(nèi)容，而實(shí)際上整個(gè)屏幕可能只是顯示不到 10 個(gè)， 會(huì)導(dǎo)致差異比較時(shí)間較長(zhǎng)，同時(shí)由于是首屏渲染，會(huì)一次性構(gòu)造很多 DOM，影響首屏渲染性能。

優(yōu)化建議

1. setData 數(shù)據(jù)量不宜過(guò)大，避免一次性傳遞過(guò)長(zhǎng)的列表。

說(shuō)明：建議 setData 的數(shù)據(jù)在 JSON.stringify 后不超過(guò) 256KB。

1. 首屏請(qǐng)勿一次性構(gòu)造太多節(jié)點(diǎn)，服務(wù)端可能一次請(qǐng)求傳遞大量數(shù)據(jù)，請(qǐng)勿一次性 setData，可先 setData 一部分?jǐn)?shù)據(jù)，然后等待一段時(shí)間（比如 400ms，具體需要業(yè)務(wù)調(diào)節(jié)）再調(diào)用 $spliceData 將其他數(shù)據(jù)傳輸過(guò)去。

1. setData 接口調(diào)用頻率減少，避免無(wú)用的頻繁調(diào)用。

說(shuō)明：建議 setData 單頁(yè)面調(diào)用次數(shù)不超過(guò) 20 次。

附錄A：優(yōu)化 setData 邏輯方案明細(xì)

工具說(shuō)明

針對(duì)上述可優(yōu)化點(diǎn)的檢測(cè)，小程序質(zhì)量團(tuán)隊(duì)推薦如下性能分析工具：商家自審核/性能調(diào)試，協(xié)助廣大開(kāi)發(fā)者對(duì)小程序進(jìn)行性能缺陷的識(shí)別和分析。

附錄B：商家自審核工具使用

附錄C：性能調(diào)試工具使用