美团扫码付小程序的优化实践

短短几年的时间，微信小程序已经从一颗小小的萌芽成长为参天大树，造成了较大规模的开发者生态系统，尤为是在支付、线下垂直领域潜力巨大。

做为领先的生活服务平台，美团的技术团队在小程序领域也进行了不少的探索和实践。像mpvue就是一款使用Vue.js开发微信小程序的前端框架，并且已经在美团点评多个实际业务项目中获得了验证，详细介绍你们能够阅读《用Vue.js开发微信小程序：开源框架mpvue解析》一文。目前，mpvue已经开源，项目地址是：https://github.com/Meituan-Dianping/mpvue。

本文将介绍扫码付小程序的实践，根据美团前端工程师陈瑶在美团第31期技术沙龙（点击能够查看此次沙龙四场演讲的Slides和视频）的演讲《金融扫码付H5迁移小程序拓荒之旅》整理而成。

图片0

什么是扫码付小程序？

美团扫码付是一款面向C端消费者推出的线下收单业务，相信你们已经在线下不少餐馆和其余生活服务商家体验过了。这项业务主要就是经过小程序提供服务的，而在实际场景中，用户先使用微信“扫一扫”功能，扫描商家二维码，系统会自动调用扫码付小程序，进入支付页面，最后输入金额完成商品的支付。

图片1

目标及数据分析

支付服务最核心的指标，显然就是用户支付成功的占比，咱们称之为支付转化率。对扫码付业务而言，支付转化率的百分比越高，扫码付业务的营业额也就越高，其带来的收益是正相关的。所以提高扫码付小程序的支付转化率，就成为咱们技术团队的重要工做。通过数据分析，咱们发现转化率流失主要存在于如下两个环节：

• 扫码到进入小程序环节（外部环节）
• 进入小程序到支付环节（内部环节）

从扫码到进入小程序环节，微信会完成小程序基本信息获取、资源准备（代码下载或更新）等准备事项。在准备事项中，若是准备失败或等待时间过长，就会致使用户离开，这部分由微信控制的环节，咱们称之为外部环节。

在进入小程序到支付环节，页面会进行渲染、数据请求等，若是渲染时间长、数据请求时间长也容易致使用户离开，一样，若是数据请求失败也会形成用户使用过程的终止，这部分由咱们美团扫码付技术团队控制的环节，称之为内部环节。

图片2

如何提高外部环节转化率？

对于小程序开发者而言，扫码到小程序调起这个环节是黑盒的，咱们没法得知其中的细节。而咱们在扫码付小程序中尝试和微信的同窗作了一次梳理，发现扫码付小程序在外部环节的丢失率较高，查询数据后，咱们发现其中大部分用户手动点击了右上角的退出。

从业务视角出发，用户使用扫码付小程序，可认为他们有强需求进行支付，而形成用户手动点击退出的部分缘由多是等待时间过长。而在这个环节对时间形成影响更多的是资源准备，即小程序代码下载或者更新的行为。根据经验，影响下载和更新时间可能的因素包括两个方面：一个是网络，另外一个是代码包。

由于用户的网络是咱们没法控制的，只能尝试从代码包开始下手。而在当时未使用分包的状况下，咱们的主包大小约为3M，这意味着新用户和无缓存小程序用户均须要在首次使用时等待下载3M左右的包。在这种状况下，虽然用户享受了小程序离线缓存包的福利，却丢失了大部分新用户的体验。因而咱们尝试从包代码层面作一些优化：

• 增长分包加载机制。用户在使用扫码付业务时会按需进行加载，优化小程序首次启动的下载时间。
• 减少主包和分包大小。按照空主包的概念进行优化。在进行分包加载机制后，主包由于没法最小化而影响首次下载时间。一方面，原有的3M整包中，图片大小占用了50%大小，咱们将全部的内含二进制和Base64图片分发到了CDN；另外一方面，部分可移出的业务分发到了其余分包。

在作了这些事情后，扫码付分包从原先的整包3M缩减到了361K（主包300K+分包61K），而外部环节的转化率也提高了3%。虽然转化率提高了，但前置环节的转化率仍然有部分丢失，理论上继续缩减300K的主包能有效提高，但因为业务性质的缘由没法再继续缩减，因而咱们向微信小程序提出了独立分包的概念：用户在使用独立分包时无需下载主包。

图片3

经过独立分包加载，程序使用期间下载更新阶段，只须要加载61K的分包大小。目前这个功能还在灰度阶段，扫码付小程序团队也在做为第一批的内测用户进行体验，优化效果在以后的实践中，咱们也会分享出来，你们可关注美团技术团队公众号，持续关注咱们。

如何提高内部环节转化率？

在进入小程序到支付这个环节，属于咱们的业务流程。在这个环节中的转化率丢失虽然咱们可以掌控，可是必须有所依据，才能对症下药。因此咱们作了一些数据监控：

