JavaScript API(JSAPI) 是由支付宝客户端实现并通过 bridge 机制为前端H5/小程序应用提供原生能力的接口,JSAPI 可大幅增加前端开发者可使用的支付宝原生能力,提高前端 H5/小程序的用户体验。
支付宝已通过 400 余个 JSAPI 对外提供支付、多媒体、缓存、定位和文件系统等众多领域的原生能力供开发者使用,这些开放 JSAPI 提供的丰富能力是支付宝开放能力的重要组成部分,目前 JSAPI 的日均调用量超过百亿次。
图1 前端开发者通过 JSAPI 调用支付宝原生能力[1]
然而在繁荣的 JSAPI 生态背后存在隐忧,由于 Android 端、 iOS 端和 IDE 模拟器在实现接口时受信息理解差异、客户端特性限制等因素影响,部分接口在不同端的执行逻辑和返回结果存在差异。
因为 JSAPI 由支付宝客户端实现,所以接口需要由支付宝 Android 端和 iOS 端分别实现。在接口实现过程中,Android 和 iOS 端的实现差异导致接口在在不同端的执行逻辑和返回结果存在差异,这迫使 JSAPI 的用户付出额外精力兼容各端差异,技术支持每月会收到大量接口相关咨询。
[1]图片版权由Smallfish所有
我们对 2021.12-2022.2 三个月的 JSAPI 相关工单进行了分析,分析发现 400 余个开放接口中有八成以上的咨询量都集中在百余个接口上。为了在有限的时间内最大的提升开发者研发效率,我们决定优先治理工单反馈量靠前的 JSAPI。
在明确治理对象后,我们还需找出 JSAPI 都存在哪些类型的不一致问题,然后从众多不一致问题中找出需要重点治理的问题类型。
为了发现全部潜在问题类型,我们从前 100 个 JSAPI 中选择了 10 个具有代表性的 JSAPI 进行全面评测。评测发现问题主要集中在行为表现、出入参数、交互逻辑、UI表现 4个方面。为了验证评测结论的准确性,我们将JSAPI工单中反馈的不一致类型进行了统计,如下表所示,开发者反馈的问题也集中在这 4 个方面。
问题大类 | 问题子类 | 数量 |
行为表现 | JSAPI 在模拟器不支持 | 54% |
JSAPI 各端功能不一致 | 10% | |
JSAPI 在某些端无回调方法 | 1% | |
出入参数 | JSAPI 某些端少返回参数 | 4% |
JSAPI 各端参数类型不一致 | 12% | |
交互逻辑 | JSAPI 调用后各端交互不一致 | 11% |
UI 样式 | JSAPI 调用后各端展示 UI 样式不一致 | 9% |
结合评测结果和 JSAPI 反馈工单数据我们分别定义了行为一致、参数一致、交互一致和 UI 一致。
定义:API 在相同设备权限、相同小程序权限、相同上下文环境下对相同输入在 iOS、Android、IDE上响应行为一致。
反例:
my.showAuthGuide 权限引导 iOS 和 Android 支持的 authType 不同,LBS 文档上说明只支持 iOS,Android 需要商户自己去实现引导(设计)
innerAudioContext.seek 音频 autoplay = false 时,调用 seek 方法,Android 会自动播放,ios 不会(设计)
ios 中,支付宝版本10.2.56,小程序调用 FileSystemManager.readFile 一直报文件/目录不存在,导致页面排版错位问题(接口不具备解析xx文件路径能力)
openDocument 预览 pdf, pdf 合同上的章在 Android 上被去除了,ios 是可以的(缺陷)
IDE 与真机授权弹窗与接口回调之间的时序不一致(设计)
定义:API 参数的数量、名称、数据类型、内容含义和能力在 Android、iOS 和模拟器保持一致。
反例:
my.request 的 success 回调中 Android 和模拟器比 iOS 多返回 profile
字段
定义:API 在相同设备权限、相同小程序权限、相同上下文环境下对相同输入在 iOS、Android、IDE上的交互逻辑。
反例:
如果在 my.alert 唤起警告框后进行跳转页面,在安卓系统下页面跳转后 my.alert 警告框依然存在,在 iOS 系统下跳转页面后 my.alert 警告框消失。
定义:API 调用后展示的组件UI或对组件UI产生的改变在Android、iOS 和模拟器中表现一致。
备注:客户端实现的组件因端设计标准差异导致的 UI 差异不属于不一致问题
反例:
my.saveImageToPhotosAlbum下载成功后会安卓自动有个提示:已保存至系统相册,但是在ios中不显示这个提示
my.showLoading 真机文字较多的情况下显示不全(只显示一行),IDE 显示全部
为了保证评测结果的客观准确,我们需要设定一套评测标准,客观定义各种不一致问题的严重程度。按照问题对开发者的影响大小,我们将问题划分为红线问题、严重问题和普通问题 3 类。
红线问题:增加开发者的调试 & 测试成本,且容易引发线上故障
严重问题:影响异常处理逻辑,可能导致异常处理逻辑不能正常工作
普通问题:影响接口的使用体验,但几乎不会影响小程序开发
我们按照以上问题分类和问题分级标准产出了接口评测评分标准:
在摸索评测方案阶段,我们通过手工评测的方式快速迭代评测场景,逐步跑通了评测流程。但是,随着评测的深入开展,手工评测模式逐渐暴露出评测脚本难复用、难分享、难管理和测试慢等一系列影响评测效率的问题。
为了提高评测效率,我们基于 alita 测试框架开发了 JSAPI 多端一致性评测平台(以下简称评测平台),通过评测脚本参数化和测试自动化两方面能力解决以上问题。
评测平台由 前端、小程序基座和 Alita SDK 三部分组成。
图2 评测平台业务架构
前端
前端是交互入口,提供评测脚本录入、评测任务下发和评测报告生产等业务层服务。
小程序基座
小程序基座是小程序运行环境,提供 JSAPI 调用环境 和 JSAPI 参数一致性校验能力。
Alita SDK
Alita SDK 是 小程序自动化框架,提供小程序操控能力。
评测平台通过脚本参数化的方式解决评测脚本难复用、难分享和难管理的问题,通过平台可以快速查看脚本内容、分享脚本链接和管理用例。
图3 查看my.getLocation的评测脚本
图4 分享/管理评测脚本
脚本参数化 1.0
通过对手工评测脚本的分析,我们发现 JSAPI 的评测代码主要由小程序运行环境和不同的输入参数组合组成,其中小程序运行环境代码存在大量冗余。因此我们将 JSAPI 小程序运行时场景抽象为 异步接口调用场景模版、同步接口调用场景模版和监听事件调用场景模版,评测新的 JSAPI 时只需使用对应的模版并传入参数组合即可生成新的评测脚本,基本解决脚本难复用问题。
图5 脚本参数化2.0
脚本参数化 2.0
1.0 方案无法解决脚本分享难和管理难的问题,因此我们决定将评测脚本中 JSAPI 输入参数组合 与 JSAPI 小程序运行环境彻底分离。
JSAPI 小程序运行环境增加 websocket 通信模块,封装为小程序基座,发布到线上。
JSAPI 的输入参数组合、操控数据和环境数据以 JSON 数据的方式统一保存,在使用时通过 websocket 发送至小程序基座。
使用脚本参数化 2.0 后我们在分享和管理评测脚本时只需分享对应的参数化 JSON 数据,彻底解决分享难和管理难的问题。
自动化评测的执行链路如下图所示:
图6 测试任务执行链路示意图
首先,通过 Alita 测试框架能力将小程序基座分别推送到支付宝 iOS 端和 Android 端;
然后,小程序基座将评测脚本数据与JSAPI 评测模版组装为评测脚本实例并执行;
最后,小程序基座将 JSAPI 返回数据后与一致性评测打分规则对比,产出报告。
2 月完成前 100 个 JSAPI 评测,通过评测共发现数十个红线/严重问题和数百个普通问题。
开发者反馈工单量大幅下降,其中 JSAPI 相关咨询量下降超过 40%。
自动化巡检召回问题
为了守护来之不易的治理成果,我们需要建设自动化巡检能力,每天使用 1000+ 评测脚本检测线上 JSAPI 质量,及时发现存在问题的 JSAPI 并召回问题。
JSAPI 变更卡点拦截问题
将 JSAPI 多端一致性校验接入 JSAPI 变更流程,将不一致问题拦截在上线之前。