iOS 上的通用链接与深层链接（URL 方案）

Posted 2023-02-19

【中文标题】iOS 上的通用链接与深层链接（URL 方案）

【英文标题】：Universal links on iOS vs. deep links (URL schemes)

【发布时间】：2016-06-02 01:09:20

【问题描述】：

在我阅读的过程中，ios 9 引入了通用链接。在 Apple 的 App Search Programming Guide 的“支持通用链接”部分中，它说这与使用 URL 方案的深度链接不完全一样，但我对这个话题并不完全清楚：

Universal Link 和 URL Schemes 之间实际上有什么区别？通用链接是否仅适用于网站、邮件或消息应用中的超链接？ 通用链接会取代 URL 方案吗？ 通用链接是一种深层链接吗？

【问题讨论】：

您需要阅读更多相关信息。我会尽可能简单地解释。当您定义一个 url 方案时，您的应用程序会响应该方案，例如，您创建一个方案 myapp://。以您的方案开头的所有链接将直接启动您的应用程序。通用链接不会在 url 中包含您的方案，但它们仍会启动您的应用程序。

【参考方案1】：

TL、DR：

Universal Link 和 URL Schemes 之间实际上有什么区别？通用链接是否仅适用于网站、邮件或消息应用中的超链接？

通用链接是 Apple 特定的、基于操作系统的 URL，它将网站 URL 与特定于应用程序的 URI 方案和路由联系起来。它并非在所有应用程序中都可用 - 因为应用程序必须支持该行为。有一份很好的清单，列出了 UL 目前的工作地点/方式 (here)。

我在最后概述了 UL 的许多问题。请参阅下面的长读。

通用链接会取代 URL 方案吗？

没有。它们是 iOS Safari 上 URI 方案和路由的强制替代品。您必须而且应该仍然支持您的应用的 URI 方案和路由，因为 android 和 iOS Chrome 仍然使用这项技术，从归因到电子邮件的所有主要链接供应商类别也是如此。

通用链接是一种深层链接吗？

是和不是。通用链接本身不是通用深层链接 - 例如，它们无法通过安装过程。但是当用户拥有应用程序时，他们可以进行深度链接。最好根据链接可以做什么和不能做什么来考虑所有链接，而不是将 URL 分为“深层链接”和“非深层链接”。

根据用户是否拥有应用程序和上下文（浏览器、应用程序、操作系统、操作系统版本等），许多链接表现出深度链接的行为。改变思维框架。

跟踪通用链接

在下面的文档中，我概述了通用链接的所有不同方面。重要的是要指出continueUserActivity 将报告来自通用链接的引用 URL，因此您可以使用它来属性打开。

因为 UL 不是正常的链接，如果您有重定向，就会破坏它。同样，如果您关闭重定向，那么您拥有的任何网站点击服务器都将永远不会受到攻击。这是一个不同的讨论，但重要的是要注意。

如果您有兴趣，我在下面整理了有关通用链接的许多有用信息。

URI 方案

大多数人都熟悉 URI 方案。 URI 是通用资源指示符 (link)。 URI 可以分配给移动应用程序。键入 URI，例如 airbnb:// 将尝试在设备上定位应用资源 Airbnb。

在通用链接或应用链接存在之前（即 iOS 9.3/Android 6.0 之前），需要使用“自定义 URI 方案”和airbnb://d/listing/530250 形式的路由来将用户深层链接到特定移动应用程序中的内容（在本例中为列表）。然而，当用户没有安装应用程序（没有回退）时，这并不安全，也不能处理这种情况。大多数归因合作伙伴（Appsflyer、Kochava、Button、Yozio、Branch 等）的工作方式是提供处理此问题的链接。

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

window.location.href(...)

如果应用程序在计时器到期之前没有打开，那么供应商可以假设手机不包含应用程序，因此，一些 javascript 会触发以打开 iTunes 或 Android URL。这种机制依赖于阻止浏览器中的 javascript。

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

Apple 通用链接和 Android 应用程序链接本质上是网络 URL（例如，https://www.airbnb.com/rooms/530250），旨在将用户引导至网络或应用程序上的最佳位置。如果用户没有应用程序，它们旨在将用户带到移动网络，但如果用户有应用程序，则将用户带到应用程序中的确切内容。在移动设备上，如果用户点击通用链接并安装了我们的应用程序，他们可能会被定向到该应用程序，否则系统将回退并让访问者登陆我们的移动网站（有一些例外 - 见下文）。

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

Apple 通用链接和 Android 应用链接

Apple Universal Links (iOS) 和 Android App Links (Android) 本质上是相同的概念，但经常互换或与其他路由机制混淆。当你谈论这些概念时，明确表达很重要，否则你可能会混淆或混淆运行方式非常不同的不同技术。

