寫在前面

如何定義好的體驗(yàn)

過去我們定義這個(gè)問題，更多的是從頁面加載速度和流暢度去解釋，但這還遠(yuǎn)遠(yuǎn)不夠。加載速度的提升是否讓用戶更愿意“玩”了，流暢度提升是否也提升了模塊曝光和成交。

為了有更立體的衡量標(biāo)準(zhǔn)，有了如下設(shè)想：頁面加載速度和流暢度提升（技術(shù)視角）-> 用戶跳失率下降（用戶視角）-> 商品曝光和點(diǎn)擊上漲（平臺(tái)視角）

困境

下面是一些 TOP 二、三方業(yè)務(wù)的性能數(shù)據(jù)（數(shù)據(jù)取自2020年5月），可以說比較糟糕。（“跳失”的定義為：用戶打開小程序后，頁面渲染未完成或未達(dá)到產(chǎn)生交互的條件就退出頁面）

• 復(fù)雜的技術(shù)架構(gòu)

小程序在邏輯/渲染分離的架構(gòu)下，保證了開放安全的同時(shí)，也引入了更大的性能挑戰(zhàn)。

• 三方生態(tài)的質(zhì)量和安全

小程序是淘寶開放體系中的重要一環(huán)，面向商家和外部開發(fā)者，給研發(fā)質(zhì)量保障、數(shù)據(jù)安全帶來了更大挑戰(zhàn)。

• 衡量指標(biāo)單一

過去我們定義這個(gè)問題，更多的是從頁面加載速度和流暢度去解釋，但這遠(yuǎn)遠(yuǎn)不夠。

破局

通過運(yùn)維數(shù)據(jù)標(biāo)準(zhǔn)化，貫穿研發(fā)->發(fā)布->上線流程，形成數(shù)據(jù)閉環(huán)：

1. 數(shù)據(jù)采集：定義采集算法、數(shù)據(jù)模型，形成一套標(biāo)準(zhǔn)化運(yùn)維數(shù)據(jù)
2. 運(yùn)維平臺(tái)：連接二/三方開發(fā)者，提供數(shù)據(jù)透出和回流能力，定義監(jiān)控&卡口規(guī)則
3. 數(shù)據(jù)分析：科學(xué)的數(shù)據(jù)分析方法論，有實(shí)驗(yàn)、有數(shù)據(jù)、有證據(jù)
4. 效能工具：打通研發(fā)基礎(chǔ)設(shè)施，賦能開發(fā)者

數(shù)據(jù)采集

T2（首屏算法）

阿里集團(tuán)小程序?qū)R了首屏加載衡量口徑，采用UC內(nèi)核的T2首屏算法，T2指標(biāo)定義為 從頁面開始加載到頁面首次渲染滿屏內(nèi)容的時(shí)間。簡單說，是在頁面加載的過程中，記錄所有的渲染幀，待頁面加載結(jié)束之后，回溯檢查每一幀，圖片渲染面積首次達(dá)到最大值的一幀記為T2。

小程序性能模型

為了把小程序啟動(dòng)性能進(jìn)行分階段拆解，定義了小程序性能模型，從小程序啟動(dòng)開始到首屏渲染完成結(jié)束，拆解成了：Downloading（資源請求：元信息請求和包下載）、Launch（容器啟動(dòng)和小程序Runtime啟動(dòng)）、Rending（業(yè)務(wù)邏輯執(zhí)行和渲染）

同時(shí)，面向小程序開發(fā)者提供了標(biāo)準(zhǔn)的 Web API performance.mark()，支持開發(fā)者自定義打點(diǎn)。

通過分析各階段耗時(shí)，可以較為清晰的發(fā)現(xiàn)性能瓶頸。

數(shù)據(jù)分析和優(yōu)化實(shí)踐

篇幅有限，僅分享幾個(gè)經(jīng)典案例。

頁面性能與用戶跳失的關(guān)系

根據(jù)小程序加載性能和用戶跳失的直方圖，能更直觀的分析出小程序加載性能跟用戶跳失的關(guān)系。如下圖，可以看出當(dāng)小程序加載耗時(shí)超過2s時(shí)，跳失率程指數(shù)級(jí)增長。也正是基于這個(gè)結(jié)論，我們將小程序可交互時(shí)長的大盤目標(biāo)定為了1.8s。（其中橫軸表示可交互時(shí)長，縱軸表示跳失的用戶分布在該時(shí)間內(nèi)的占比）

小程序啟動(dòng)漏斗

小程序啟動(dòng)漏斗，能更直觀的分析出各階段耗時(shí)和跳失率/白屏率等指標(biāo)的關(guān)系。以下圖為例：

1. Downloading 請求階段耗時(shí)過長，是白屏率/跳失率的重要因素旗艦店小程序接入 資源預(yù)熱，Downloading 耗時(shí)縮短50%，階段跳失/白屏收窄至0.08%內(nèi)；
2. 業(yè)務(wù)數(shù)據(jù)請求耗時(shí)長

• 旗艦店小程序接入數(shù)據(jù)預(yù)取，店鋪框架數(shù)據(jù)請求耗時(shí)基本降為0，階段跳失/白屏基本降至0。

