HarmonyOS 应用间跳转概述：App Linking / Deep Linking / Want，一篇把链路讲透的笔记（含配置与代码）

HarmonyOS 应用间跳转概述：App Linking / Deep Linking / Want，一篇把链路讲透的笔记（含配置与代码）

鸿蒙第四期开发者活动

你打开一个分享链接，已安装就直达 App 指定页面；没安装就去应用市场/网页 —— 这类“跨应用一键直达”的能力，在 HarmonyOS 里通常归到应用间跳转（Application Redirection / Link Between Apps） 。 官方对“应用跳转”的描述核心就是：从一个应用跳到另一个应用，传数据或执行特定功能。 developer.huawei.com

---

1. 为什么要做“应用间跳转”

在真实业务里，用户经常要跨多个 App 才能完成一次任务，比如：

• 社交分享：朋友发来活动链接 → 点开直接进入活动详情页（带参数）
• 广告/投放：落地页按钮 → 一键拉起 App 的某个页面，提升转化
• Web 与 App 联动：H5 里点击“立即打开” → 进入 App 并定位到对应内容
• 特殊文本跳转：短信/邮件/系统识别的链接 → 触发应用直达

这些典型场景在社区版的“应用间跳转开发指南”里也有整理（社交分享、广告跳转、特殊文本跳转、Web 与应用跳转等）。 harmonyosdev.csdn.net

---

2. HarmonyOS 里常见的 3 种“跳转思路”

你可以把它们当成三层能力：

2.1 Want 跳转（显式 / 隐式）

• 显式 Want：我明确知道目标应用的 bundleName/abilityName，直接点对点启动。
• 隐式 Want：我只描述“我要打开一个 uri / action”，系统做匹配路由到符合 skills 的应用（这就和 Deep Linking 很像了）。

Want 是系统级“启动能力”的基础形态；Deep Linking / App Linking 本质上就是“把 uri 变成可路由的入口”，再落回到 Want 的分发与处理上（理解这一点，你就不容易被名词绕晕）。

---

3. Deep Linking vs App Linking：到底差在哪？

一句话版本：

• Deep Linking：你可以自定义 scheme，接入简单，但缺少域名校验，存在被仿冒风险。 harmonyosdev.csdn.net
• App Linking：限定 scheme 必须是 https，并引入域名校验/域名认证，安全性更高，通常更推荐。 harmonyosdev.csdn.net+1

社区文档把差异写得很清晰（我把关键点提炼成表）：

对比项	App Linking	Deep Linking
scheme	必须 https harmonyosdev.csdn.net	可自定义 harmonyosdev.csdn.net
安全性	域名校验、防仿冒 harmonyosdev.csdn.net+1	缺少域名校验，可能被仿冒 harmonyosdev.csdn.net
前置条件	通常需要在 AGC 开通 App Linking harmonyosdev.csdn.net+1	主要在应用侧配置 skills 即可 harmonyosdev.csdn.net
适用场景	分享/扫码/投放等“需要可信直达”的入口	内部调试、可控环境、对安全要求不高的场景

---

4. 一张“链路图”理解跳转全过程

4.1 已安装：点击链接直达 App 页面

 用户点击链接（App Linking / Deep Linking）
         |
         v
 系统路由（匹配 skills + 校验域名/规则）
         |
         v
 拉起目标 UIAbility
         |
         v
 目标页解析参数（want.uri / query / path）
         |
         v
 导航到详情页 / 执行业务动作

4.2 未安装：走降级策略（常见）

• App Linking 常见做法：未安装 → 应用市场/网页；安装后首次打开还能“恢复意图”（延迟跳转/延迟链接的体验在很多实现里都会提到）。 SegmentFault

---

5. Deep Linking：最关键的是 module.json5 的 skills 配置

Deep Linking 的“入站配置”，核心就是：让系统知道“什么 action + 什么 uri 规则”可以把你这个 Ability 匹配出来。 harmonyosdev.csdn.net

社区示例强调了几个很实用的点（别忽略）：

• actions 不能为空，为空会导致匹配失败。 harmonyosdev.csdn.net
• scheme 不要用系统占用的（如 https/http/file 等），也不要以 "ohos" 开头，避免匹配到系统应用或冲突。 harmonyosdev.csdn.net

示例（按思路精简后保留关键字段，写法以你项目实际为准）：

 // module.json5（示意）
 {
   "module": {
     "abilities": [
       {
         "name": "EntryAbility",
         "skills": [
           {
             "actions": ["ohos.want.action.viewData"],
             "uris": [
               {
                 "scheme": "link",
                 "host": "www.example.com"
               }
             ]
           }
         ]
       }
     ]
   }
 }

有多个跳转场景，就配置多个 skill 对象。 harmonyosdev.csdn.net

---

6. App Linking：为什么更安全？它多做了哪一步

App Linking 之所以“更可信”，关键是 域名校验： 你的应用要和某个 HTTPS 域名建立可信绑定，系统验证通过后，点击该域名下的链接，才会更可靠地“直达正确的应用”，避免被其它 App 冒充。 harmonyosdev.csdn.net+1

常见落地步骤（按社区总结的思路串起来）：

0. 在 AGC 开通 App Linking 服务 harmonyosdev.csdn.net+1
1. 在你自己的域名服务器放置校验文件（例如 .well-known/applinking.json 这类约定路径） harmonyosdev.csdn.net+1
2. 系统校验域名绑定状态（成功会显示 success 类似信息） harmonyosdev.csdn.net
3. 应用内正确解析并处理链接（把参数落到页面导航上） SegmentFault

---

7. 调用方怎么“打开一个链接”：openLink（统一入口）

在“应用内跳转其他应用”的常见场景里，社区给出的做法是：

• 调用方用 openLink(link, options) 启动目标应用
• link 既可以是 Deep Linking，也可以是 App Linking
• 若只想按 App Linking 方式打开，可设置 appLinkingOnly: true harmonyosdev.csdn.net

示例（保持原意，按可读性整理）：

 // 伪代码：在 UIAbility / 页面上下文里
 let link = "https://www.example.com/programs?action=showall";
 ​
 // 仅以 App Linking 的方式打开
 context.openLink(link, { appLinkingOnly: true });

harmonyosdev.csdn.net

---

8. 目标应用怎么“接住参数”：把 want.uri 当成你的入口协议

你最终都要做一件事：解析 URI → 还原业务意图 → 导航到页面。

SegmentFault 的示例给了一个很典型的“带参分享”处理方式：在 onCreate(want) 中解析 want.uri 的 query 参数，然后加载详情。 SegmentFault

示意思路（你可以迁移到自己的路由框架里）：

 onCreate(want) {
   // want.uri 里带了类似 ?eid=567&from=social
   const eid = url.URL.parseURL(want.uri).params.get('eid');
   this.loadEventDetail(eid);
 }

SegmentFault

---

9. 经验小结：我会怎么选型

• 对外分享/扫码/投放入口：优先 App Linking（可信、安全、体验更一致）。 harmonyosdev.csdn.net+1
• 内部联调/可控环境：Deep Linking 足够快（但要意识到它的仿冒风险）。 harmonyosdev.csdn.net
• 应用内点对点拉起：你掌握目标包名能力名时，用 Want/显式启动会更直接。

---