WWDC案例解读:大众点评相机直接扫描支付是怎么实现的
总第253篇
2018年 第45篇
背景
去年12月4日,Apple CEO Tim Cook 和王兴共同出现在上海的一家老字号生煎店“大壶春”,现场用大众点评App体验了iOS 11新功能,包括用地图找店订座、用相机扫码点餐及Apple Pay付款等一条龙便利服务。
在今年的WWDC上,大众点评App更进一步:Apple技术人员在“Create Great Customer Experience Using Wallet and Apple Pay”演讲中专门重点演示了如何用iPhone相机直接扫码点餐下单,并使用Apple Pay支付闭环的全流程。这背后的技术是怎么实现的呢?
实现方案
相机扫码
从iOS 7开始,系统就通过AVFoundation赋予了App“相机扫码”的能力。不过当时只能通过代码的形式,构建AVCaptureDevice,并设置输出类型为AVMetadataObjectTypeQRCode,来实现在App内部的二维码识别。
然而,整个iOS系统在此后的几年一直没有系统级的扫码入口,直到iOS 11发布,Apple终于在系统“相机”App内提供了二维码扫描识别并跳转到对应URL的能力。
Universal-Link
Universal-Link是iOS 9之后推出的,可以实现URL和App之间的无缝连接,在此之前是自定义的URL Scheme。和自定义URL Scheme对比,Universal-Link有如下优势:
唯一性:Universal-Link使用标准的HTTP协议URL,拥有唯一性。
安全性:App可以控制处理哪些URL。
简单灵活:URL对于H5和App是通用的,如果没有安装App,就会跳转到Safari打开对应H5。
私密性:在跳转之前并不需要知道用户是否安装目标App。
结合“相机扫码”和Universal-Link,我们就可以做到从系统“相机扫码”直接唤起App了。
具体方案:将一个Universal-Link链接对应的二维码作为物料投放,用户直接使用系统“相机”扫描此二维码,如果装有大众点评App,会出现“是否用大众点评打开”的提示框,点击即进入App。如下所示:
面临挑战
上述方案是我们基于iOS系统现有能力做出的最佳实践,然而现实世界总有很多“意外惊喜”等待着我们:
物料已经大规模投放出去了,没办法修改怎么办?
整个流程发起是通过“相机扫码”进行,业务如何知道入口在哪?
Universal-Link在微信里不能跳怎么办?
我们知道Universal-Link的生效主要依赖两部分:
AppTarget的Capabilities中配置的Associated Domains,用以控制Universal-Link下的Domain。
部署在WebServer上的Apple-App-Site-Association,用以控制对应Domain下的Path。
也就是说,在大型工程化项目中使用Universal-Link,URL必须遵循一定的规则,才能做到所有业务共同使用互不干扰,点评App在引入Universal-Link时也制定了使用规范。
然而由于对应的物料已经大量投放,物料中二维码的URL在投放时并没有考虑Universal-Link的适配,无法遵循上面的“最佳实践”,而重新更换物料的成本又非常高,时间上也不允许。
所以我们只好“另辟蹊径”实现这个功能了。由于Universal-Link本身对URL没有任何限制,理论上我们可以通过部署配置把任意一条URL变成Universal-Link。
这样一来,投放出去的物料二维码就无法遵循我们已经定义好的Universal-Link使用规范,但这也是我们必须接受的“妥协”,在局部牺牲一些规范性换来重要功能的实现。
事情到此还没有完全结束,这种实现方式会带来另一个问题:这条物料二维码对应URL在WebView内打开的行为会发生改变。
按照Apple官方的解释:Universal-Link由用户“主动”触发,例如在邮件,记事本或是其它App中通过openURL唤起App打开这个URL;而如果用户处在Safari浏览器内直接输入或是点击链接打开这个URL,系统会在同源(Domain)页面下直接打开,非同源页面则会直接唤起App。
换句话说,如果在App内的WebView打开非同源某个页面,然后又在这个页面上点击了Universal-Link链接,这会变成一次对系统openURL方法的直接调用,如果不做处理有可能会跳出App,即使处理过大部分App也会在此时打开一个新的页面。
这显然不是我们希望得到的结果,但我们又必须将这些URL配置成Universal-Link。最终在非常困难的情况下,我们和业务同学达成共识:对于这批特殊的投放物料二维码,业务系统保证URL使用场景的唯一性,不会在除二维码之外的其它场景使用这批特征URL,绕过App内WebView打开异常的Case。
这样我们完成了“对于既有投放二维码的iOS相机扫码唤起App”实现。
在这个特殊的场景中,整个流程的发起始自于App外,业务非常需要了解当前处于“相机扫码唤起App”的场景。
遗憾的是iOS系统除了userActivity的相关回调之外,并没有一个明确的App启动路径标识,我们只能知道App是通过Universal-Link的方式被唤醒了。
由于启动节点在App控制权范围以外,任何Native埋点的方式都不能在此时生效,我们唯一可以拿到的是那条被唤醒的URL,缺乏足够的上下文可能是所有启动相关业务最难以处理的部分。
由于问题1的解决,我们知道这条URL在App Scope内是有场景唯一性的,所以我们可以据此来比较Tricky的判断当前的场景。 拿到当前启动场景标识之后,就要考虑如何告知业务。
最简单的方式就是通过修改URL,告知业务具体特征,但作为一个通用平台型App直接修改业务方的原始URL显然不是合适的行为,而且可能造成不必要的麻烦,Header、Cookie、JSBridge等都可以考虑作为与H5的通信方式。
到此为止,我们完成了“从系统相机扫码唤起App进入相应页面”。然而,在国内微信才是各种二维码最大的扫描入口,在今年的1月份,微信彻底关闭了Universal-Link的跳转行为,任何Universal-Link在微信里都不能往外跳了。
“捡了芝麻,丢了西瓜”,这个ROI对我们来说过于沉重不能接受。考虑在Universal-Link诞生以前,我们都是通过openSchema的方式唤起App,“综合链接”是当时H5在微信唤起App的主要方式,我们可以在Universal-Link页面内再套一层综合链接,并在此区分用户场景,完成从微信唤起App的“初心”。
结语
大众点评App参与了过去多届WWDC的现场演示,从iOS 6的PassKit开始,经历Flat Design、MessageKit、MapKit、SiriKit、ApplePay到WWDC2018的ApplePay闪付。我们积累了丰富的与Apple沟通合作经验,既有驻场Apple Campus的封闭式开发,也有在IAPM的Face2Face,更多时候是在安化路492号的远程合作。
通常BD同学都会基于点评App现有功能和Apple提供的新能力,找到需求点。这种基于外部系统升级适配的二次开发,总会遇到各种问题。有些问题会比较容易可以直接解决,有些问题会挑战我们设定的边界需要我们做出妥协,还有些问题无法正面突破只能规避。
二进制世界总是由输入,计算,输出来定义。合理规划整体架构,明确划分输入输出边界,尽量减少外部依赖,可以让我们在缺少上下文,不能端到端掌控整体流程的情况下依旧游刃有余。
团队简介
点评平台移动研发中心总体负责大众点评APP。依托平台能力,我们不断输出高质量服务:Shark、Picasso、Logan、MCI、移动之家、Appkit等,在这里和“最好的合作伙伴“以“最严格的标准”做“最复杂的业务”,经受考验,砥砺前行,共同打造业界领先的移动开发团队。
---------- END ----------
也许你还想看