Deep Link：它是什么，链接类型及工作原理

什么是Deep Link

Deep Link（深层链接）是一种URI，点击后打开的并非网页，而是移动应用内的特定屏幕。该技术解决了移动平台的一个根本问题：浏览器无法直接打开应用的屏幕，而deep link在Web与原生代码之间架起了一座桥梁。没有deep link，用户总是会进入主屏幕，不得不手动导航到所需内容。

Deep Link的架构由两部分组成：方案（scheme）确定哪个应用应处理链接，路径（path）指出应用内的具体资源——商品、文章、用户资料或设置部分。查询参数（?source=push&campaign=summer）传递用于分析、个性化和活动归因的额外上下文。

区分deep link与普通链接很重要。普通链接（https://example.com/product/42）在浏览器中打开，指向页面的Web版本。Deep link（myapp://product/42）在应用已安装的情况下会打开相同内容的原生屏幕，如果应用不存在则会显示错误。正是为了解决无缝回退问题，才创建了Universal Link（iOS）和App Link（Android）。

深层链接的类型

不同的任务需要不同类型的deep link。有些链接仅适用于已安装的应用，有些可以等待安装，还有些传递分析上下文。类型的选择取决于使用场景：广告活动、推送通知、内容分享或邮件营销。

标准Deep Link（Standard Deep Link）

Standard Deep Link是基本类型，仅在应用已安装在设备上时触发。用户点击myapp://product/42链接，系统确定已注册的方案并打开应用至相应屏幕。如果应用未安装，浏览器会显示“页面未找到”错误或什么都不做。此类型适用于已安装应用内的内部导航。

标准deep link的配置很简单：只需在清单文件（Android）或Info.plist（iOS）中注册URI方案即可。无需服务器验证或SSL证书。但正是由于缺乏回退，此类型被认为已过时，不适合营销活动——没有应用的用户流量损失高达60%。

延迟Deep Link（Deferred Deep Link）

Deferred Deep Link解决了普通deep link的主要问题：即使应用未安装也能工作。用户点击链接 → 看到页面（着陆页或App Store/Google Play）→ 安装应用 → 首次启动时，应用获取原始链接的上下文并打开相应屏幕。该技术需要中介SDK（AppsFlyer、Branch、Adjust）在服务器上保存上下文直到首次启动。

Branch是最流行的延迟deep link平台之一。它提供一个统一的链接，适用于所有平台：确定用户的操作系统，重定向到应用商店，在安装后传递上下文（促销代码、商品ID、活动来源）。根据Branch（2024）的数据，延迟deep link可将广告活动的转化率提高40–70%。

上下文Deep Link（Contextual Deep Link）

Contextual Deep Link是在普通或延迟deep link基础上增加上下文参数：流量来源（source）、活动（campaign）、促销代码、referrer、合作伙伴ID。参数在URL中传递，由应用处理以实现个性化：显示欢迎奖励、打开折扣商品、记录安装分析。

UTM标记（utm_source、utm_medium、utm_campaign）是传递上下文的标准方式。在移动领域，上下文deep link对于归因至关重要：没有它们，应用所有者无法知道哪个渠道带来了用户——自然流量、Facebook广告、邮件营销还是QR码。高质量的归因需要与MMP（移动测量合作伙伴）集成。

iOS上的Deep Link

iOS通过两种机制支持deep link：旧的Custom URL Scheme和现代的Universal Link（iOS 9+）。Custom URL Scheme的原理是在Info.plist中注册自定义方案。应用注册myapp://，iOS在点击此类链接时会打开应用。问题在于：如果没有应用注册该方案，浏览器会显示错误。

处理iOS上的deep link通过AppDelegate的application(_:open:options:)方法或SceneDelegate的scene(_:openURLContexts:)方法进行。开发者提取URL，解析路径和参数，然后导航到相应屏幕。如果使用SwiftUI，则通过OpenURLAction或onChange(of: openURL)进行处理。正确处理状态很重要：应用可能未启动、处于后台或活跃状态。

安全性在iOS上很严格：任何注册了相同方案的应用都可以拦截Custom URL Scheme。这是一个潜在漏洞（URL Scheme劫持）。因此苹果推荐Universal Link作为更安全的替代方案：只有经过验证的域名所有者才能将链接与应用关联。更多关于Universal Link的信息，请参见Universal Link文章。

Android上的Deep Link

Android通过AndroidManifest.xml中的Intent Filter实现deep link。应用定义处理特定方案（myapp://）或特定主机和路径的Activity。当用户点击deep link时，Android会查找具有匹配Intent Filter的Activity并打开它。如果有多个匹配的Activity，系统会显示应用选择对话框。

// AndroidManifest.xml — 用于Deep Link的Intent Filter
<activity
    android:name=".ui.ProductActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="product"
            android:pathPrefix="/" />
    </intent-filter>
</activity>

处理Android中的deep link在Activity的onCreate()或onNewIntent()方法中执行。开发者获取Intent，提取URI并调用导航。对于Jetpack Navigation，Navigation Deep Link组件允许在导航图中声明式地描述deep link。Android App Link（Android 6.0+）是deep link的演进，通过Digital Asset Links进行验证，消除了应用选择对话框。

需要特别关注Android 12+的变化：从API 31开始，系统要求为处理deep link的Activity显式设置exported=true，并检查Intent Filter的正确性。Google Play Store在发布时会检查App Link验证。如果deep link指向不存在的网站页面，Google可能会拒绝更新。

Deep Link配置

配置deep link包括几个步骤，两个平台通用。第一步是确定方案和URL结构。建议使用https方案（而非自定义方案）以确保与Universal Link和App Link的兼容性。URL结构应重复网站结构：/product/42、/profile/john、/settings/notifications。这简化了维护和搜索引擎的内容索引。

第二步是在应用代码中处理deep link。对于Android，建议使用带有声明式deep link的Jetpack Navigation（nav_graph）。对于iOS，建议使用带有OpenURLAction处理的SwiftUI NavigationStack。处理三种应用状态很重要：冷启动（应用未启动）、温启动（后台）和活跃（在前台）。每种状态需要不同的导航逻辑。

• 确定方案和URL结构（myapp://或https://your.domain/）
• 注册方案到清单文件（Android）或Info.plist（iOS）
• 实现Activity或AppDelegate/SwiftUI中的处理逻辑
• 配置应用未安装时的回退方案
• 测试所有三种状态：冷启动、温启动、活跃

测试deep link是一个单独的任务。Android Studio提供了App Links Assistant工具来检查Intent Filter。在iOS上，通过Xcode使用启动方案参数传递URL进行测试。建议配置CI检查：自动点击deep link并验证是否打开了预期的屏幕。对于延迟deep link，测试包括完整的“安装 → 首次启动 → 上下文”循环。如果不进行测试，deep link在应用导航更新时经常会失效。