前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Universal Link 前端部署采坑记

Universal Link 前端部署采坑记

作者头像
顶级程序员
发布于 2018-04-26 09:54:05
发布于 2018-04-26 09:54:05
3K0
举报
文章被收录于专栏:顶级程序员顶级程序员

前言

文章会适当说一些如何开发iOS上的universal link,但类似的文章太多了一艘一大堆,每篇都介绍的挺清楚,因此也不是重点

本文更加会侧重从前端的角度,将整个universal link 部署应用到wap app中的一些策略和一些问题解决办法

其实整个Universal Link没啥难的,真正上线过Universal link的人这些应该都趟过一遍了,本文主要是我们team去应用Universal link的时候一些文档沉淀和记录

Schema VS Universal Link

Deeplink相关的技术,在wap中唤起app其实应用最最广泛的并不是Universal Link,而是直接Schema跳转

location.href = 'schema://xxxx'

并且一般各大APP都会给自己做一套路由体系,这样其实可以直接在schema头后面对接路由体系,做到一行schema定位打开任意App内功能界面(我就不详细扯路由的事了)

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { if ([[url absoluteString] hasPrefix:@"schema://"]) { [[WKDispatcher sharedInstance] operationObjectFromRouteURL:[url absoluteString]];//路由 return YES; } }

如果单纯为了实现deeplink -- 在WAP上打开App,并且传递来数据信息,定位App内的具体逻辑,那么Schema就够了,其实没必要上Universal Link,Schema相当于是很特殊的Url,他是schema://xxx这种样子,如果安装了APP才能支撑跳转这种Schema Url,如果没安装APP就没任何效果,而Universal Link则是把普通url,长http://xxx.xxx.xxx/xxx这样的Normal Url,如果安装了App,就能像Schema一样传递给App,延续App内逻辑,如果没装App,则还会继续在浏览器里跳转这个Normal Url

Schema的弊端

Schema无法判断是否安装App

一定会有这样的产品需求的:

  • 如果已经安装App,则打开App
  • 如果没有安装App,则前往下载App

浏览器实际上是没有能力判断手机里是否安装了某个App的,所以聪明的程序员们选择了讨巧的方法

try { var appSchema = 'schema://xxxx'; if ($.os.ios) { location.href = openNALocation; //location.href 打开schema } else { $('body').append('<iframe src="' + appSchema + '" style="display:none"></iframe>'); //iFrame 打开 schema } }catch (e) {} //延迟1000秒 setTimeout(function () { if ($.os.ios) { location.href = `https://itunes.apple.com/us/app/idxxxxxxx?mt=8`; } else { location.href = `https://xxx.xxx.xxx/xxx/xxx.apk`;//直接apk下载link } },1000)

  • 首先发起跳转Schema

如果没安装App,会打开App失败,没效果

如果安装App,会成功打开App

  • 延迟1000ms

如果没安装App,Schema打开失败,等1000秒后会自动跳转

如果安装App,App会打开,当前网页会被暂停,这延迟代码不会执行

聪明的人会发现,这样有个风险,如果用户打开APP成功后,又手动切回浏览器,那么延迟1000ms的代码依然会执行,安卓会跳出下载apk包得提示,iOS会又再度跳到Appstore,但这个瑕疵也不是太大的问题,所以这种做法被普遍采用,运用在各种安装就跳转,不安装就下载的用户场景。

安卓这么用挺好,iOS有个讨厌的弹框

如果用户没有安装App,那么他一定会经历2个事情

  • schema打开app,但是失败
  • 延迟后,跳转下载App

在第一个环节,安卓上schema打开失败,没有任何反映,也没有任何提示,一切顺利,但是iOS就不同了。

schema会弹个可恶的跳转失败的框

1504334347900

然后再延迟后弹跳转AppStore的框

1504334376521

Schema被很多App禁止,比如微信手百

Schema被广泛使用,从浏览器中唤起打开专门的App,但这并不被很多App认可,比如微信,手机百度,他们本身除了浏览网页以外有其他的使用场景,所以站在微信/手百的角度,并不希望用户为了看一些分享和内容就跳出微信/手百的App,于是这些客户端拦截了Schema,使得所有Schema都无法生效。

于是不得已,广大开发者只好针对,微信/手百,等特殊UA信息,展现出蒙层,引导用户用系统/外部浏览器打开

Universal Link 解决 Schema的弊端

开篇就说了,如果你单纯为了能让wap打开App,Schema就能做到了,Universal Link的意义则是把普通url,也赋予了能打开App的能力,而不必编写专门的Schema Url去唤起App

Schema 的2个弊端确实能通过Universal Link解决

不同于Schema,在没装App的时候,Universal Link他也是一个合法的url链接,浏览器可以正常跳转,因此不会出现在iOS上讨人厌的框

Universal Link目前还没有基于iOS的UI/WKWebView的应用进行拦截,所以目前看还是能突破微信/手百的封锁。(以后,不好说啊~)

Universal Link 开发

类似的话题,随便搜搜Universal Link能搜到一大堆,我这里就略微多啰嗦两句,一般各大教程里会反复说的,我尽量一带而过,多说点我遇到的坑

配置apple-app-association

究竟哪些的url会被识别为Universal Link,全看这个apple-app-association文件

Apple Document UniversalLinks.html

  • 你的域名必须支持Https
  • 域名根目录下放这个文件apple-app-association,不带任何后缀
  • 文件为json保存为文本即可
  • json按着官网要求填写即可

怎么写json其实没啥可教的,满世界的文章都教你咋写了,我们看个例子,点下面的链接,你的浏览器就会自动把知乎的apple-app-association的json file给down下来

知乎的 apple-app-association 文件

划重点

有心人可能看到,知乎的Universal Link配置的是 oia.zhihu.com 这个域名,并且对这个域名下比如/answers /questions /people 等urlpath进行了识别,也就是说,知乎的universal link,只有当你访问 https://oia.zhihu.com/questions/xxxx,在移动端会触发Universal Link,而知乎正经的Urlhttps//www.zhihu.com/questions/xxx是不会触发Universal Link的,知乎为什么制作,为什么不把他的主域名配置Universal Link,这是由于Universal Link的一个大坑所致

PS.

apple-app-association 你可以看完全了知乎的json file,会发现里面也不止是 universal link 苹果的一些其他功能都和apple-app-association有关,都需要配置这个文件,增加更多json字段信息 比如Hand off 还有一些跨Web&App的分享

测试是否正确

苹果官方提供了一个网站来测试你配置的域名apple-app-association是否正常work

https://search.developer.apple.com/appsearch-validation-tool/

这个网站有点SB,就是你用他测试不通过,其实Universal Link也可能不生效的,比如我把知乎的oia.zhihu.com输入进去,他就没感应到,认为没有。我搜索的时候,发现也有人发现了这个问题,反正可以当个参考

配置iOS App工程

  • 开发者中心证书打开Associated Domains
  • 工程配置Associated Domains
  • 将你apple-app-association所在域名配置进去
  • 给你的工程像Schema的OpenUrl一样,编写App被唤醒后的处理逻辑

#pragma mark Universal Links - (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler { if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) { NSURL *webUrl = userActivity.webpageURL; [self handleUniversalLink:webUrl]; // 转化为App路由 } return YES; }

恩比较千篇一律,我不多说了

Universal Link的基本运作流程

  • APP第一次启动 or APP更新版本后第一次启动
  • APP向工程里配置的域名发起Get请求拉取apple-app-association Json File
  • APP将apple-app-association注册给系统
  • 由任意webview发起跳转的url,如果命中了apple-app-association注册过的通用链接
  • 打开App,触发Universal Link delegate
  • 没命中,webview继续跳转url

在你进行apple-app-association 以及 App工程的配置之后,整个Universal Link的运作流程完全由系统控制了

Universal Link 采坑

整个Universal Link其实真要只是开发完成,完全写不了几行代码,就差不多搞定了,不过还真是踩了几个坑

跨域

前端开发经常面临跨域问题,恩Universal Link也有跨域问题,但不一样的是,Universal Link,必须要求跨域,如果不跨域,就不行,就失效,就不工作。(iOS 9.2之后的改动,苹果就这么规定这么设计的)

这也是上面拿知乎举例子的时候重点强调的一个问题,知乎为什么使用oia.zhihu.com做Universal Link?

  • 假如当前网页的域名是 A
  • 当前网页发起跳转的域名是 B
  • 必须要求 B 和 A 是不同域名,才会触发Universal Link
  • 如果B 和 A 是相同域名,只会继续在当前WebView里面进行跳转,哪怕你的Universal Link一切正常,根本不会打开App

是不是不太好理解,那直接拿知乎举例子

https://www.zhihu.com/question/22914651

知乎的一般网页URL都是www.zhihu.com域名,你在微信朋友圈看到了知乎的问题分享,如果copy url 你就能看到这样的链接

微信里其实是屏蔽Schema的,但是你依然能看到大大的一个按钮App内打开,这确实就是通过Universal Link来实现的,但如果知乎把Universal Link 配在了www.zhihu.com域名,那么即便已经安装了App,Universal Link也是不会生效的。

一般的公司都会有自己的主域名,比如知乎的www.zhihu.com,在各处分享传播的时候,也都是直接分享基于主域名的url,但为了解决苹果强制要求跨域才生效的问题,Universal Link就不能配置在主域名下,于是知乎才会准备一个oia.zhihu.com域名,专为Universal Link使用,不会跟任何主动传播分享的域名撞车,从而在任何活动WAP页面里,都能顺利让Universal Link生效。

简单一句话

只有当前webview的url域名,与跳转目标url域名不一致时,Universal Link 才生效

apple-app-association 覆盖

我们业务机房的集群是大部门下几条业务线共用的,有一整套云服务系统来进行机房集群的管理,有统一的接入层进行分发。虽然是不同的产品线,不同的服务,但是共享分布式的机房进行运作的。

很多Universal Link的教学文章是这么写的

  • 将json命名为 apple-app-association 不要乱改名
  • 将file 上传到域名所在的服务器根目录下

于是我就将我们文库的apple-app-association,上传到我准备的wenkuUniversal域名的所在机器的根目录下。(因为机房都是分布式的,所以其实就是upload的全部门下的很多机器上)

同部门另一个产品线阅读后来也开始尝试Universal Link,也要把他们写好的apple-app-association上传到他们的yueduUniversal域名所在的机器的根目录下。

因为都是同样的文件名,又因为整个事业部机器实际上是共用的,因此就发生了覆盖。

解决办法

共用同一个 apple-app-association

因为apple-app-association的具体内容里有App 的Bundle ID在,因此可以简单的把2个json file 进行merge,你的App bundle 生效你的link,我的App bundle生效我的link

但其实并不推荐,毕竟双方都要小心在更新的时候,不能覆盖对方,并且这样做也很不合理,apple-app-association也不止为universal link 一个feature工作,当面临跨app / web share 甚至hand off的时候,共用一个json file 还是有坑

接入层分发不同json file

2个产品线的link域名其实是不一样的,只不过恰巧这两个域名最重打到得机器是同一个或者说有重叠,因此产生了覆盖,完全可以将json文件保存成各自的名字,在接入层对域名进行分发

最终App也是通过Get请求去拉取apple-app-association的,只要Get到,并且ssl安全性上符合要求(强制https)就没问题

隐藏的坑:apple-app-association被覆盖后如何更新

我们线上已经work的Universal Link功能,突然有一天发现坏了,查了一圈最后查到被阅读覆盖了,那就修复呗,修复倒是没问题,问题在于修复后的universal link,用户必须重新安装一次app,才能重新work,这个太坑了啊

所以关键是需要掌握apple-app-association的更新时机,反复重新杀APP重开完全没用,删了APP重装确实有用,但不可能让用户这么去做

https://stackoverflow.com/questions/35187576/does-the-apple-app-site-association-json-file-ever-get-updated-in-app

这里解释了,每次App安装后的第一次Launch,会拉取apple-app-association,除此之外在Appstore每次App的版本更新后的第一次Launch,也会拉取apple-app-association。

也就是说,一旦不小心因为意外apple-app-association,想要挽回又让那部分用户无感,App再发一个版本就好了

Universal Link 会因为用户行为而失效

Universal Link 触发后打开App,这时候App的状态栏右上角会有文字提示来自XXApp,可以点状态栏的文字快速返回原来的AP

如果用户点了返回微信,就会被苹果记住,认为用户并不需要跳出原App打开新App,因此这个App的Universal Link会被关闭,再也无效。

想要开启也不是不行,让用户重新用safari打开,universal link的页面,然后会出现很像苹果smart bar的东西,那个东西点了后就能打开(我是看到的,我没亲自操作过)

Universal Link 业务部署

知乎的apple-app-association可以看到里面有一大堆的WAP的URL,比如/answers /questions /people等,知乎都将它一一映射到App得对应界面里,问题/回答/人详情页。这是因为知乎的WAP站和APP的功能几乎是一致的。因此知乎的Universal Link的使用方式,可以说是很经典的遵循着苹果的原始设计初衷通用链接,将wap url,变成通用url,同样的url,对应着2个跳转,web跳转/app跳转,但是他们是同一个功能。

我们产品线面临的情况不一样,我们的产品线文库,他的WAP和APP功能差异非常大,可以说除了文档阅读页/view,WAP与APP都有这个功能,其他的功能WAP是WAP的,APP是APP的,形态和场景都有明显差异。除了/view这个功能,我们可以按着通用链接的设计,将APP阅读页跳转,与WAP阅读页跳转进行统一。其他时候Universal Link对于我们业务来说就是一个更强大的Schema(突破旧Schema局限的=),他只需要跳转到APP,他没有合法的WAP Url可以让浏览器在没有安装App的情况下继续跳转。

我们的Universal Link 业务部署

我们的Universal Link就像知乎一样,没有选择我们的主域名,而是选了一个完全没在WAP上有任何页面和流量的域名,我们的apple-app-association是这么写的

{ "appID": "xxxxxx.xxx.xxx.xxxxx", "paths":[ "/view/*", "/_iosuniversallink/*"] },

我们的AppDelegate中具体handleUniversalLink的逻辑是这么写的

- (BOOL)handleUniversalLink:(NSURL *)url { NSURLComponents *components = [NSURLComponents componentsWithURL:url resolvingAgainstBaseURL:YES]; NSString *host = components.host; if ([host isEqualToString:@"xxx.xxx.xxx"]) { //host判断,虽然没啥意义 if (pathComponents.count >= 3) { //地址匹配+页面跳转 NSString *router; if ([pathComponents[1] isEqualToString:@"view"]) { router = @"xxx";//生成打开APP阅读页的专属Router } else if ([pathComponents[1] isEqualToString:@"_iosuniversallink"]) { router = @"xxx";//解析出APP能识别的任意路由, } if (router && router.length > 0) { [[WKDispatcher sharedInstance] operationObjectFromRouteURL:router];//无论

是阅读页路由还是任意路由,发起跳转

} return YES; } } return NO; }

可以看出来我只打开了这个域名下https://xxx.xxx.xxx/view/* 和 https://xxx.xxx.xxx/_iosuniversallink/*2个Universal Link Path.对没错,不像知乎那么多。

  • /view/* 后面的*直接是阅读页ID,用于快速生成阅读页路由,发起跳转
  • /_iosuniversallink/* 后面的*其实应该填写的是我们App已经设计好的路由字符串,识别出路由字符串后,发起跳转

其实可以看出来/_iosuniversallink是完全包含/view的,因为APP阅读页天然也是包含在我们的路由规则内的,只要这里有路由策略,扩展力已经足够支持任意APP页面了,因此apple-app-association只配置了2个,但是如果有计划外的特殊case,大不了更新一下,也没多大事。

为了统一WAP&APP,为了通用链接的效果

我刚才提到,我们选择的Universal Link的域名其实是一个没有实际页面的域名,也就是说https://xxx.xxx.xxx/view/*这个url,如果没安装APP因此触发WebView继续跳转原地址,会直接404。处理很简单,重定向一下

router.use('/view', function (req, res, next) { var path = req.path; res.redirect('https://wk.baidu.com/view' + path + '?st=1#1'); });

整个效果就是

  • 跳转https://xxx.xxx.xxx/view/*
  • 已安装App
    • 打开App 触发handleUniversalLink
    • 走到/view/分支,拼接阅读页路由
    • 跳转
  • 未安装App
    • WebView原地跳转https://xxx.xxx.xxx/view/*
    • 命中服务器的重定向逻辑
    • 重定向到https://wk.baidu.com/view/*
    • 打开我们的WAP阅读页

这就是为啥明明/_iosuniversallink是完全包含/view能力的,但还是要把/view/单独处理的原因,为的是实现WAP与APP的统一设计,为了通用链接这个初衷

不为了统一WAP&APP 只拿来当强化版Schema使用

同样的道理,https://xxx.xxx.xxx/_iosuniversallink/*这个url,也没有实际的页面,如果不进行重定向,也会直接返回404,因此看一眼重定向的代码

router.use('/_iosuniversallink', function (req, res, next) { var redirecturl = 'https://wk.baidu.com/topic/naiosappstore'; res.redirect(redirecturl); });

解释一下https://wk.baidu.com/topic/naiosappstore就是我们为iOS下载App准备的专门的WAP单页面,这个页面打开后会自动延迟500ms,发起跳转appstore

整个效果就是

  • 跳转https://xxx.xxx.xxx/_iosuniversallink/*
  • 已安装App
    • 打开App 触发handleUniversalLink
    • 走到/_iosuniversallink/分支,拼接出任意App内的界面路由
    • 跳转界面
  • 未安装App
    • WebView原地跳转https://xxx.xxx.xxx/_iosuniversallink/*
    • 命中服务器的重定向逻辑
    • 重定向到https://wk.baidu.com/topic/naiosappstore
    • naiosappstore页面会延迟跳转AppStore
    • 打开AppStore下载

这个设计看起来就是完美解决了PM得需求

  • 如果已安装App,跳转对应界面
  • 如果没安装App,跳转App下载界面

解决了旧Schema模式下的弊端问题:

  • Schema无法判断是否安装App,只能采用setTimeout的Trick方式
  • Schema的Trick方式会有一个丑陋的错误跳转弹框
  • Schema无法在微信/手百等App内,打开我们自己的App

简单的说,这样设计的初衷就是,我不为了通用链接这一目的来使用Universal Link,来统一WAP&APP的URL跳转,我就为了把Universal Link当做加强版Schema来使用

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-09-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 顶级程序员 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
工业缺陷检测深度学习方法综述
基于深度学习的工业缺陷检测方法可以降低传统人工质检的成本,提升检测的准确性与效率,因而在智能制造中扮演重要角色,并逐渐成为计算机视觉领域新兴的研究热点之一。其被广泛地应用于无人质检、智能巡检、质量控制等各种生产与运维场景中。
一点人工一点智能
2022/12/27
1.7K0
工业缺陷检测深度学习方法综述
霸榜第一框架:工业检测,基于差异和共性的半监督方法用于图像表面缺陷检测
关注并星标 从此不迷路 计算机视觉研究院 公众号ID|ComputerVisionGzq 学习群|扫码在主页获取加入方式 论文地址:https://arxiv.org/ftp/arxiv/papers/2205/2205.00908.pdf 链接: https://pan.baidu.com/s/1ar2BN1p2jJ-cZx1J5dGRLg  密码: 2lah 计算机视觉研究院专栏 作者:Edison_G 目前霸榜第一,99.56%,一秒31.34张图片。 1 概括 半监督框架下,研究者提出了一
计算机视觉研究院
2022/05/20
1K0
霸榜第一框架:工业检测,基于差异和共性的半监督方法用于图像表面缺陷检测
工业界表面缺陷检测方法综述
产品的表面缺陷检测是近年来制造业中格外关注的一项技术问题。作为生产制造过程中必不可少的一步,表面缺陷检测广泛应用于各工业领域,包括3C、半导体及电子、汽车、化工、医药、轻工、军工等行业,催生了众多上下游企业。自20世纪开始,表面缺陷检测大致经历了三个阶段,分别是人工目视法检测、单一机电或光学技术检测以及机器视觉检测。随着光电元器件的快速发展,以及计算机技术中图像处理、人工智能等算法的深入研究,以机器视觉为代表的先进方法在工业质检中得到越来越广泛的应用。
用户7699929
2021/01/05
2.6K0
工业界表面缺陷检测方法综述
DeepSeek与PyTorch携手:开启工业缺陷检测新时代(4/18)
摘要:本文介绍了如何结合DeepSeek和PyTorch实现工业缺陷检测的全流程,重点聚焦于小样本数据增强、异常检测模型微调以及产线级部署与边缘计算优化。在小样本数据增强方面,我们探讨了多种方法,包括噪声注入、特征扰动、对比度增强、生成对抗网络(GANs)、自回归模型(Autoencoders)以及伪标签(Pseudo-Labeling)。这些方法能够有效扩充数据集,提升模型在有限数据条件下的泛化能力。
正在走向自律
2025/02/15
1.4K0
DeepSeek与PyTorch携手:开启工业缺陷检测新时代(4/18)
复杂场景下的复杂缺陷检测方法--深度学习算法综述
随着自动化技术的快速发展,在工业生产中很多需要人工操作的环节逐渐转由机器完成,工业生产自动化也将越来越多的工人们从枯燥乏味的工作中解放出来,让他们去发挥更大的价值。
OpenCV学堂
2020/02/24
1.4K0
SEM-CLIP:用于扫描电子显微镜图像中纳米级缺陷检测的精确少量学习 !
半导体制造是一个复杂且多面的过程,其中缺陷可能是由于工艺不当或设备问题引起的。为了实现实时监控,会捕捉SEM图像并基于缺陷的外观对其进行分类,从而帮助缺陷检测和根本原因分析。与粗略的晶圆级缺陷图谱不同,SEM图像可以提供更详细的缺陷特征,从而有助于确定具体的过程步骤和设备。目前,缺陷检测主要依赖人工操作,这既费时又容易出错。开发自动缺陷检测系统已成为一种趋势。
AIGC 先锋科技
2025/03/29
1130
SEM-CLIP:用于扫描电子显微镜图像中纳米级缺陷检测的精确少量学习 !
总结|深度学习实现缺陷检测
缺陷检测是工业上非常重要的一个应用,由于缺陷多种多样,传统的机器视觉算法很难做到对缺陷特征完整的建模和迁移,复用性不大,要求区分工况,这会浪费大量的人力成本。深度学习在特征提取和定位上取得了非常好的效果,越来越多的学者和工程人员开始将深度学习算法引入到缺陷检测领域中,下面将会介绍几种深度学习算法在缺陷检测领域中的应用。
Datawhale
2020/07/09
2.6K0
总结|深度学习实现缺陷检测
用深度学习实现异常检测/缺陷检测
创建异常检测模型,实现生产线上异常检测过程的自动化。在选择数据集来训练和测试模型之后,我们能够成功地检测出86%到90%的异常。
Color Space
2021/02/07
3.2K0
综述|工业金属平面材料表面缺陷自动视觉检测的研究进展
基于计算机视觉的金属材料表面缺陷检测是冶金工业领域的研究热点。在金属制造行业中,高标准的平面质量要求自动视觉检查系统及其算法的性能必须不断提高。本文基于对钢,铝,铜板和带钢的一些典型金属平面材料产品的160多种出版物的综述,试图对二维和三维表面缺陷检测技术进行全面的综述。根据算法的属性和图像特征,现有的二维方法分为四类:统计方法,光谱方法,模型方法和基于机器学习的方法。在三维数据采集的基础上,三维技术分为立体视觉,光度立体,激光扫描仪和结构化光测量方法。本文将分析和比较这些经典算法和新兴方法。最后,对视觉缺陷检测的剩余挑战和未来的研究趋势进行了讨论和预测。
计算机视觉
2021/02/26
9700
综述|工业金属平面材料表面缺陷自动视觉检测的研究进展
基于深度学习的【木板】表面缺陷检测与识别
实木板材在国民经济中扮演重要角色,被广泛使用在国家建设中。为了提高林业资源利用率,实现企业木材加工的可持续发展,基于深度学习对实木板材缺陷图像进行检测,准确检测和识别表面缺陷位置信息。实木板材加工设备的研制已经取得一定成绩,但大多数实木板材智能加工设备功能单一,缺乏多种功能一体化的经济型设备。
Color Space
2022/12/22
1.1K0
基于深度学习的【木板】表面缺陷检测与识别
表面缺陷检测数据集汇总及其相关项目推荐
目前, 基于机器视觉的表面 缺陷装备已经在各工业领域广泛替代人工肉眼检测,包括3C、汽车、家电、机械制造、半导体及电子、化工、医药、航空航天、轻工等行业。传统的基于机器 视觉的表面缺陷检测方法,往往采用常规图像处理 算法或人工设计特征加分类器方式。一般来说,通常利用被检表面或缺陷的不同性质进行成像方案的设计,合理的成像方案有助于获得光照均匀的图像,并将物体表面缺陷明显的体现出来。近年来,不少基于深度学习的缺陷检测方法也被广泛应用在各种工业场景中。
AI算法修炼营
2020/06/24
3.8K0
表面缺陷检测数据集汇总及其相关项目推荐
利用大视觉-语言模型(LVLM)来提高工业环境中异常检测和定位的效果 !
工业异常检测(IAD)在确保制造过程的质量和安全方面起着至关重要的作用,特别是在依赖自动化系统进行生产的行业中。识别工业系统中的异常或故障行为——无论是机械设备故障、材料缺陷还是工艺偏差——对于减少停机时间、降低运营成本并保证产品质量至关重要。近年来,大型多模态视觉语言模型(LVLMs)的出现为提升IAD的技术水平提供了前景。LVLMs结合了视觉理解和自然语言处理的能力,在涉及图像和文本数据的任务中展示了强大的能力[1,2]。LVLMs的双模态特性使其特别适用于工业异常检测,因为在这种场景下需要同时理解视觉模式和文本描述(例如缺陷报告、产品手册和机器日志)。
AIGC 先锋科技
2025/01/13
4950
利用大视觉-语言模型(LVLM)来提高工业环境中异常检测和定位的效果 !
一文梳理缺陷检测方法
近年来,随着深度学习的快速发展,基于卷积神经网络(CNN)的计算机视觉技术在工业领域得到了广泛的应用。目前,机器视觉表面缺陷检测是CNN在工业上最成熟的应用之一。接下来我们将介绍深度学习在表面缺陷检测领域的概述。
Amusi
2021/01/28
6.2K0
一文梳理缺陷检测方法
基于AidLux的工业视觉少样本缺陷检测实战应用---深度学习分割模型UNET的实践部署
工业视觉在生产和制造中扮演着关键角色,而缺陷检测则是确保产品质量和生产效率的重要环节。工业视觉的前景与发展在于其在生产制造领域的关键作用,尤其是在少样本缺陷检测方面,借助AidLux技术和深度学习分割模型UNET的实践应用,深度学习分割模型UNET的实践部署变得至关重要。
远方上
2023/12/04
4930
基于AidLux的工业视觉少样本缺陷检测实战应用---深度学习分割模型UNET的实践部署
智能手机背面玻璃的缺陷检测,分割网络的应用
论文地址:https://www.mdpi.com/2076-3417/10/10/3621
AI算法修炼营
2020/07/02
2K0
OpenCV4应用开发:入门、进阶与工程化实践
机器视觉是使用各种工业相机,结合传感器跟电气信号实现替代传统人工,完成对象识别、计数、测量、缺陷检测、引导定位与抓取等任务。其中工业品的缺陷检测极大的依赖人工完成,特别是传统的3C制造环节,产品缺陷检测依赖于人眼睛来发现与检测,不仅费时费力还面临人员成本与工作时间等因素的制约。使用机器视觉来实现产品缺陷检测,可以节约大量时间跟人员成本,实现生产过程的自动化与流水线作业。
默 语
2024/11/20
630
OpenCV4应用开发:入门、进阶与工程化实践
总结 | 使用OpenCV4实现常见缺陷检测
机器视觉是使用各种工业相机,结合传感器跟电气信号实现替代传统人工,完成对象识别、计数、测量、缺陷检测、引导定位与抓取等任务。其中工业品的缺陷检测极大的依赖人工完成,特别是传统的3C制造环节,产品缺陷检测依赖于人眼睛来发现与检测,不仅费时费力还面临人员成本与工作时间等因素的制约。使用机器视觉来实现产品缺陷检测,可以节约大量时间跟人员成本,实现生产过程的自动化与流水线作业。
OpenCV学堂
2023/12/11
1.1K0
总结 | 使用OpenCV4实现常见缺陷检测
基于深度学习和机器视觉的手机表面缺陷检测
随着智能制造产业的升级和改造,智能手机作为人们生活的必需品,它的“智”不仅仅在于产品功能、性能方面的创新,更在于生产制造过程的智能化。
Color Space
2024/06/17
4850
基于深度学习和机器视觉的手机表面缺陷检测
ICLR 2025 | 多模态大模型能否胜任工业异常检测?MMAD基准揭示真相
事实上,工业场景中的许多任务——例如异常检测——就属于这种基础但至关重要的工作。想象一下,一个工厂质检员每天需要检查成千上万的产品,找出微小的缺陷或异常。这是一项既繁琐又要求极高的工作,通常依赖大量人力完成。如果能够用AI替代这种重复性强且耗时的任务,不仅可以显著提高效率,还能让人类员工专注于更具创造性和战略性的工作。
小腾资讯君
2025/02/14
3810
CVPR VISION 23挑战赛第1赛道亚军解决方案 - 数据高效缺陷检测
CVPR VISION 23挑战赛第1赛道 "数据智能缺陷检测 "要求参赛者在数据缺乏的环境下对14个工业检测数据集进行实例分割。本论文的方法聚焦于在有限训练样本的场景下提高缺陷掩模的分割质量的关键问题。基于混合任务级联(HTC)实例分割算法,我们用受CBNetv2启发的复合连接将transformer骨干(Swin-B)连接起来以增强基准结果。此外,我们提出了两种模型集成方法来进一步增强分割效果:一种是将语义分割整合到实例分割中,另一种是采用多实例分割融合算法。最后,通过多尺度训练和测试时数据增强(TTA),我们在数据高效缺陷检测挑战赛的测试集上获得了高于48.49%的平均mAP@0.50:0.95和66.71%的平均mAR@0.50:0.95。论文链接:https://arxiv.org/abs/2306.14116 代码链接:https://github.com/love6tao/
BBuf
2023/08/22
6600
CVPR VISION 23挑战赛第1赛道亚军解决方案 - 数据高效缺陷检测
推荐阅读
相关推荐
工业缺陷检测深度学习方法综述
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档