背景与挑战
多码即在同一个界面中同时存在多个条码或二维码， 其在现实场景中广泛存在，如服饰吊牌、饮料瓶身、快递单等。然而对于拍立淘的扫一扫场景来说，最初只支持单码能力，用户对于在多码场景识别到的是哪个码毫无感知，影响体验。基于上述现状，在淘宝现有的条件下，是否具备改造成识别多码的能力；进一步地，是否能够进行码位置的锚定，并将该能力同时应用于单码场景。
多码实现
要实现单码到多码的转变，需要从逻辑层、视图层进行重新设计。下面分别阐述。
▐ 逻辑层：单码识别到多码识别
我们通过对逻辑层梳理，把对单码的处理全部改为对码数组的依次处理。扫一扫解码层需要处理的内容如下，改动是由单数据处理切换为批量处理。在第五步中，因为在展示层后续需要有多码场景的展示，因此这里特地缓存了一帧当前帧。
▐ 展示层：单码展示到多码展示
当识别到多码之后，需要让用户保持所见即所得：即覆盖缓存帧在镜头页上，通过箭头锚定码框的中心点。等待用户的操作后再进行进一步的响应。考虑到要展示当前帧的实现方式有下述两种方案：方案一、将相机会话数据输入停止，则屏幕不会刷新新的帧数据，停留在当前帧，镜头页盖蒙层展示锚点。方案二、将当前帧缓存图添加在镜头页上，镜头页盖蒙层展示锚点。
两种方案各有利弊。方案一不额外消耗内存，但需要控制相机会话的开启和停止，在重新启动相机时状态切换导致画面有明显切换痕迹。方案二不影响相机启停，但帧缓存图需要额外消耗的内存。解法是通过对分辨率控制来实现对内存的控制，并在用户操作后及时回收内存。
改造后的层级如下所示。同时为了严格枚举不同状态（正常、单码、多码）的流转，使用了状态机模式。
- 镜头页容器 - 扫一扫镜头页 - 当前帧缓存图（新增） - 多码场景页（新增） - 蒙层（新增） - 导航栏（新增） - 码框（新增） - 提示文本框（新增）
扫一扫业务实现层需要处理的内容如下，蓝色部分为改动点。
▐ 二维码码框转换算法
实现多码视觉展示的一个重要内容，是要在条码/二维码的中心展示箭头。这里涉及到解码SDK返回的原始数据映射到设备屏幕的码框的计算。对于二维码，整体三步走文字描述及伪代码如下，主要包含三步处理：
第一步、原图（即相机输入帧） 0° → 顺时针90°。原图为横屏的图，需要将原始rect顺时针旋转90°
第二步、将旋转后的图，缩放到和设备屏幕同一个尺寸
第三步、将码框坐标变换：原图坐标点 → 屏幕坐标点
码框旋转rect = CGRect(x: 原图宽 - （原码框.y + 原码框.height), y: 原码框.x, width: 原码框.height, height: 原码框.width); BOOL 是否长屏幕 = 图片宽/图片高 > 屏幕宽/屏幕高 ? YES : NO;缩放比例 = 是否长屏幕 ? 屏幕高/图片高 : 屏幕宽/相机宽;码框缩放rect = CGRect(x: 图片旋转rect.x * scale, y: 图片旋转rect.y * scale, width: 图片旋转rect.width * scale, height: 图片旋转rect.height * scale); 码框坐标变换rect = null;if(长屏幕) { CGFloat xOffset = (图片宽*scale - 屏幕宽)/2.0; 码框坐标变换rect = CGRectMake(x:码框缩放rect.x-xOffset, y:码框缩放rect.y, width:码框缩放rect.width, height:码框缩放rect.height);}else { CGFloat yOffset = (图片高*scale - 屏幕高)/2.0; 码框坐标变换rect = CGRectMake(x:码框缩放rect.x, y:码框缩放rect.y-yOffset, width:码框缩放rect.width, height:码框缩放rect.height);} return 码框坐标变换rect;
整体三步走图示：
降低漏检率
在上述章节中，直观地看起来，要支持多码识别只要将解码SDK切换并开发上层链路就解决了，但是现实中情况并不如此。
单帧数据的解码成功率会受到很多因素的影响，比如当前帧的模糊程度、传输给解码SDK的帧图像压缩比例、解码算法等等。在完成完成上述内容后，我们发现在多码识别的场景中，多码解码漏检率是比较高的。但是核心解码SDK的改动是比较难的。因此这时候我们考虑从别的角度入手来解决问题。
▐ Vision解码
基于iOS13以上的Vision解码能力，我们能够进行大多是码类型的解码。同时，在多数场景中，Vision能够解码SDK的漏检问题进行补充，下图为帧数据增加Vision解码的链路：
使用Visioin方案设计的核心关键点如下：
- 图像串行解码
通过测算，扫一扫中解码SDK 和 Vision 解码耗时均在 50-100ms 左右，采用串行的解码能够满足业务要求。因此，在不阻塞单帧处理的情况下，使用 Vision 可以提高准确度。
从结果（VNRequest.results）当中，我们核心要获取的原始数据包括（和现有解码SDK对齐的数据，即最终数据格式要能够统一）：
- 码类型（symbology.rawValue）
- 码内容（payloadStringValue）
- 置信度（confidence）
- 原始码框（boundingBox）
- 置信度检测
增加置信度检测，是为了保证用户取得的码框是符合预期的。通过参数调优，我们设定了 0.9 作为可接受的置信度（confidence）最小值。
- 数据去重
在条形码的解码场景中，因为码竖条长度的不确定性以及底层算法的实现不同。存在一个条形码出现多个返回结果的情况，这些返回结果的中心点沿着条形码的中轴线纵向分布。基于用户的意图和常规操作场景，我们把位置重合且同样的码内容（payloadStringValue），只去重展示一个数据。去重策略上，选择置信度（confidence）最高的数据。
- 模型映射
进行码展示和码处理都是使用解码SDK原有的模型（Model），我们需要把 Vision 输出的结果进行转换。最重要的是将码类型（symbology.rawValue）转化成扫一扫需要的码类型和码子类型。
▐ 数据融合
有了Vision的数据之后，我们后续需要对解码数据做融合。融合的意思就是去重后合并，这就要求不同解码方式输出的解码结果是能够比较的。有了模型映射这个步骤，融合就比较简单了：我们把位置重合且同样的码内容，只去重展示一个数据。去重策略上，选择置信度（confidence）最高的数据。
▐ 端智能
有了Vision的帮助，我们能够对解码SDK解不出来的码做一次融合。但有没有办法提高解码SDK的成功率？前面说到，对于原图的压缩、码过小等场景都会影响解码SDK的解码率。那么有没有办法预先识别出当前图片的码框范围并抠图解码？
通过拍立淘的端智能架构，我们增加了码检测算法。码检测能力的提供，让我们不再是“摸黑”地进行解码了。而是有目的、有预期的进行解码。当码检测模型检测到当前帧具备一个或多个码，同时能够返回码框的位置。针对这个码框的位置，我们就能够进行抠图解码，能够增加解码SDK的解码成功率。
效果展示
左图为相册链路的多码识别，右图为镜头链路的多码识别。通过应用降低漏检率的策略，我们在多码场景上的识别率有非常显著提升。
总结和展望
本篇是从真实场景入手，在优化用户体验的维度发现问题，并尝试解决问题。但解决了问题（完成了多码实现）并不代表完成，因为始终能够有提升的空间（降低漏检率，提高解码率）。可以说，解决问题只是一个新的开始，是一个可以展开更广泛想象力，使用更广泛工具去不断优化的开始。
扫一扫作为手淘主要解码能力的载体，对扫码能力相关的优化是永无止境的。除了解码SDK本身对算法的不断升级之外，借助iOS系统和端智能技术，也能够对解码成功率起到正向的促进作用。扫一扫在经过多次迭代后，相册解码成功率提升了30pt+。同时，全屏识别、多码识别、药品码物流码的识别能力，也都是我们的优势所在。后续我们将会不断优化扫码解码的用户体验，缩短码识别时间，提高码识别场景的图片稳定性，做到
团队介绍
我们是大淘宝技术搜索终端团队，负责手机淘宝搜索，拍立淘等核心业务的研发和技术创新，同时打造了端侧的搜索终端通用框架，提供搜索领域端到端解决方案，以平台化能力支撑了手机淘宝等多个集团电商和本地生活业务，同时我们和算法技术紧密结合，将端智能和边缘计算充分应用于我们的文本和图像搜索业务，我们研发的产品为亿级消费者提供服务，期待您的加入。
感兴趣的同学可将简历发送到 taozi.ly@taobao.com
