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

@陳小二

 

@simpxu

什么是掃碼付小程序？

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

 

我們的目標(biāo)？

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

而這部分轉(zhuǎn)化率流失的影響，我們認(rèn)為包含兩個(gè)部分：

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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