美團掃碼付小程序開發(fā)實踐,美團掃碼購小程序開發(fā)實例

短短幾年的時間，微信小程序已經(jīng)從一顆小小的萌芽成長為參天大樹，形成了較大規(guī)模的開發(fā)者生態(tài)系統(tǒng)，尤其是在支付、線下垂直領(lǐng)域潛力巨大。

作為領(lǐng)先的生活服務(wù)平臺，美團的技術(shù)團隊在小程序領(lǐng)域也進行了很多的探索和實踐。像mpvue就是一款使用Vue.js開發(fā)微信小程序的前端框架，而且已經(jīng)在美團點評多個實際業(yè)務(wù)項目中得到了驗證，詳細(xì)介紹大家可以閱讀《 用Vue.js開發(fā)微信小程序：開源框架mpvue解析 》一文。目前，mpvue已經(jīng)開源，項目地址是： https://github.com/Meituan-Dianping/mpvue。

本文將介紹掃碼付小程序的實踐，根據(jù)美團前端工程師陳瑤在美團第31期技術(shù)沙龍（點擊可以查看這次沙龍四場演講的Slides和視頻）的演講《金融掃碼付H5遷移小程序拓荒之旅》整理而成。

美團掃碼付是一款面向C端消費者推出的線下收單業(yè)務(wù)，相信大家已經(jīng)在線下很多餐館和其他生活服務(wù)商家體驗過了。這項業(yè)務(wù)主要就是通過小程序提供服務(wù)的，而在實際場景中，用戶先使用微信“掃一掃”功能，掃描商家二維碼，系統(tǒng)會自動調(diào)用掃碼付小程序，進入支付頁面，最后輸入金額完成商品的支付。

支付服務(wù)最核心的指標(biāo)，顯然就是用戶支付成功的占比，我們稱之為支付轉(zhuǎn)化率。對掃碼付業(yè)務(wù)而言，支付轉(zhuǎn)化率的百分比越高，掃碼付業(yè)務(wù)的營業(yè)額也就越高，其帶來的收益是正相關(guān)的。因此提升掃碼付小程序的支付轉(zhuǎn)化率，就成為我們技術(shù)團隊的重要工作。經(jīng)過數(shù)據(jù)分析，我們發(fā)現(xiàn)轉(zhuǎn)化率流失主要存在于以下兩個環(huán)節(jié)：

• 掃碼到進入小程序環(huán)節(jié)（外部環(huán)節(jié)）
• 進入小程序到支付環(huán)節(jié)（內(nèi)部環(huán)節(jié)）

從掃碼到進入小程序環(huán)節(jié)，微信會完成小程序基本信息獲取、資源準(zhǔn)備（代碼下載或更新）等準(zhǔn)備事項。在準(zhǔn)備事項中，如果準(zhǔn)備失敗或等待時間過長，就會導(dǎo)致用戶離開，這部分由微信控制的環(huán)節(jié)，我們稱之為外部環(huán)節(jié)。

在進入小程序到支付環(huán)節(jié)，頁面會進行渲染、數(shù)據(jù)請求等，如果渲染時間長、數(shù)據(jù)請求時間長也容易導(dǎo)致用戶離開，同樣，如果數(shù)據(jù)請求失敗也會造成用戶使用過程的終止，這部分由我們美團掃碼付技術(shù)團隊控制的環(huán)節(jié)，稱之為內(nèi)部環(huán)節(jié)。

對于小程序開發(fā)者而言，掃碼到小程序調(diào)起這個環(huán)節(jié)是黑盒的，我們無法得知其中的細(xì)節(jié)。而我們在掃碼付小程序中嘗試和微信的同學(xué)做了一次梳理，發(fā)現(xiàn)掃碼付小程序在外部環(huán)節(jié)的丟失率較高，查詢數(shù)據(jù)后，我們發(fā)現(xiàn)其中大部分用戶手動點擊了右上角的退出。

從業(yè)務(wù)視角出發(fā)，用戶使用掃碼付小程序，可認(rèn)為他們有強需求進行支付，而造成用戶手動點擊退出的部分原因可能是等待時間過長。而在這個環(huán)節(jié)對時間造成影響更多的是資源準(zhǔn)備，即小程序代碼下載或者更新的行為。根據(jù)經(jīng)驗，影響下載和更新時間可能的因素包括兩個方面：一個是網(wǎng)絡(luò)，另一個是代碼包。

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

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

