iOS上的通用链接与深层链接(URL方案)

时间:2016-02-20 11:33:13

标签: ios ios9 deep-linking url-scheme ios-universal-links

在我阅读时,iOS 9引入了Universal Links。在"支持通用链接"在Apple的App Search Programming Guide部分,它说这与URL方案的深层链接不完全相同,但我对这个主题并不完全清楚:

  • Universal Link和URL Schemes之间的实际差异是什么?通用链接是仅用于网站中的超链接,还是邮件或消息应用程序?
  • Universal Links是否取代了URL方案?
  • Universal Links是一种深层链接吗?

4 个答案:

答案 0 :(得分:40)

通用链接是iOS向给定应用发送网址请求的功能,而不是在浏览器中打开它们。

URL-schemes是一种应用程序能够在给定状态下打开,由url描述,并由开发人员在代码中处理。

假设您有一个名为“酷应用”的应用,并且您已经注册了网址方案 “coolapp”。你的应用程序有不同的区域,如“漂亮的小工具”和“漂亮的东西”。 现在,您可以通过链接链接coolapp://nice-gadgets打开您的应用。要在好的小工具部分打开应用,您必须实现application(_:openURL:options:)方法,并在此内发现请求的网址,并让应用打开请求的视图控制器。

同时您有一个名为www.coolapp.com的网站。使用iOS设备进行浏览时,如果您遇到指向您网站的链接(例如www.coolapp.com/nice-gadgets)并打开该链接,则会在浏览器中打开该链接。 通过启用通用链接,它将通过在给定url作为参数的情况下调用application(_:continueUserActivity:restorationHandler:)方法来打开应用程序。 从这里,您可以使用url方案处理中的相同逻辑,以在请求的状态下打开应用程序。

通用链接会取代网址方案吗?我对此表示怀疑,但他们会以一种很好的方式相互称赞。

通用链接是否是深层链接?不,但他们可以启动在应用程序中使用深层链接的过程。

答案 1 :(得分:37)

TL,DR:

Universal Link和URL Schemes之间的实际差异是什么?环球链接仅用于网站中的超链接,以及邮件或消息应用程序吗?

Universal Link是一种Apple特定的基于操作系统的URL,它将网站URL与特定于应用程序的URI Scheme&路线。它并非在所有应用中都可用 - 因为应用必须支持该行为。有一个很好的清单列出了UL目前的工作地点和方式(here)。

UL也存在很多问题,我在最后概述了这些问题。见下面的长读。

Universal Links是否取代了URL方案?

没有。它们是iOS Safari上URI方案和路由的强制替代品。您必须并且仍然应该支持您的应用程序的URI方案和路由,因为Android和iOS Chrome仍然使用此技术,每个主要类别的链接供应商都可以通过电子邮件进行归档。

Universal Links是一种深层链接吗?

是和否。 Universal Links本身并不是通用的深层链接 - 例如,它们无法通过安装过程进行路由。但是当用户拥有该应用时,他们可以进行深层链接。最好根据他们可以做什么和不能做什么来考虑所有链接,而不是将URL分类为" deeplinks"和"不是深层链接。"

许多链接都表现出深层链接的行为,具体取决于用户是否拥有应用程序和上下文(浏览器,应用程序,操作系统,操作系统版本等)。改变思维框架。

跟踪通用链接

在下面的文档中,我概述了Universal Links的所有不同方面。请注意continueUserActivity将从通用链接报告引用网址,这一点非常重要,因此您可以使用此属性打开。

由于UL不是普通链接,如果您有重定向,则会破坏它。同样,如果您关闭重定向,那么任何网站点击服务器都不会被击中。这是一个不同的讨论,但重要的是要注意。

如果您有兴趣,我会在下面的环球链接中提供大量有用的信息。

URI方案

大多数人都熟悉URI方案。 URI是统一资源指示符(link)。 URI可以分配给移动应用程序。输入一个URI,如airbnb://将尝试在设备上找到应用资源Airbnb。