具体来说，Apple Universal Links 是 Apple 的一项标准，部署在 iPhone 操作系统 (OS) 上，允许用户点击链接并立即传送到应用程序（如果他们拥有该链接）。 Apple 通用链接没有重定向。这是一个特殊的系统设置，具有一定程度的技术复杂性。当用户点击链接时，会向 Apple 发起往返服务器调用，操作系统会立即打开应用程序，而无需打开浏览器或加载 URL。下面详细了解它的工作原理。

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

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

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

一些例子：

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

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

示例... 应用前缀. 包 ID

路径：如果用户拥有它，这些路径将立即打开应用程序。该应用将收到引用 URL，并可以解析出正确的路径，以便将用户深层链接到之后的内容。

在某些情况下，大多数归因供应商（例如 Branch 或 Appsflyer）也可以为您托管 AASA（例如：Branch 的 Airbnb 的 AASA 托管在自定义域 https://abnb.me/apple-app-site-association 上）。

这些文件有效地将要在应用程序中映射或不映射到的 URL 列入白名单和黑名单。就像公司拥有的 AASA 一样，对于每个域，供应商都会指定 App ID 和 URL 路径，例如：

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

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

通用链接的已知问题

通用链接在大多数情况下都很好用，但是它们很容易被禁用，并且在不经意间被禁用！如果发生这种情况，用户将始终被重定向到网站 URL，直到他们升级他们的应用程序或重置我们所谓的“权利文件”(link)。

如果用户点击我们应用右上角的“airbnb.com”或“abnb.me”链接，操作系统会将用户引导至该网站，但也会永久引导任何未来的通用链接访问移动网站以获取与该域的链接！

这有效地破坏了 Apple 通用链接对用户的功能。这目前无法跟踪，唯一的重置方法是长按 URL 并单击“在“Airbnb”中打开”（不直观）或点击 Apple 通用链接横幅（幻影横幅）上的“打开”按钮本文档前面已描述。

Apple 通用链接横幅

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

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

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

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

Apple Universal Links Banner 属性总结：

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

【讨论】：

这个答案太棒了。感谢您为此付出的努力。

这些关于 URL 方案的信息是否仍然是最新的？我意识到这是对 iOS 9 的回答，但是有了这么多的信息，我想知道它是否仍然适用于 iOS 13。根据 WWDC 2019，“通用链接中的新功能”，“我们建议您当前使用自定义" (developer.apple.com/videos/play/wwdc2019/717/?time=107)

【参考方案2】：

通用链接是 iOS 向给定应用发送 Web url 请求的能力，而不是在浏览器中打开它们。

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

假设您有一个名为“Cool App”的应用，并且您已经注册了 url-scheme “酷应用”。而且您的应用程序具有不同的区域，例如“Nice gadgets”和“Nice stuff”。 现在您可以使用链接链接coolapp://nice-gadgets 打开您的应用程序。要让应用在 nice gadget 部分打开，您必须实现 application(_:openURL:options:) 方法，并在其中发现请求的 url，并使应用打开请求的视图控制器。

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

那么通用链接会取代 url 方案吗？我对此表示怀疑，但他们会以一种很好的方式互相恭维。

通用链接是深层链接吗？不，但他们可以启动在应用中使用深层链接的过程。

【讨论】：

关于Android中类似技术的任何信息？

Android 应用链接@zoujyjs

【参考方案3】：

通用链接替换 ​​URL/URI 方案？

在 Apple 的理想世界中，YES！

---

通用链接是深层链接的一种吗？

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

【讨论】：

您在哪里找到的：“因为从 iOS 9.2 开始，Apple 不再支持用于深度链接的 URI 方案”？

@kubba - 我相信他是从blog.branch.io/… 那里复制的。

我认为 Apple 自 iOS 9.2 起不再支持 URI 方案是不正确的。如果我错了，请提供指向 Apple 文档的链接。 Branch 正在销售基于通用链接的服务，因此请自行考虑。

说“不支持 URI 方案”有点用词不当。有关详细信息，请参阅我上面的帖子。具体来说，Safari 不支持非阻塞 Javascript，因此您不能使用古老的归因方法，即设置计时器、触发 URI 方案，然后在弹出错误之前回退到目标 URL。 URI 方案仍然“有效”，但如果用户没有应用程序而不会在 Safari 中触发“无法打开页面”错误，则无法启动它们。 URI 方案仍然有效，例如，在 iOS 上的 Chrome 浏览器上。

深度链接不可用的说法是错误的，请收回答案

【参考方案4】：

这是一个示例通用链接： “http://sample-universal-link.demoapp.com”

它是独特的，在被点击时会 在不通过 Safari 的情况下打开应用（如果已安装应用）或将在 Safari 上打开网站（如果未安装应用）

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

这个可能不是唯一的，并且在被点击时如果安装了它就会打开应用程序。如果应用程序未安装，它将什么都不做。 一个或多个 App 可能有相同的 URL Scheme。

Universal Link 和 URL Scheme 的实现（要求）完全不同，所以我非常怀疑 Universal Links 是否会取代 URL Scheme。

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