HarmonyOS扫码服务,应用服务一扫直达打造系统级流量新入口
二维码如今是移动应用流量入口以及功能实现的重要工具,也是各App的流量入口,是物、人、服务的连接器,通过扫码我们可以更便捷的生活,更高效的进行信息交互,包括信息的发布、信息的获取。
在日常扫码过程中,我们也经常会遇到扫码环境暗、二维码污损、模糊等情况,导致识别二维码困难。HMS Core 统一扫码服务(Scan Kit)为常见复杂扫码场景(如反光、暗光、污损、模糊、柱面)做了针对性识别优化,还能实现远距离码或小型码的检测和自动放大,提升扫码成功率与用户体验。未来,华为统一扫码服务将带来新的升级,将扫码能力下沉到OS里面,提供系统级的扫码API,帮助您快速构建强大的扫码能力。
功能特性
- 支持13种国际主流的码制,包含日常生活中常见的QR码,商品和运输行业用到的条形码。
- 远距离检测自动放大:支持检测远距离码并自动放大,提升远距和小码场景的识别成功率。
- 一图多码:可实现最多四个码同时识别。
-
任意角度识别:通过自动检测和旋转矫正,实现对平面一定角度旋转的码进行识别。
-
复杂场景识别增强:针对常见的复杂扫码场景(如暗光、污损、模糊、小角度、曲面码等)做了针对性识别优化,提升扫码成功率与用户体验。
各种场景下识别的效果
模糊和遮挡的场景:
小角度场景,当前已经可以做到20度的角度识别:
反光的场景下识别,包括在地库里面发光屏的场景的使用:
远距离的放大,最多可以支持将近20米的放大:
折叠的场景,识别的效果也非常好:
还有一些其它复杂的场景,比如曲面、曝光的场景下,都有比较好的识别的效果。
未来,当扫码API被调用之后,基于软硬协同的方案,在相机启动的时候会进行几个步骤,首先做图谱的裁剪,精简流程。其次资源供给倾斜,相机启动会更快。在没有做下沉的时候,对一些远距离、强光场景下,至少要15帧以上才能识别到,能力下沉到OS后基本3帧以内即可检测出码。
HarmonyOS NEXT独特优势
-
免SDK集成,采用HarmonyOS系统级扫码接口,包体0增加,接入更简单,更便捷。
-
免弹窗。在传统的扫码过程中,需要用户授权相机的权限进行弹窗提示,用户体验较差;统一扫码服务与相机协同,通过系统的预授权的方式免除用户弹窗,优化用户体验的同时安全隐私也能得到保证。
-
相机启动快。统一扫码服务和相机的底层做了协同和优化,码图质量更好,算法检测识别的准确率更高更快。
HarmonyOS NEXT接入指南
相对原有的SDK的接入方式更加便捷,在导入API以后,只需要几行代码按需求配置好相应参数,就可以实现极简的接入。
1、统一扫码服务提供HarmonyOS系统级扫码接口,不同于传统的SDK集成方式,接口简单,接入更便捷;
2、统一扫码服务将提供默认界面扫码(支持单码和多码识别)API,后续将开放其它接口。
HMS Core统一扫码服务新版首页即将来袭,更多HarmonyOS NEXT技术干货敬请期待!
了解更多详情>>
访问统一扫码服务联盟官网 获取统一扫码服务开发指导文档 访问HMS Core 联盟官网
获取HMS Core 开发指导文档
关注我们,第一时间了解 HMS Core 最新技术资讯~
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
谈了千百遍的数据一致性 | 京东云技术团队
今天来说一个老生常谈的问题,来看一个实际案例: 现有业务中往往都会通过缓存来提高查询效率,降低数据库的压力,尤其是在分布式高并发场景下,大量的请求直接访问Mysql很容易造成性能问题。 有一天老板找到了你...... 老板:听说你会缓存? 你:来看我操作。 你设计了一个最常见的缓存方案,基于这种方案,开始对用户积分功能进行优化,但当你睡的正酣时,系统悄悄进行了下面操作: 1、线程A根据业务会把用户id为1的积分更新成100 2、 线程B根据业务会把用户id为1的积分更新成200 3、在数据库层面,由于数据库用锁来保证了ACID,线程A和线程B不存在并发情况,,无论数据库中最终的值是100还是200,我们都假设正确 4、假设线程B在A之后更新数据库,则数据库中的值为200 5、线程A和线程B在回写缓存过程中,很可能会发生线程A在线程B之后操作缓存的情况(因为网络调用存在不确定性),这个时候缓存内的值会被更新成100,发生了缓存和数据库不一致的情况。 第二天早上你收到了用户投诉,怎么办?人工修改积分值还是删库跑路? 凡是处于不同物理位置的两个操作,如果操作的是相同数据,都会遇到一致性问...
- 下一篇
破局主键重复问题的坎坷路 | 京东物流技术团队
伴随着业务的不断发展,逐渐由单库单表向分库分表进行发展。在这个过程中不可避免的一个问题是确保主键要的唯一性,以便于后续的数据聚合、分析等等场景的使用。在进行分库分表的解决方案中有多种技术选型,大概分为两大类客户端分库分表、服务端分库分表。例如 Sharding-JDBC、ShardingSphere、 MyCat、 ShardingSphere-Proxy、Jproxy(京东内部已弃用)等等。 在这个燥热的夏天,又突然收到告警,分库分表的主键冲突了,这还能忍?不,坚决不能忍,必须解决掉!后面咱们慢慢道来是如何破局的,如何走了一条坎坷路…… 翻山第一步 咱们的系统使用的是ShardingSphere进行分库分表的,大概的配置信息如下:(出于信息的安全考虑,隐藏了部分信息,只保留的部分内容,不要在意这些细节能说明问题即可) <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.o...
相关文章
文章评论
共有0条评论来说两句吧...