前幾日作者在掘金上看到了【微信小程序性能優(yōu)化】這篇文章，當時心想這個團隊做的事情和我們方向很相似，仔細一看原來是微信公開課上小程序專場中“小程序性能優(yōu)化”模塊的記錄，而其中我們提出的建議（獨立分包）也即將發(fā)布。借著這個機會，我們也決定把在掃碼付小程序中的一些優(yōu)化實踐分享出來。作者： 

@陳小二

 

@simpxu

什么是掃碼付小程序？

美團掃碼付小程序是一款面向C端消費者推出的線下收單業(yè)務。它寄托在美團小程序下，在實際場景中，用戶先使用微信掃一掃掃描商家二維碼，接著調(diào)起掃碼付小程序，進入支付頁后輸入金額向商家完成商品支付。

 

我們的目標？

我們一直在做一件事情：提升掃碼付小程序的支付轉化率。這里所提的支付轉化率指：整個業(yè)務流程中用戶成功支付到掃碼的占比。支付轉化率與掃碼付業(yè)務來講，百分比越高，掃碼付業(yè)務的營業(yè)額收入越高，帶來的收益是成正比的。

而這部分轉化率流失的影響，我們認為包含兩個部分：

• 掃碼到進入小程序環(huán)節(jié)（外部環(huán)節(jié)）
• 進入小程序到支付環(huán)節(jié)（內(nèi)部環(huán)節(jié)）
  
  在掃碼到進入小程序環(huán)節(jié)，微信會完成小程序基本信息獲取、資源準備（代碼下載或更新）等準備事項，在準備事項中若準備失敗或時間過長會導致用戶手動離開，這部分由微信控制的環(huán)節(jié)稱之為外部環(huán)節(jié)；在進入小程序到支付環(huán)節(jié)，頁面會進行渲染、數(shù)據(jù)請求等，如果渲染時間長、數(shù)據(jù)請求時間長也易導致用戶手動離開，而數(shù)據(jù)請求失敗也會造成用戶使用流程終止而離開，這部分由我們自己控制的環(huán)節(jié)稱之為內(nèi)部環(huán)節(jié)。

如何提升外部環(huán)節(jié)轉化率？

對于小程序開發(fā)者而言，掃碼到小程序調(diào)起這個環(huán)節(jié)是黑盒的，我們無法得知此處的細節(jié)。而我們在掃碼付小程序中嘗試和微信的同學做了一次梳理，發(fā)現(xiàn)掃碼付小程序在外部環(huán)節(jié)的丟失率較高，查詢數(shù)據(jù)發(fā)現(xiàn)其中大部分用戶手動點擊了右上角的退出。從業(yè)務出發(fā)，用戶使用掃碼付可以認為用戶是有強需求進行支付，能夠造成用戶手動點擊退出的行為部分原因可能來自于等待時間較長，而在這個環(huán)節(jié)對時間造成影響更多的是資源準備，即小程序代碼下載或者更新的行為。

影響下載和更新時間可能的因素有：

• 網(wǎng)絡
• 代碼包

用戶網(wǎng)絡是我們無法控制的，只能嘗試從代碼包開始下手。而在當時未使用分包的情況下，我們的主包大小約3M，意味著新用戶和無緩存小程序用戶均需要在首次使用時等待下載3M左右的包大小，在這種情況下雖然用戶享受了小程序離線緩存包的福利，卻丟失了大部分新用戶的體驗。于是我們嘗試從包代碼大小做了一些優(yōu)化：

• 增加分包加載機制。用戶在使用掃碼付業(yè)務時會按需進行加載，優(yōu)化小程序首次啟動的下載時間。
• 減小主包和分包大小。按照空主包的概念進行優(yōu)化。在進行分包加載機制后，主包無法最小化依然影響首次下載時間。一方面，原有的3M整包中，圖片大小占用了50%大小，我們將所有的內(nèi)含二進制和Base64圖片分發(fā)到了CDN；另一方面，部分可移出的業(yè)務分發(fā)到了其他分包。

在做了這些事情后，掃碼付分包從原先的整包3M縮減到了361k(主包300k+分包61)，而外部環(huán)節(jié)的轉化率也提升了3%。雖然轉化率提升了，但前置環(huán)節(jié)的轉化率仍然有部分丟失，理論上繼續(xù)縮減300k的主包能有效提升，但由于業(yè)務性質(zhì)的原因無法再繼續(xù)縮減，于是我們向微信小程序提出了獨立分包的概念:用戶在使用獨立分包時無需下載主包。通過獨立分包加載，程序使用期間下載更新階段只需要加載61k的分包大小，目前這個功能還在內(nèi)測階段，掃碼付小程序也在作為第一批的內(nèi)測用戶進行體驗，優(yōu)化效果在之后的實踐中我們也會分享出來。

如何提升內(nèi)部環(huán)節(jié)轉化率？

在進入小程序到支付這個環(huán)節(jié)，屬于我們的業(yè)務流程。在這個環(huán)節(jié)中的轉化率丟失雖然是我們能掌控的，但我們并無頭緒，所以我們做了一些數(shù)據(jù)監(jiān)控來尋求方法：

