接下来，程志分享了支付宝在2016年做的四个AR相关案例，并重点介绍了支付宝在春节期间推出的“扫福字领福卡”活动。

AR 实践一：扫月

支付宝首次尝试运营AR活动是2016年中秋节的“扫月亮”活动，需要识别月亮和一些圆形物体。

扫描月球的识别过程大致分为以下三个部分：

因为拍摄真实场景时，月亮通常较小，所以使用了亮点检测模块，然后进行简单的场景分析，过滤掉明显不是拍到月亮的图片。第二部分是支付宝也会上线一些海报，海报通常较大，所以这里使用了白色圆圈检测算法。因为中秋节期间天气不是很好，有可能看不到月亮。为了增加互动话题，市场和运营提出了允许识别月亮以外的圆形物体的要求，所以也需要圆形物体检测算法。

总之，以上三部分整合在一起，实现了图像的快速识别。当时处理一帧图像的时间大概是100毫秒左右。往往在用户举起手机的时候，物体就已经被识别出来了，但是人的视觉可能还没识别出来，因为识别太灵敏，可能会给用户一种假的感觉，所以做了3秒的延时，并且设置了在举起手机的时候不进行图像识别。另外圆检测的方法有很多，比如随机选取多个点拟合成一个圆进行匹配等。其实在客户端开发的过程中，对速度和计算的要求会很高，所以这里使用了一种简化的方法：先用颜色分割区分物体，提取边缘后再使用近似圆检测。

扫月活动整体效果还是不错的，在微博上引起了不小的讨论，一些图片网站也借此进行了宣传。

AR练习2：扫描1212文房四宝

扫月活动之后，不少商家开始积极探索相关应用场景。因此，在双十二期间，支付宝也进行了线下引流，在线下商圈张贴海报，宣传“扫1212，集四宝”活动。因为主要针对线下商圈，所以这次活动的宣传力度不是特别大，但活动现场人气还是不错的。

当时的需求是识别“1212”四个字，但在实际上线测试过程中发现海报样式非常丰富，总共有20种左右。由于角度、距离、光线等因素，摄像头采集到的像素可能比较低，所以实际的图片识别难度比较大。所以最终采取的策略是近景识别“1212”四个字，远景识别整张海报。整个客户端大概支持20多种图片的识别。在杭州银泰百货实际测试过程中也做了动态的改进，不断调整线上配置的模型包，实时提升整体的用户体验和算法功能。如果没有这种动态调整能力，代码静态放在客户端，一旦上线就很难修改和修正，所以引擎的动态化在一些运营场景下非常重要。

至于这次活动的整体效果，客户端对这20张海报的整体识别率接近90%。之所以无法达到特别高的识别率，是因为线下场景距离远等因素，有些时候人眼可能可以识别，但机器因为像素低无法准确识别。识别速度大概是130毫秒/帧，所以整体用户体验还是比较流畅的。当时有多家地方电视台对这次活动进行了采访报道。

AR实战三：AR实景红包

接下来我重点分享一下支付宝去年做的一些AR实景红包相关的实践。去年支付宝推出的AR实景红包也算是比较大胆的尝试。其实在业务讨论阶段，最初的方案是类似现有的一些产品比如GO，想通过LBS、手机传感器来实现交互。但是在开发过程中遇到了一个问题，如果想在某一层楼发红包或者只有拍下这个楼的照片才可以发红包、收红包，现有的技术是无法解决的，因为LBS定位无法满足这样的需求。在一栋楼里，LSB是无法区分某一层楼的。面对这样的问题，支付宝多媒体猎鹰团队提出了这样一种基于拍照图片对比的方式来达到目的。比如用户在藏红包的时候，拍下物体的照片，收红包的人也必须来到这个地方，找到物体才能拍照、收红包。基于这样的逻辑，支付宝技术团队实现并推出了AR实景红包。AR实景红包的一个好处是可以帮助商家进行品牌推广。因为藏红包和找红包需要拍照，商家可以用自己的logo或者产品作为线索进行推广。

AR红包框架

AR红包框架背后的逻辑主要分为两个部分：一个是藏红包的过程，一个是找红包的过程。为了避免藏红包过程中出现很多模糊的场景，比如到处都是白墙、比较暗的地方，支付宝多媒体技术团队增加了一个评估的过程。如果用户要发AR红包，首先要判断这个场景是否适合发红包，光线是否需要亮一点，因为特别暗的场景不适合藏红包；另一方面还要评估纹理是否足够丰富，因为如果纹理特征比较少，对后续的识别或者区分都是不利的，所以藏红包时会限制这部分特征。如果满足上述条件，就会将图片上传到服务器，在服务器上进行特征提取，然后合成线索图。