在存在Universal Links或App Links之前(即在iOS 9.3 / Android 6.0之前),需要使用“自定义URI方案”和airbnb://d/listing/530250形式的路由来深度链接用户移动应用程序中的特定内容(在本例中为列表)。但是,当用户没有安装应用程序(没有回退)时,这不安全,也没有处理。大多数归因合作伙伴(Appsflyer,Kochava,Button,Yozio,Branch等)的工作方式是,他们会提供一个处理此问题的链接。

当用户访问此URL的页面时,会有一些javascript会设置一个计时器,然后尝试使用一些简单的javascript从浏览器启动URI Scheme:

window.location.href(...)

如果应用程序在计时器过期之前没有打开,那么供应商可能会认为手机没有包含应用程序,因此相反,某些javascript会启动以打开iTunes或Android URL。这种机制依赖于在浏览器中阻止javascript。

在iOS 9.3中,Apple删除了Safari中的阻止javascript(link)。最终结果是,每当您尝试在Safari中使用URI方案打开应用程序时,您会看到一条大错误消息,上面写着“无法打开页面。”这是一种糟糕的用户体验并导致Apple新系统的执行,Apple Universal Links。

Safari "Cannot Open Page" triggered by older style URI Scheme redirects. In iOS 8 and below all attribution and deeplinking tech worked by setting a timer, trying to launch the URI scheme & pathway, then if a timer expired before the app launched, redirecting the user to the App Store. The advent of iOS 9.3 killed non-blocking javascript, and hence there was no way for this method to work anymore. Chrome & Android still support this style of attribution and routing.