• 業(yè)務核心流程監(jiān)控。業(yè)務核心流程指用戶進入小程序后所涉及到的影響最終支付的中間流程，中間流程的丟失直接影響業(yè)務整個轉化率丟失，所以它們是必須監(jiān)控的。而業(yè)務核心流程監(jiān)控需要可監(jiān)控的具體指標，我們對進入小程序和支付進行了關鍵動作拆解，從掃碼到用戶看到頁面、再到點擊支付、初始化訂單、支付成功。拆解完這些關鍵動作，再針對每一步可控環(huán)節(jié)，進行技術指標的拆解。從入口到出口的每一步制定關鍵指標（掃碼加載轉化率、點擊意愿等，見下圖），形成一個至上而下的漏斗，產(chǎn)出多個可量化指標，來做業(yè)務流程的監(jiān)控。對于這部分可量化指標，通過長期的觀察分析來提升轉化率。

 

• 異常監(jiān)控。頁面的任何異常都可能導致支付頁面的渲染失敗，從而無法正常支付。我們對頁面的接口異常、微信API異常進行了監(jiān)控。接口異?？稍贏PI（wx.request)的fail函數(shù)中直接捕獲，從而上報監(jiān)控；對于接口超時，則只能通過全局的app.json進行全局設置（默認60s，時間過長，對用戶體驗較差），此前我們曾嘗試在小程序中設置全局的5s請求超時，但實際應用中并非所有場景需要設置統(tǒng)一的超時，最終我們單獨封裝了接口請求超時。微信API的異常通過微信的一些fail中進行監(jiān)控即可。
• 性能監(jiān)控。小程序內(nèi)部轉化環(huán)節(jié)中關注進入小程序后的白屏時間和可交互時間。內(nèi)部白屏時間從onLoad處打點，到頁面onReady處結束；內(nèi)部可交互時間從onLoad處打去kjnpl0o09o0點，到頁面數(shù)據(jù)請求結束后的可點擊支付時間截止。

日常監(jiān)控中，我們也發(fā)現(xiàn)了一些問題，例如接口調(diào)用超時、接口調(diào)用失敗，這些問題會導致頁面流程終止。針對這些問題，做了一些優(yōu)化：

• 接口合并。支付頁面的外網(wǎng)鏈路接口請求數(shù)量較多，任意一個接口的失敗都會導致問題，合并接口則可以減少問題出現(xiàn)概率，提升中間流程的轉化率。
• 增加重試機制。在出現(xiàn)接口異常的情況下，會直接導致頁面阻塞，如果通過重試能成功，則可以提升轉化率。整個流程中可重試的有兩類：

自有的接口請求異常
小程序API調(diào)用異常

對于這兩類異常，在接口超時、調(diào)用失敗時采取重試。而為了避免在極端情況下服務端流量陡增、峰值倍數(shù)增加，頁面的可重試次數(shù)會在前置獲取全局配置時根據(jù)“可重試次數(shù)”控制，并且每次重試需要在一段時間后用戶手動觸發(fā)。超過重試次數(shù)時，則流程終止。

如何監(jiān)控內(nèi)部和外部環(huán)節(jié)？

前面我們也提到，對于小程序開發(fā)者而言，掃碼到小程序調(diào)起這個環(huán)節(jié)是黑盒的，我們開發(fā)者無法得知此處的細節(jié)，所以說在監(jiān)控外部環(huán)節(jié)這方面我們開發(fā)者似乎可做的事情屈指可數(shù)。但是，不知道細心的同學有沒有發(fā)現(xiàn)，微信在每次掃碼后會給我們在query參數(shù)上附帶一個scancode_time字段。其實這個字段表示的是用戶在使用掃一掃時微信服務端記錄的時間，所以基于這個字段的考量，我們做了如下嘗試，針對以下兩個參數(shù)值分別做了實時監(jiān)控：

• 支付頁面的白屏時間（用戶看到首屏的客戶端時間—用戶微信掃一掃服務端時間+服務端客戶端差額時間）
• 支付頁面的用戶可交互時間（頁面Loading完畢時間—用戶微信掃一掃服務端時間+服務端客戶端差額時間）
  
  Tips：由于客戶端的時間戳是獲取本地手機系統(tǒng)的時間，可能存在差異。所以為了保證上報的準確性，我們在每次onLoad的時候取了一次我們服務端的時間，記錄了客戶端的時間與服務端的一個時間差額，并且在后續(xù)所有涉及到服務端的時間都參照這個時間差額做計算（網(wǎng)絡100-200ms級別的傳輸時延暫可忽略）

但由于我們掃碼付小程序的特殊應用場景就是為了保障用戶進行快速可靠的支付，既然在外部環(huán)節(jié)可控度不高，那是不是可以考慮在內(nèi)部的業(yè)務流程方面把監(jiān)控統(tǒng)計做的細粒度一點，做到能對每一個可能影響到支付的環(huán)節(jié)有數(shù)據(jù)可循呢？所以我們針對這個方向，區(qū)別于傳統(tǒng)的pv、uv統(tǒng)計，對業(yè)務上報做了如下分類：

• 根據(jù)上報的場景劃分：實時性監(jiān)控部分與統(tǒng)計部分
• 根據(jù)上報的類型劃分：Error類型、Event類型（普通生命周期事件）、Metric類型（自定義Event類型，維度可自定義）、自定義測速類型（延時趨勢與分布）

基于上述方案的探索，我們小組基本上做到了對可能影響支付環(huán)節(jié)的某些業(yè)務指標的把控。從而在下一步，可以針對每個潛在的可優(yōu)化點做進一步思考與考量，作出及時的策略優(yōu)化與更新。