首页 文章

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

提问于
浏览
30

就像我'm reading, iOS 9 introduced Universal Links. In the 330446 section in Apple' s App Search Programming Guide一样,它说这与URL方案的深层链接不完全相同,但我对这个主题并不完全清楚:

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

  • Universal Links是否取代了URL方案?

  • Universal Links是一种深层链接吗?

4 回答

  • 8

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

    它是 unique ,并且在被点击它将 either open the App without going through Safari(if the App is installed)will open the website on Safari( if the App is not installed)

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

    may not be unique ,并被点击 it will open the App if it is installed . 如果应用程序是 not installedit will do nothing . 一个或多个应用程序可能具有相同的URL方案 .

    Universal Link和URL Scheme的实现(要求)完全不同,因此我非常怀疑Universal链接取代了URL Scheme .

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

  • 34

    Universal Links取代了URL / URI方案?

    在Apple的理想世界中, YES


    Universal Links是一种深层链接?

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

  • 31

    通用链接是iOS将web url请求发送到给定应用程序的功能,而不是在浏览器中打开它们 .

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

    假设您有一个名为"Cool App"的应用,并且您已经注册了url-scheme "coolapp" . 你的应用程序有不同的区域,如"Nice gadgets"和"Nice stuff" . 现在,您可以通过链接链接 coolapp://nice-gadgets 打开您的应用 . 要在好的小工具部分打开应用程序,您必须实现application(_:openURL:options:)方法,并在此内发现请求的网址,并使应用程序打开请求的视图控制器 .

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

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

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

  • 12

    TL,DR:

    What is actually the difference(s) between Universal Link and the URL Schemes? Is it that a Universal Link is only for hyperlinks in websites, and the Mail or Messages apps?

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

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

    Do Universal Links replace URL schemes?

    不 . 它们是iOS Safari上的URI方案和路由的强制替代品 . 您必须并且仍然应该支持您的应用程序的URI方案和路由,因为Android和iOS Chrome仍然使用此技术,每个主要类别的链接供应商也可以使用此功能,从归因到电子邮件 .

    Are Universal Links a type of deep link?

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

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

    Tracking Universal Links

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

    因为UL不是普通链接,如果你有重定向,那将破坏它 . 同样,如果您关闭重定向,那么您拥有的任何网站点击服务器都将永远不会受到影响 . 这是一个不同的讨论,但重要的是要注意 .

    如果您有兴趣,我在Universal Links下面列出了大量有用的信息 .

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

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

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

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

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

    Universal Links首先为您的每个域托管“Apple App Site Association File”(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中包含的一些值得注意的事项:可应用Universal Links的所有应用程序的AppID . 在我们和许多其他AASA中,您将看到应用程序的 生产环境 和测试版本的设置,以便链接可用于所有版本以进行测试 . AppID的结构为App Prefix,后跟Bundle ID . 通常,应用程序的每个测试版本都有不同的前缀,但Bundle ID保持一致 .

    示例... .

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

    在某些情况下,大多数归属供应商(如Branch或Appsflyer)也可以为您托管AASA(例如:分支机构针对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 .

    通用链接的已知问题

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

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

    这有效地破坏了Apple Universal Links的功能 . 这是目前无法跟踪的,唯一的重置方法是长按URL并点击“打开”Airbnb“”(不直观)或点击Apple Universal Links Banner(幻影 Banner )上的“打开”按钮这是本文前面所述 .

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

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

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

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

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

    Apple Universal Links Banner 属性摘要:

    • 仅在用户拥有应用程序时显示 .

    • 与Apple Smart App Banner不同

    • 仅在iOS Safari浏览器上显示 .

    • 不可自定义,但您可以使用iTunesMetadata.plist内容(link)自定义此 Banner 中 Headers 和说明的文本 .

    • 无归属或跟踪 .

相关问题