作者：莫緒旻(向嶼)
淘寶小程式已經走過若干個雙十一，淘寶開放業務有序鋪開。體驗優化是個老生常談的話題，如何讓小程式跑得又穩又快，成了我們最大的挑戰之一。
寫在前面
如何定義好的體驗
過去我們定義這個問題，更多的是從頁面載入速度和流暢度去解釋，但這還遠遠不夠。載入速度的提升是否讓使用者更願意“玩”了，流暢度提升是否也提升了模組曝光和成交。
為了有更立體的衡量標準，有了如下設想：頁面載入速度和流暢度提升（技術視角）-> 使用者跳失率下降（使用者視角）-> 商品曝光和點選上漲（平臺視角）
困境
下面是一些 TOP 二、三方業務的效能資料（資料取自2020年5月），可以說比較糟糕。（“跳失”的定義為：使用者開啟小程式後，頁面渲染未完成或未達到產生互動的條件就退出頁面）
複雜的技術架構
小程式在邏輯/渲染分離的架構下，保證了開放安全的同時，也引入了更大的效能挑戰。
三方生態的質量和安全
小程式是淘寶開放體系中的重要一環，面向商家和外部開發者，給研發質量保障、資料安全帶來了更大挑戰。
衡量指標單一
過去我們定義這個問題，更多的是從頁面載入速度和流暢度去解釋，但這遠遠不夠。
破局
通過運維資料標準化，貫穿研發->釋出->上線流程，形成資料閉環：
- 資料採集：定義採集演算法、資料模型，形成一套標準化運維資料
- 運維平臺：連線二/三方開發者，提供資料透出和迴流能力，定義監控&卡口規則
- 資料分析：科學的資料分析方法論，有實驗、有資料、有證據
- 效能工具：打通研發基礎設施，賦能開發者
資料採集
T2（首屏演算法）
阿里集團小程式對齊了首屏載入衡量口徑，採用UC核心的T2首屏演算法，T2指標定義為 從頁面開始載入到頁面首次渲染滿屏內容的時間。簡單說，是在頁面載入的過程中，記錄所有的渲染幀，待頁面載入結束之後，回溯檢查每一幀，圖片渲染面積首次達到最大值的一幀記為T2。
小程式效能模型
為了把小程式啟動效能進行分階段拆解，定義了小程式效能模型，從小程式啟動開始到首屏渲染完成結束，拆解成了：Downloading（資源請求：元資訊請求和包下載）、Launch（容器啟動和小程式Runtime啟動）、Rending（業務邏輯執行和渲染）
同時，面向小程式開發者提供了標準的 Web API performance.mark()，支援開發者自定義打點。
通過分析各階段耗時，可以較為清晰的發現效能瓶頸。
資料分析和優化實踐
篇幅有限，僅分享幾個經典案例。
頁面效能與使用者跳失的關係
根據小程式載入效能和使用者跳失的直方圖，能更直觀的分析出小程式載入效能跟使用者跳失的關係。如下圖，可以看出當小程式載入耗時超過2s時，跳失率程指數級增長。也正是基於這個結論，我們將小程式可互動時長的大盤目標定為了1.8s。（其中橫軸表示可互動時長，縱軸表示跳失的使用者分佈在該時間內的佔比）
小程式啟動漏斗
小程式啟動漏斗，能更直觀的分析出各階段耗時和跳失率/白屏率等指標的關係。以下圖為例：
- Downloading 請求階段耗時過長，是白屏率/跳失率的重要因素
a、旗艦店小程式接入 資源預熱，Downloading 耗時縮短50%，階段跳失/白屏收窄至0.08%內；
- 業務資料請求耗時長
a、旗艦店小程式接入資料預取，店鋪框架資料請求耗時基本降為0，階段跳失/白屏基本降至0。
最佳實踐之：小程式引擎例項複用和預啟動
- 小程式程式啟動後，在空閒時機，會初始化並保留有且僅有一個通用的小程式 Engine 環境（與業務無關），直到小程式程式被殺死；
- 在執行過程中，小程式 Engine 例項會在3個狀態之間切換：
a、可執行：小程式程式啟動後，新建立的小程式Runtime環境為”可執行“狀態；
b、執行中：小程式業務啟動時，將狀態為”可執行“的例項取出使用，狀態變為“執行中"；
c、重置中：小程式業務關閉後，將使用過的例項取出，狀態變為”重置中“；狀態重置完畢後，變為”可執行“狀態，供下個小程式使用。
最佳實踐之：資料預取2.0
根據小程式效能模型分析，在小程式啟動過程中，Worker啟動總是快於Render完成（Worker 處於空閒狀態），Worker 空閒時長分佈如下：
- 可以看出，線上有92.2%的概率會發生Worker閒置，閒置時長集中在300-500ms，可以完成1-2次網路請求；
- 閒置 Worker 具備了完備的小程式 JS 執行能力，可在受限範圍內執行小程式 JSAPI，傳送網路請求獲取定位資訊/系統資訊等；
- 動態預取優點
a、靈活：環境具備JS執行能力，更靈活
b、豐富：提供受限的 JSAPI 呼叫能力=
c、安全：支援許可權管控，面向三方開放更安全
最佳實踐之：基於模板的快照渲染
- 快照渲染能夠提升頁面二次開啟效能，但在旗艦店場景下存在如下弊端：
a、資料真實性：快照渲染使用了上次開啟時的老資料，會先展示舊內容再重新整理；
b、磁碟佔用和命中率：旗艦店屬於模板類小程式，有百萬數量級的例項化小程式，快照渲染會為每家店鋪生成不同的快照檔案；龐大的基數條件下，再考慮磁碟佔用建立的淘汰機制，使得快照命中率較低；
c、長尾問題：訪問頻次較低的長尾店鋪，同一使用者二次訪問的概率較低，無法命中快照；
- 為解決上述問題，實現了”基於模板的快照渲染（Template Snapshot）“。基於模板小程式生成快照檔案並將資料剔除，在快照渲染時，配合資料預取將真實資料插入模板中。既能保證資料真實性，同時可讓所有店鋪共享同一快照檔案，最大限度的提高快照命中率和降低磁碟佔用。
工具和平臺
建立標準化運維資料，輸出到不同場景，貫穿整個研發和上線流程：
- 工具側：提供效能除錯工具，幫助開發者快速分析和解決問題
- 釋出卡口：設定釋出前質量卡口和靜態掃描，避免業務帶病上線
- 線上監控：通過小程式運維平臺，承擔日常高可用資料的監控和告警職責
資料效果
經歷漫長的優化週期，資料結果上，淘寶小程式大盤T2指標由 2.7s優化至1.9s；旗艦店首屏大盤從 4s+提升至1.8s。
同時，為了驗證體驗優化對業務資料的正向效果，對旗艦店業務做了分桶實驗，資料證明也收穫了不錯的業務效果。
下圖是Top二、三方業務優化前後的資料對比：
關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！