2017-03-06
在过去的几年中，深度链接、Universal Links（通用链接）、URI/URL 方案和 App 链接显著改变了移动 App 中内容链接的格局。这让很多 App 开发人员对要实施哪种技术以及每种技术的行业最佳实践是什么感到困惑。
此外，移动深度链接仍然是一个快速演变的领域。一年前行之有效的做法，即使仍然可行，也不一定是目前的最佳做法。现在到处都充斥着多年前的过时文章和误导信息，因此，我们有必要澄清误解，让大家重新认识移动深度链接世界。
首先，某些核心术语（“深度链接”）只是一个概念。我们每天都使用深度链接，比如，您可能就是点击了一个深度链接，然后访问这篇博客文章的。这个术语仅仅意味着“任何直接指向某个内容的链接”。比如，当您点击诸如 https://example.com/my-awesome-content-page 您不需要先进入 https://example.com/，然后一步步浏览网站来再次找到 my-awesome-content-page。换句话说，网络上的大多数链接实际上都是“深度网络链接”，只是我们不这么称呼。对我们来说，这些都只是“链接”。
移动 App 中的深度链接要复杂得多，但是移动深度链接仍然是为 App 用户提供流畅内容体验的最佳方式。Universal Links（通用链接）、URI 方案和 App 链接是让移动深度链接能够正常工作，从而直接将用户带到 App 中内容的几项技术标准。如果您想与朋友分享移动 App 中的某个页面，那么深度链接会将您的朋友带到正确的页面。如果没有深度链接，您的朋友将很难自己找到正确的页面，并且经常会进入 App 商店（即使已安装该 App）或移动网络中。
多年来，实施移动深度链接的过程不断发展，Android 和 iOS 都提供了自己的解决方案。这在 App 开发社区中造成了困扰，即使是经验丰富的工程师也会被迫在紧急情况下更新他们的链接，新手工程师还在苦苦探索在他们的 App 中实施深度链接的最佳途径。
下面是目前使用的各种移动深度链接标准的详细分类：
注意：iOS 和 Android 两大平台控制着 99.3％ 的移动市场。因此，Branch 对其他平台的支持非常有限，为简单起见，这里不做说明。
当然，并非所有平台或操作系统版本都支持这些标准：
Facebook 发明了一种开源的深度链接标准，而且显示出了发展潜力，尽管后来他们完全放弃了这套标准，但是标准本身仍然值得我们肯定：
下面来让我们更详细地分别研究一下每个标准。
如果您想在一个满是工程师的房间里掀起一场骚乱，您可以举办一场关于标签和代码缩进方面的辩论。或者您可能会混淆“URI 和 URL”之间的区别。我们之前已经写过关于这方面的文章，但是为了这篇文章的阐述，您只需要记住：所有 URL 也是URI。重要的部分是开头的“方案”。您已经熟悉 https:// 和 https:// 方案，甚至可能遇到过 ftp:// 或 feed://。所有这些都表明所请求内容的类型，并且您的移动 App 可以注册自己的自定义 URI 方案。例如，myapp://。
如果您正在研究深度链接，那么您可能会遇到有关 URI 方案的重要内容。纵观 App 开发历史，URI 方案在大部分时间都是深度链接到 iOS 和 Android 上 App 的主要方法。
遗憾的是，自定义 URI 方案有很多缺点，最明显的一点就是无法轻松处理以下两种情况：
myapp:// 时。URI 方案没有内置的回退选项，这意味着如果用户在单击朋友分享的链接时没有安装 App，他们只会看到一个错误页面。此外也没有中央注册系统，这意味着可能会发生 URI 冲突（Apple 的官方显示是“当前没有进程…”）。很多开发者使用复杂的 JavaScript 重定向来解决第一个问题，但是当有新的 iOS 版本发布时，这些方法就会中断。第二个问题可能永远不会有解决方法。
由于这些限制，iOS 和 Android 分别制定了Universal Links（通用链接）和 App 链接的第二代深度链接标准。从那以后，Apple 便禁止将 JavaScript 重定向方法用于 URI 方案，因而 Universal Links（通用链接）成为了 iOS 深度链接的必备选项。App 链接的采用率则低得多。
URI 方案是您的 App 特有的内容“类型”，与 URI 方案不同，Universal Links（通用链接）和 App 链接只是标准的深度网络链接
(https://example.com)，既指向网页又指向 App 中的内容。打开 Universal Links（通用链接）或 App 链接时，设备将检查是否有任何已安装的设备注册到该域。如果有，App 将立即启动，而不会加载网页。如果没有，则在默认的网络浏览器中加载网络链接（可以是到 App 商店或 Play 商店的简单的重定向）。
如果您完全参与衡量和分析，那么您可能会在这里注意到一个问题：“App 立即启动”意味着针对网络和电子邮件营销的传统跟踪方法（所有这些方法都基于重定向链接）不再起作用。这可能是一个严重的问题，Universal Links（通用链接）和 App 链接标准目前都没有任何解决方案。您唯一的选择是在 App 打开后反向衡量点击次数。
Universal Links（通用链接）实际上并不是”通用”的。诸如 Facebook 和 Twitter 之类的主要平台根本不支持 Universal Links（通用链接），并且右上角看似友好的按钮也没有暗示它本质上是一个“危险选项”。这个选项会使得访客很容易无意间禁用 Universal Links（通用链接）。一旦禁用，普通用户极有可能不知道该如何逆转此进程，从而导致他们认为您的 App 出问题了。
更糟糕的是，采用 Universal Links（通用链接）会面临重重阻碍，因为 Apple 不提供验证器工具，很难对其进行测试。
Apple 承认了这样的说法。从 iOS 9.2 开始，Apple 不再正式支持深度链接的 URI 方案，开发人员不得不实施 Universal Links（通用链接），才能在 iOS 上获得同等的功能。
实际上，情况并非如此。虽然 Universal Links（通用链接）非常好用，但是仍然有很多地方需要使用 URI 方案作为备用方法，如果完全依赖 Universal Links（通用链接），则会在 Table 上留下大量流量。Android 生态系统过于分散，甚至考虑在不久的将来放弃 URI 方案。
我们还有一个更重要的概念还没有讨论：延迟深度链接。无论是通过 URI 方案、Universal Links（通用链接），还是 App 链接实施，这些标准深度链接都只能在设备上已安装 App 的情况下发挥作用。如果没有安装，它们最多只能将您的用户引导到 App Store 或 Play 商店。但是，如果您想将用户引导到 App 中的正确位置，即使要先让用户安装 App，那该怎么办呢？
您可能还会接触到另外两个不太常见的深度链接标准：Chrome Intents 和 Facebook App 链接。
Chrome 团队为自定义 URI 方案自行开发构建了自己的扩展，目的是在未安装 App 时提供回退行为。虽然可以很好地解决潜在问题，但只有 Android 版本的 Chrome 浏览器和少数第三方 App 才支持 Chrome Intents。这意味着每次实施深度链接都很复杂，因为您现在需要同时支持标准技术和特定于 Chrome 的替代方案。
Facebook 在 2014 年创建了App 链接，作为解决 URI 方案深度链接局限性的开放标准。App 链接有两个主要组成部分：
App 链接标准有一个关键的限制：它要求源 App 和目标 App 同时工作。尽管元标记组件被广泛采用，但路由引擎的唯一主要实现是在核心 Facebook 和 Messenger App 中。Facebook 现在更倾向于将用户保留在自己的平台内，并已从除主要 Android App 之外的所有位置删除了 App 链接路由引擎。由于 Facebook 还阻止 iOS Universal Links（通用链接），因此没有可靠的方法可以在 iOS 上从 Facebook 或 Messenger 打开第三方 App。Branch 已经实施了一个解决方案来绕过这些限制。
移动 App 深度链接领域仍然是处于“四分五裂”的局面。达成统一的行业标准仍然任重而道远。但是，这不是给客户带来不良用户体验的借口。
您需要深度链接，并且需要利用所有不同的标准来实现。Branch 延迟深度链接同时支持 URI 方案、Universal Links（通用链接）、App 链接、Chrome
Intents和 Facebook App 链接，因此您不需要自己亲力亲为。
想不想不用大费周章就轻松实施处理所有这些不同标准并提供统一的分析和归因数据的深度链接？请单击此处索取 Branch 演示程序。
现在订阅每周博客摘要，其中包含移动增长技巧，行业更新和产品公告！