Apple Universal Links& Android应用链接本质上是网址(例如https://www.airbnb.com/rooms/530250),旨在将用户引导到网络或应用上的最佳位置。如果用户没有应用程序,它们的目的是将用户带到移动Web,但如果他们这样做,则将用户带到应用程序中的确切内容。在移动设备上,如果用户遵循通用链接并安装了我们的应用程序,则可能会将其定向到应用程序,否则系统将回退并将访问者放在我们的移动网站上(除了少数例外情况 - 见下文)。

要使链接真正成为通用,它需要在网络,iOS和Android上启用链接功能,并且所有应用都要共享相同的资源路径。

Apple Universal Links& Android应用链接

Apple通用链接(iOS)和Android应用链接(Android)本质上是相同的概念,但经常互换或与其他路由机制混淆。当你谈论这些概念时要明确这一点很重要,否则你可能会混淆或混淆不同技术,这些技术的运作方式截然不同。

具体来说,Apple Universal Links是Apple的标准,部署在iPhone操作系统(OS)上,允许用户点击链接并立即发送到应用程序(如果有的话)。 Apple Universal Links没有重定向。这是一种特殊的系统设置,具有一定程度的技术复杂性。当用户点击链接时,将向Apple发送往返服务器调用,操作系统会立即打开应用程序,而无需打开浏览器或加载URL。更多关于它如何在下面工作。

Android App Links是在Android上设置的等效链接系统。

Universal Links首先为您的每个域托管“Apple App站点关联文件”(AASA)。

值得注意的是,几乎每家公司的AASA都在其主域名托管,后跟“/ apple-app-site-association”

一些例子:

https://www.jet.com/apple-app-site-association https://www.pinterest.com/apple-app-site-association

如果您点击这些网址,它将下载该公司的AASA。 AASA示例位于右侧。 AASA中包含的一些值得注意的事项: 适用于可以应用通用链接的所有应用的AppID。在我们和许多其他AASA中,您将看到应用程序的生产和测试版本的设置,以便链接可用于所有版本以进行测试。 AppID的结构为App Prefix,后跟Bundle ID。通常,应用程序的每个测试版本都有不同的前缀,但Bundle ID保持一致。

...例     {App Prefix}。{Bundle ID}

路径:如果用户拥有应用程序,这些路径将立即打开应用程序。该应用程序将收到引用网址,并可以解析出将用户与内容深层链接的正确途径。

在某些情况下,大多数归属供应商(如Branch或Appsflyer)也可以为您托管AASA(例如:分支机构的Airbnb AASA托管在自定义域https://abnb.me/apple-app-site-association上)。

这些文件有效地将应用程序中的URL列入白名单并将其列入黑名单,以便映射或不映射。就像公司拥有的AASA一样,对于每个域,供应商指定应用ID和URL路径,例如:

5LL7P8E8RA.com.airbnb.app
"/rooms/*"
"/wishlists/*"
"/invite"
"NOT /rooms/*/building-rules"

当用户安装或升级我们的应用时,iOS会为我们应用的权利中列出的所有域提取AASA文件,以确保我们的网站允许我们的应用代表他们打开网址。

通用链接的已知问题

Universal Links在大多数情况下都能很好地工作,但是这些很容易被无意中禁用!如果发生这种情况,用户将始终被重定向到网站网址,直到他们升级应用或重置我们称之为“权利文件”(link)。

如果用户点击我们应用右上角的'airbnb.com'或'abnb.me'链接,操作系统会将用户引导至该网站,但它也会永久指向任何未来的环球链接到移动网站获取与该域名的链接!

这有效地打破了Apple Universal Links对用户的功能。这是目前无法跟踪的,唯一的重置方法是长按URL并点击“打开”Airbnb“”(不直观)或点击Apple Universal Links Banner(幻影横幅)上的“打开”按钮这在本文档前面已有描述。

Apple Universal Links Banner

这些AASA路径还用于确定何时显示或不显示iOS系统的“通用链接横幅”。

这是一个特别热门的话题,经常出现在对话中,值得讨论。

当您在特定域上启用Apple Universal Links时,Apple将在Safari浏览器上注入系统App Banner。这意味着除了我们展示的任何横幅广告或网页插页式广告之外,Apple还会强制推出一个不可自定义的,不可跟踪的通用链接横幅,该横幅显示在Safari的顶部,供拥有该应用并在Safari中查看网址的用户使用谁的路径在AASA。

Apple injects a "Universal Links Banner" on your website when you setup Universal Links. There is no attribution or tracking.

我们无法控制此横幅的外观。我们只能确定它是否应该在基于AASA的页面上可见。我们目前也无法确定用户是否或何时点击“打开”按钮(IE无归属。

Apple Universal Links横幅属性摘要:

  • 仅在用户拥有该应用时显示。
  • 与Apple Smart App Banner不同
  • 仅显示在iOS Safari浏览器上。
  • 不可自定义,但您可以使用iTunesMetadata.plist内容(link)自定义此横幅中的标题和说明文字。
  • 没有归属或跟踪。

答案 2 :(得分:12)

Universal Links取代了URL / URI方案?

在Apple的理想世界中,

Universal Links是一种深层链接?

因为Apple强制开发者用户Universal Links才能进行深层链接。因此,Universal Links是Apple的一种深层链接。但是,如果你看到Facebook持续SDK,他们实现了自己的WebView,以支持iOS 9.0 +中的深层链接。因此,Apple Universal Links比深层链接更好。

答案 3 :(得分:8)

这是一个示例Universal Link: “http://sample-universal-link.demoapp.com

唯一,点击它会 无需通过Safari打开应用程序(如果安装了应用程序)将在Safari上打开网站(如果未安装应用程序)

这是一个示例URL方案:“demoapp”(demoapp:// params)

可能不是唯一的,点击时,如果安装了,则会打开该应用。如果应用未安装,则将无效。 一个或多个应用程序可能具有相同的URL方案。

Universal Link& amp;的实施(要求) URL方案完全不同,所以我非常怀疑Universal链接取代了URL Scheme。

Universal Link是实现深层链接的方式之一。