支付寶小程序擴展能力 性能解決方案

名詞解釋

背景

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

首屏?xí)r間

首屏?xí)r間定義是指用戶開始嘗試打開小程序到小程序首屏加載完成的時長。

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

說明：建議首屏?xí)r間不超過 3s。

可優(yōu)化時機

小程序啟動過程中需要完成 3 步工作：

step1：運行環(huán)境準備

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

step3：渲染小程序首屏

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

業(yè)務(wù)耗時常見問題

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

優(yōu)化建議

控制小程序資源包大小

當用戶訪問一個小程序時，支付寶客戶端會首先從 CDN 下載小程序資源包，所以資源包大小會影響小程序啟動性能。

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

優(yōu)化建議

1. 及時刪除無用的圖片資源，因為圖片資源會默認打包；

1. 及時清理無用代碼；

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

說明：建議主包大小不超過 1M

控制小程序圖片大小

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

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

優(yōu)化建議

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

說明：建議圖片資源大小不超過 60KB。

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

說明：建議圖片寬高不超過實際顯示寬高的 3 倍。

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

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

說明：建議每秒發(fā)起的圖片請求不超過 20 個。

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

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

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

優(yōu)化建議

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

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

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

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

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

優(yōu)化建議

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

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

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

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

優(yōu)化建議

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

控制接口單次耗時

接口耗時太長會讓用戶一直等待甚至離開，接口的耗時有小程序 API 調(diào)用耗時、頁面渲染耗時，同時也有服務(wù)器處理時間。

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

優(yōu)化建議

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

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

1. 縮短單個 API 接口的耗時時長。

說明：建議小程序接口單次耗時不超過 200ms。

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

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

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

優(yōu)化建議

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

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

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

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

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

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

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

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

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

優(yōu)化建議

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

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

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

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

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

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

工具說明

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

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

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