最佳實(shí)踐之：小程序引擎實(shí)例復(fù)用和預(yù)啟動(dòng)

1. 小程序進(jìn)程啟動(dòng)后，在空閑時(shí)機(jī)，會(huì)初始化并保留有且僅有一個(gè)通用的小程序 Engine 環(huán)境（與業(yè)務(wù)無關(guān)），直到小程序進(jìn)程被殺死；
2. 在運(yùn)行過程中，小程序 Engine 實(shí)例會(huì)在3個(gè)狀態(tài)之間切換：

• 可運(yùn)行：小程序進(jìn)程啟動(dòng)后，新創(chuàng)建的小程序Runtime環(huán)境為”可運(yùn)行“狀態(tài)；
• 運(yùn)行中：小程序業(yè)務(wù)啟動(dòng)時(shí)，將狀態(tài)為”可運(yùn)行“的實(shí)例取出使用，狀態(tài)變?yōu)椤斑\(yùn)行中"；
• 重置中：小程序業(yè)務(wù)關(guān)閉后，將使用過的實(shí)例取出，狀態(tài)變?yōu)椤敝刂弥小?；狀態(tài)重置完畢后，變?yōu)椤笨蛇\(yùn)行“狀態(tài)，供下個(gè)小程序使用。

最佳實(shí)踐之：數(shù)據(jù)預(yù)取2.0

根據(jù)小程序性能模型分析，在小程序啟動(dòng)過程中，Worker啟動(dòng)總是快于Render完成（Worker 處于空閑狀態(tài)），Worker 空閑時(shí)長分布如下：

• 可以看出，線上有92.2%的概率會(huì)發(fā)生Worker閑置，閑置時(shí)長集中在300-500ms，可以完成1-2次網(wǎng)絡(luò)請求；
• 閑置 Worker 具備了完備的小程序 JS 執(zhí)行能力，可在受限范圍內(nèi)執(zhí)行小程序 JSAPI，發(fā)送網(wǎng)絡(luò)請求獲取定位信息/系統(tǒng)信息等；

• 動(dòng)態(tài)預(yù)取優(yōu)點(diǎn)

• 靈活：環(huán)境具備JS執(zhí)行能力，更靈活
• 豐富：提供受限的 JSAPI 調(diào)用能力
• 安全：支持權(quán)限管控，面向三方開放更安全

最佳實(shí)踐之：基于模板的快照渲染

• 快照渲染能夠提升頁面二次打開性能，但在旗艦店場景下存在如下弊端：

（1）數(shù)據(jù)真實(shí)性：快照渲染使用了上次打開時(shí)的老數(shù)據(jù)，會(huì)先展示舊內(nèi)容再刷新；

（2）磁盤占用和命中率：旗艦店屬于模板類小程序，有百萬數(shù)量級(jí)的實(shí)例化小程序，快照渲染會(huì)為每家店鋪生成不同的快照文件；龐大的基數(shù)條件下，再考慮磁盤占用建立的淘汰機(jī)制，使得快照命中率較低；

（3）長尾問題：訪問頻次較低的長尾店鋪，同一用戶二次訪問的概率較低，無法命中快照；

• 為解決上述問題，實(shí)現(xiàn)了”基于模板的快照渲染（Template Snapshot）“。基于模板小程序生成快照文件并將數(shù)據(jù)剔除，在快照渲染時(shí)，配合數(shù)據(jù)預(yù)取將真實(shí)數(shù)據(jù)插入模板中。既能保證數(shù)據(jù)真實(shí)性，同時(shí)可讓所有店鋪共享同一快照文件，最大限度的提高快照命中率和降低磁盤占用。

工具和平臺(tái)

建立標(biāo)準(zhǔn)化運(yùn)維數(shù)據(jù)，輸出到不同場景，貫穿整個(gè)研發(fā)和上線流程：

• 工具側(cè)：提供性能調(diào)試工具，幫助開發(fā)者快速分析和解決問題
• 發(fā)布卡口：設(shè)置發(fā)布前質(zhì)量卡口和靜態(tài)掃描，避免業(yè)務(wù)帶病上線
• 線上監(jiān)控：通過小程序運(yùn)維平臺(tái)，承擔(dān)日常高可用數(shù)據(jù)的監(jiān)控和告警職責(zé)

數(shù)據(jù)效果

經(jīng)歷漫長的優(yōu)化周期，數(shù)據(jù)結(jié)果上，淘寶小程序大盤T2指標(biāo)由 2.7s優(yōu)化至1.9s；旗艦店首屏大盤從 4s+提升至1.8s。

同時(shí)，為了驗(yàn)證體驗(yàn)優(yōu)化對業(yè)務(wù)數(shù)據(jù)的正向效果，對旗艦店業(yè)務(wù)做了分桶實(shí)驗(yàn)，數(shù)據(jù)證明也收獲了不錯(cuò)的業(yè)務(wù)效果。

下圖是Top二、三方業(yè)務(wù)優(yōu)化前后的數(shù)據(jù)對比：