在做了這些事情后，掃碼付分包從原先的整包3M縮減到了361K（主包300K+分包61K），而外部環(huán)節(jié)的轉(zhuǎn)化率也提升了3%。雖然轉(zhuǎn)化率提升了，但前置環(huán)節(jié)的轉(zhuǎn)化率仍然有部分丟失，理論上繼續(xù)縮減300K的主包能有效提升，但由于業(yè)務(wù)性質(zhì)的原因無法再繼續(xù)縮減，于是我們向微信小程序提出了獨立分包的概念：用戶在使用獨立分包時無需下載主包。

通過獨立分包加載，程序使用期間下載更新階段，只需要加載61K的分包大小。目前這個功能還在灰度階段，掃碼付小程序團隊也在作為第一批的內(nèi)測用戶進行體驗，優(yōu)化效果在之后的實踐中，我們也會分享出來，大家可關(guān)注美團技術(shù)團隊公眾號，持續(xù)關(guān)注我們。

在進入小程序到支付這個環(huán)節(jié)，屬于我們的業(yè)務(wù)流程。在這個環(huán)節(jié)中的轉(zhuǎn)化率丟失雖然我們能夠掌控，但是必須有所依據(jù)，才能對癥下藥。所以我們做了一些數(shù)據(jù)監(jiān)控：

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

• 異常監(jiān)控。頁面的任何異常都可能導(dǎo)致支付頁面的渲染失敗，從而無法正常支付。我們對頁面的接口異常、微信API異常進行了監(jiān)控。接口異?？稍贏PI（wx.request）的fail函數(shù)中直接捕獲，從而上報監(jiān)控；對于接口超時，則只能通過全局的app.json進行全局設(shè)置（默認(rèn)60s，時間過長，對用戶體驗較差），此前我們曾嘗試在小程序中設(shè)置全局的5s請求超時，但實際應(yīng)用中并非所有場景需要設(shè)置統(tǒng)一的超時，最終我們單獨封裝了接口請求超時。微信API的異常通過微信的一些fail中進行監(jiān)控即可。

• 性能監(jiān)控。小程序內(nèi)部轉(zhuǎn)化環(huán)節(jié)中關(guān)注進入小程序后的白屏?xí)r間和可交互時間。內(nèi)部白屏?xí)r間從onLoad處打點，到頁面onReady處結(jié)束；內(nèi)部可交互時間從onLoad處打點，到頁面數(shù)據(jù)請求結(jié)束后的可點擊支付時間截止。

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

• 接口合并。支付頁面的外網(wǎng)鏈路接口請求數(shù)量較多，任意一個接口的失敗都會導(dǎo)致問題，合并接口則可以減少問題出現(xiàn)概率，提升中間流程的轉(zhuǎn)化率。

• 增加重試機制。在出現(xiàn)接口異常的情況下，會直接導(dǎo)致頁面阻塞，如果通過重試能成功，則可以提升轉(zhuǎn)化率。整個流程中可重試的有兩類：自有的接口請求異常，小程序API調(diào)用異常。

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

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

• 支付頁面的白屏?xí)r間（用戶看到首屏的客戶端時間—用戶微信掃一掃服務(wù)端時間+服務(wù)端客戶端差額時間）。
• 支付頁面的用戶可交互時間（頁面Loading完畢時間—用戶微信掃一掃服務(wù)端時間+服務(wù)端客戶端差額時間）。

由于客戶端的時間戳是獲取本地手機系統(tǒng)的時間，可能存在差異。所以為了保證上報的準(zhǔn)確性，我們在每次onLoad的時候取了一次我們服務(wù)端的時間，記錄了客戶端的時間與服務(wù)端的一個時間差額，并且在后續(xù)所有涉及到服務(wù)端的時間都參照這個時間差額做計算（網(wǎng)絡(luò)100-200ms級別的傳輸時延，暫可忽略）。

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

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

基于上述方案的探索，我們團隊基本上做到了對可能影響支付環(huán)節(jié)的很多業(yè)務(wù)指標(biāo)，進行了整體的把控。從而在下一步，針對每個潛在的可優(yōu)化點做進一步思考與考量，然后作出及時的策略優(yōu)化與更新。通過對掃碼付小程序的探索，我們積累了很多優(yōu)化經(jīng)驗。美團的價值觀是追求卓越，對于能優(yōu)化的方面，我們還會進一步去探索，也歡迎更多的同學(xué)跟我們一起討論。