• 业务核心流程监控。业务核心流程指用户进入小程序后所涉及的影响最终支付的中间流程，中间流程的丢失会直接影响业务整个转化率丢失，因此这里必须进行监控。而业务核心流程监控须要可监控的具体指标，咱们对进入小程序和支付进行了关键动做拆解，从开始扫码到用户看到页面，再到点击支付、初始化订单、支付成功。拆解完这些关键动做，再针对每一步可控环节，进行技术指标的拆解。从入口到出口的每一步制定关键指标（扫码加载转化率、点击意愿等，见下图），造成一个至上而下的漏斗，产出多个可量化指标，来作业务流程的监控。对于这部分可量化指标，能够经过长期的观察分析来提高转化率。

图片4

• 异常监控。页面的任何异常均可能致使支付页面的渲染失败，从而没法正常支付。咱们对页面的接口异常、微信API异常进行了监控。接口异常可在API（wx.request）的fail函数中直接捕获，从而上报监控；对于接口超时，则只能经过全局的app.json进行全局设置（默认60s，时间过长，对用户体验较差），此前咱们曾尝试在小程序中设置全局的5s请求超时，但实际应用中并不是全部场景须要设置统一的超时，最终咱们单独封装了接口请求超时。微信API的异常经过微信的一些fail中进行监控便可。

图片5

• 性能监控。小程序内部转化环节中关注进入小程序后的白屏时间和可交互时间。内部白屏时间从onLoad处打点，到页面onReady处结束；内部可交互时间从onLoad处打点，到页面数据请求结束后的可点击支付时间截止。

• 平常监控中，咱们也发现了一些问题，例如接口调用超时、接口调用失败，这些问题会致使页面流程终止。针对这些问题咱们作了一些优化：

• 接口合并。支付页面的外网链路接口请求数量较多，任意一个接口的失败都会致使问题，合并接口则能够减小问题出现几率，提高中间流程的转化率。

• 增长重试机制。在出现接口异常的状况下，会直接致使页面阻塞，若是经过重试能成功，则能够提高转化率。整个流程中可重试的有两类：自有的接口请求异常，小程序API调用异常。

对于这两类异常，在接口超时、调用失败时采起重试。而为了不在极端状况下服务端流量陡增、峰值倍数增长，页面的可重试次数会在前置获取全局配置时根据“可重试次数”进行控制，而且每次重试须要在一段时间后用户手动触发。超太重试次数时，则流程终止。

如何监控内部和外部环节？

前面咱们也提到，对于小程序开发者而言，扫码到小程序调起这个环节是黑盒的，咱们开发者没法得知此处的细节，因此说在监控外部环节这方面咱们开发者彷佛可作的事情屈指可数。可是，不知道细心的同窗有没有发现，微信在每次扫码后会给咱们在query参数上附带一个scancode_time字段。其实这个字段表示的是用户在使用扫一扫时微信服务端记录的时间，因此基于这个字段的考量，咱们作了以下尝试，针对如下两个参数值分别作了实时监控：

• 支付页面的白屏时间（用户看到首屏的客户端时间—用户微信扫一扫服务端时间+服务端客户端差额时间）。
• 支付页面的用户可交互时间（页面Loading完毕时间—用户微信扫一扫服务端时间+服务端客户端差额时间）。

因为客户端的时间戳是获取本地手机系统的时间，可能存在差别。因此为了保证上报的准确性，咱们在每次onLoad的时候取了一次咱们服务端的时间，记录了客户端的时间与服务端的一个时间差额，而且在后续全部涉及到服务端的时间都参照这个时间差额作计算（网络100-200ms级别的传输时延，暂可忽略）。

但因为咱们扫码付小程序的特殊应用场景就是为了保障用户进行快速可靠的支付，既然在外部环节可控度不高，那是否是能够考虑在内部的业务流程方面把监控统计作的细粒度一点，作到能对每个可能影响到支付的环节有数据可循呢？咱们针对这个方向，区别于传统的PV、UV统计，并对业务上报作了以下分类：

• 根据上报的场景划分：实时性监控部分与统计部分。
• 根据上报的类型划分：Error类型、Event类型（普通生命周期事件）、Metric类型（自定义Event类型，维度可自定义）、自定义测速类型（延时趋势与分布）。

基于上述方案的探索，咱们团队基本上作到了对可能影响支付环节的不少业务指标，进行了总体的把控。从而在下一步，针对每一个潜在的可优化点作进一步思考与考量，而后做出及时的策略优化与更新。经过对扫码付小程序的探索，咱们积累了不少优化经验。美团的价值观是追求卓越，对于能优化的方面，咱们还会进一步去探索，也欢迎更多的同窗跟咱们一块儿讨论。

做者简介

陈瑶，2015年校招入职美团，此前参与过美团平台移动端触屏版的前端开发工做，从0到1参与了智能支付应用层的前端建设工做，现负责美团收单业务扫码付小程序业务。

招聘

若是对咱们“智能支付大前端团队”感兴趣，可直接简历发送给陈小二同窗（chenyao05@meituan.com）。欢迎加入美团，跟咱们一块儿探索将来。