短短几年的時間，微信小程式已經從一顆小小的萌芽成長為參天大樹，形成了較大規模的開發者生態系統，尤其是在支付、線下垂直領域潛力巨大。
作為領先的生活服務平臺，美團的技術團隊在小程式領域也進行了很多的探索和實踐。像mpvue就是一款使用Vue.js開發微信小程式的前端框架，而且已經在美團點評多個實際業務專案中得到了驗證，詳細介紹大家可以閱讀《用Vue.js開發微信小程式：開源框架mpvue解析》一文。目前，mpvue已經開源，專案地址是：https://github.com/Meituan-Dianping/mpvue。
本文將介紹掃碼付小程式的實踐，根據美團前端工程師陳瑤在美團第31期技術沙龍（點選可以檢視這次沙龍四場演講的Slides和視訊）的演講《金融掃碼付H5遷移小程式拓荒之旅》整理而成。
什麼是掃碼付小程式？
美團掃碼付是一款面向C端消費者推出的線下收單業務，相信大家已經線上下很多餐館和其他生活服務商家體驗過了。這項業務主要就是通過小程式提供服務的，而在實際場景中，使用者先使用微信“掃一掃”功能，掃描商家二維碼，系統會自動呼叫掃碼付小程式，進入支付頁面，最後輸入金額完成商品的支付。
目標及資料分析
支付服務最核心的指標，顯然就是使用者支付成功的佔比，我們稱之為支付轉化率。對掃碼付業務而言，支付轉化率的百分比越高，掃碼付業務的營業額也就越高，其帶來的收益是正相關的。因此提升掃碼付小程式的支付轉化率，就成為我們技術團隊的重要工作。經過資料分析，我們發現轉化率流失主要存在於以下兩個環節：
- 掃碼到進入小程式環節（外部環節）
- 進入小程式到支付環節（內部環節）
從掃碼到進入小程式環節，微信會完成小程式基本資訊獲取、資源準備（程式碼下載或更新）等準備事項。在準備事項中，如果準備失敗或等待時間過長，就會導致使用者離開，這部分由微信控制的環節，我們稱之為外部環節。
在進入小程式到支付環節，頁面會進行渲染、資料請求等，如果渲染時間長、資料請求時間長也容易導致使用者離開，同樣，如果資料請求失敗也會造成使用者使用過程的終止，這部分由我們美團掃碼付技術團隊控制的環節，稱之為內部環節。
如何提升外部環節轉化率？
對於小程式開發者而言，掃碼到小程式調起這個環節是黑盒的，我們無法得知其中的細節。而我們在掃碼付小程式中嘗試和微信的同學做了一次梳理，發現掃碼付小程式在外部環節的丟失率較高，查詢資料後，我們發現其中大部分使用者手動點選了右上角的退出。
從業務視角出發，使用者使用掃碼付小程式，可認為他們有強需求進行支付，而造成使用者手動點選退出的部分原因可能是等待時間過長。而在這個環節對時間造成影響更多的是資源準備，即小程式程式碼下載或者更新的行為。根據經驗，影響下載和更新時間可能的因素包括兩個方面：一個是網路，另一個是程式碼包。
因為使用者的網路是我們無法控制的，只能嘗試從程式碼包開始下手。而在當時未使用分包的情況下，我們的主包大小約為3M，這意味著新使用者和無快取小程式使用者均需要在首次使用時等待下載3M左右的包。在這種情況下，雖然使用者享受了小程式離線快取包的福利，卻丟失了大部分新使用者的體驗。於是我們嘗試從包程式碼層面做一些優化：
- 增加分包載入機制。使用者在使用掃碼付業務時會按需進行載入，優化小程式首次啟動的下載時間。
- 減小主包和分包大小。按照空主包的概念進行優化。在進行分包載入機制後，主包因為無法最小化而影響首次下載時間。一方面，原有的3M整包中，圖片大小佔用了50%大小，我們將所有的內含二進位制和Base64圖片分發到了CDN；另一方面，部分可移出的業務分發到了其他分包。
在做了這些事情後，掃碼付分包從原先的整包3M縮減到了361K（主包300K+分包61K），而外部環節的轉化率也提升了3%。雖然轉化率提升了，但前置環節的轉化率仍然有部分丟失，理論上繼續縮減300K的主包能有效提升，但由於業務性質的原因無法再繼續縮減，於是我們向微信小程式提出了獨立分包的概念：使用者在使用獨立分包時無需下載主包。
通過獨立分包載入，程式使用期間下載更新階段，只需要載入61K的分包大小。目前這個功能還在灰度階段，掃碼付小程式團隊也在作為第一批的內測使用者進行體驗，優化效果在之後的實踐中，我們也會分享出來，大家可關注美團技術團隊公眾號，持續關注我們。
如何提升內部環節轉化率？
在進入小程式到支付這個環節，屬於我們的業務流程。在這個環節中的轉化率丟失雖然我們能夠掌控，但是必須有所依據，才能對症下藥。所以我們做了一些資料監控：
- 業務核心流程監控。業務核心流程指使用者進入小程式後所涉及的影響最終支付的中間流程，中間流程的丟失會直接影響業務整個轉化率丟失，所以這裡必須進行監控。而業務核心流程監控需要可監控的具體指標，我們對進入小程式和支付進行了關鍵動作拆解，從開始掃碼到使用者看到頁面，再到點選支付、初始化訂單、支付成功。拆解完這些關鍵動作，再針對每一步可控環節，進行技術指標的拆解。從入口到出口的每一步制定關鍵指標（掃碼載入轉化率、點選意願等，見下圖），形成一個至上而下的漏斗，產出多個可量化指標，來做業務流程的監控。對於這部分可量化指標，可以通過長期的觀察分析來提升轉化率。
- 異常監控。頁面的任何異常都可能導致支付頁面的渲染失敗，從而無法正常支付。我們對頁面的介面異常、微信API異常進行了監控。介面異常可在API（wx.request）的fail函式中直接捕獲，從而上報監控；對於介面超時，則只能通過全域性的app.json進行全域性設定（預設60s，時間過長，對使用者體驗較差），此前我們曾嘗試在小程式中設定全域性的5s請求超時，但實際應用中並非所有場景需要設定統一的超時，最終我們單獨封裝了介面請求超時。微信API的異常通過微信的一些fail中進行監控即可。
效能監控。小程式內部轉化環節中關注進入小程式後的白屏時間和可互動時間。內部白屏時間從onLoad處打點，到頁面onReady處結束；內部可互動時間從onLoad處打點，到頁面資料請求結束後的可點選支付時間截止。
日常監控中，我們也發現了一些問題，例如介面呼叫超時、介面呼叫失敗，這些問題會導致頁面流程終止。針對這些問題我們做了一些優化：
介面合併。支付頁面的外網鏈路介面請求數量較多，任意一個介面的失敗都會導致問題，合併介面則可以減少問題出現概率，提升中間流程的轉化率。
增加重試機制。在出現介面異常的情況下，會直接導致頁面阻塞，如果通過重試能成功，則可以提升轉化率。整個流程中可重試的有兩類：自有的介面請求異常，小程式API呼叫異常。
對於這兩類異常，在介面超時、呼叫失敗時採取重試。而為了避免在極端情況下服務端流量陡增、峰值倍數增加，頁面的可重試次數會在前置獲取全域性配置時根據“可重試次數”進行控制，並且每次重試需要在一段時間後使用者手動觸發。超過重試次數時，則流程終止。
如何監控內部和外部環節？
前面我們也提到，對於小程式開發者而言，掃碼到小程式調起這個環節是黑盒的，我們開發者無法得知此處的細節，所以說在監控外部環節這方面我們開發者似乎可做的事情屈指可數。但是，不知道細心的同學有沒有發現，微信在每次掃碼後會給我們在query引數上附帶一個scancode_time欄位。其實這個欄位表示的是使用者在使用掃一掃時微信服務端記錄的時間，所以基於這個欄位的考量，我們做了如下嘗試，針對以下兩個引數值分別做了實時監控：
- 支付頁面的白屏時間（使用者看到首屏的客戶端時間—使用者微信掃一掃服務端時間+服務端客戶端差額時間）。
- 支付頁面的使用者可互動時間（頁面Loading完畢時間—使用者微信掃一掃服務端時間+服務端客戶端差額時間）。
由於客戶端的時間戳是獲取本地手機系統的時間，可能存在差異。所以為了保證上報的準確性，我們在每次onLoad的時候取了一次我們服務端的時間，記錄了客戶端的時間與服務端的一個時間差額，並且在後續所有涉及到服務端的時間都參照這個時間差額做計算（網路100-200ms級別的傳輸時延，暫可忽略）。
但由於我們掃碼付小程式的特殊應用場景就是為了保障使用者進行快速可靠的支付，既然在外部環節可控度不高，那是不是可以考慮在內部的業務流程方面把監控統計做的細粒度一點，做到能對每一個可能影響到支付的環節有資料可循呢？我們針對這個方向，區別於傳統的PV、UV統計，並對業務上報做了如下分類：
- 根據上報的場景劃分：實時性監控部分與統計部分。
- 根據上報的型別劃分：Error型別、Event型別（普通生命週期事件）、Metric型別（自定義Event型別，維度可自定義）、自定義測速型別（延時趨勢與分佈）。
基於上述方案的探索，我們團隊基本上做到了對可能影響支付環節的很多業務指標，進行了整體的把控。從而在下一步，針對每個潛在的可優化點做進一步思考與考量，然後作出及時的策略優化與更新。通過對掃碼付小程式的探索，我們積累了很多優化經驗。美團的價值觀是追求卓越，對於能優化的方面，我們還會進一步去探索，也歡迎更多的同學跟我們一起討論。
作者簡介
陳瑤，2015年校招入職美團，此前參與過美團平臺移動端觸屏版的前端開發工作，從0到1參與了智慧支付應用層的前端建設工作，現負責美團收單業務掃碼付小程式業務。
招聘
如果對我們“智慧支付大前端團隊”感興趣，可直接簡歷傳送給陳小二同學（chenyao05@meituan.com）。歡迎加入美團，跟我們一起探索未來。