背景

去年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是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等，在这里和“最好的合作伙伴“以“最严格的标准”做“最复杂的业务”，经受考验，砥砺前行，共同打造业界领先的移动开发团队。