在搜红包的时候，用户选中红包之后，线索图和红包的特征码都会被客户端拉到本地，后续的图片比对也会在本地完成。这样做的好处是用户在搜红包的同时，还可以进行实时的计算。如果将图片传输到服务器，往返的数据传输时间可能达不到产品要求，也达不到用户体验和准确率的要求。所以客户端实时图片比对的优势还是很大​​的。本地匹配成功之后，会将对应的图片传输到服务器进行二次验证。二次验证主要是为了保证安全性，因为恶意用户可能会绕过支付宝入口，直接调用后台服务，所以这里的二次验证主要是为了针对一些作弊行为进行特殊处理。

AR红包的挑战

事实上，AR实景红包背后还有不少挑战：

AR红包效果

当AR实景红包终于上线的时候，影响还是比较大的，从最初的界面我们可以看到地图上的位置点周围全是红包，当然这是个人玩法，但最大的影响还是随着商家对活动的关注，很多商家愿意尝试加入进来，所以后来就有二三十家主流商家加入进来，并且创造了一种新的营销方式，就是通过拍摄自己的logo来推广。

AR 实践四：扫描并收集祝福

2017年春节期间，支付宝推出了“扫一扫领福”红包活动，大家最熟悉的就是扫网页或者门贴上的“福”字，但这背后其实隐藏着很多复杂的需求。

支付宝技术团队在实现AR扫描时面临一些重大挑战：

多个识别任务是并发的。在扫码入口，不仅需要识别“福”字，还需要识别不同的海报。另外，有些商户的红包还需要通过扫码入口上传图片到后台进行识别，所以这是一个多任务并发的过程。扫“福”字的请求是高并发的。因为春节扫福活动受到的关注度很高，所以扫“福”字的请求数也比较高，每秒需要处理的计算量也很大。识别“福”字的挑战在于，当时提出的要求是“福”字的识别不仅要能识别网页上的“福”字，还要能识别一些手写的字或者贴在墙上的字。因为需要识别的“福”字的样式非常丰富，所以在识别“福”字本身的难度上也有一定的挑战。

春节期间的扫福活动也和可口可乐有深度合作，所以也需要支持可口可乐的7个福娃的扫描。上图最上面一排图片是可口可乐福娃的海报样式，顾客通过扫描线下购买的可口可乐产品上的福娃，即可领取相应的红包或者福卡。同时，支付宝在海外及港澳台地区也进行了大规模的海报促销攻势，所以也需要支持这些特别定制的海报，当用户在海外机场或者海外消费时看到这些促销海报，用支付宝扫描也可以获得福卡。所以对于识别来说，除了识别开箱的福字，还需要识别大概14种海报样式。

AR祝福扫描框架设计

为了满足上述需求，支付宝红包扫描客户端的识别策略也采用了框架处理模式。

首先第一帧就识别海报，大概就是之前说的14种海报，而且每帧的处理时间控制在100毫秒以内，所以能非常快速的判断当前拍摄的是不是海报。

在下一帧的时候需要判断手机是否静止，因为有时候客户端识别不成功，需要将图片传到服务器端，所以需要判断当前手机是否静止。判断静止的方式有很多种，比如通过手机的陀螺仪、传感器等，而支付宝技术团队采用的是图像判断，利用前后两帧图像的差异来判断。如果两到三秒内图像差异不大，那么就认为当前用户的意图是拍照并传到服务器端识别，所以在第二帧进行图像静止判断的过程。如果静止判断成功，就会将图片传到服务器端识别。

第三步是本地福字检测。为了应对服务器端可能承受不住压力的情况，需要基于本地客户端的应急方案。因此，支付宝多媒体猎鹰团队在客户端做了基于LBP福字检测的本地备案算法。本地福字检测的目的是为了将流量分流到服务器端，需要的时候才会开启这个功能。其实这个开关在活动刚开始的时候是关闭的，所以扫红包的流程就只有之前的海报识别和图片传输到服务器端。第二天活动进行的时候，服务器端的压力比较大，所以三个步骤都开启了。这个策略的好处是提供给用户的整体体验不会卡顿，因为每个模块都是在100毫秒内处理的，所以每秒大概可以尝试10次，每个模块平均有三次左右的机会。支付宝AR扫福框架的响应速度和流畅度得到很好的保障，而客户端扫福字识别模块的加入也能起到分流的作用，有助于减轻服务器端的负担。

活动效果

最终实现的效果是，在客户端和服务端同时开启“福”字识别后，识别量达到峰值。活动第一天预估峰值在1万左右，但由于用户参与热情高涨，活动开始一天后就达到了服务端识别能力的上限，因此立即开启了客户端本地识别。不过这也带来了一些问题，由于客户端识别能力有限，一些不是“福”字的图片会被误识别为“福”字，而这些都是后续开发中需要在技术封装和储备方面进一步完善的地方。

不过活动整体效果还是不错的，能够识别出大部分用户拍摄的福字，产品中少量的误识也是可以接受的。整体来看，70%的识别任务都是在客户端完成的，识别过程比较流畅，只有极少数本地无法识别的情况才会上传到服务器，节省了服务器资源。本次活动也引起了不少关注，网上也出现了很多有趣的故事，所以整体效果还是不错的。

3. 总结与展望