你是不是也在想——“鸿蒙这么火我能不能学会”答案是当然可以这个专栏专为零基础小白设计不需要编程基础也不需要懂原理、背术语。我们会用最通俗易懂的语言、最贴近生活的案例手把手带你从安装开发工具开始一步步学会开发自己的鸿蒙应用。不管你是学生、上班族、打算转行还是单纯对技术感兴趣只要你愿意花一点时间就能在这里搞懂鸿蒙开发并做出属于自己的App关注本专栏《零基础学鸿蒙开发》一起变强每一节内容我都会持续更新配图代码解释全都有欢迎点个关注不走丢我是小白酷爱学习我们一起上路 全文目录前言一、隐式 Want 为什么离不开 skills二、action不是目标组件名而是“我要做什么”三、entities在 action 基础上继续缩小范围四、URI不仅要有链接还要匹配链接特征五、module.json5 到底怎么参与匹配六、搭一个最小调用场景七、几个比较容易理解错的地方1. skills 属于目标方不是调用方2. skills 要放到真正负责接收请求的 UIAbility 下3. 不要只检查 action4. URI 看起来一样不代表配置一定一样5. HarmonyOS 7 不应继续照搬旧版本的“万能隐式 action”思路八、实际项目中怎么排查开发经验总结前言上一篇如果已经把 Want 理解成“描述我要去哪里、要做什么”的信息载体那么继续往下就会遇到一个很实际的问题显式 Want 可以直接写 bundleName、abilityName隐式 Want 没有指定目标组件系统凭什么知道该把请求交给谁答案就在目标应用的skills。隐式匹配并不是系统“猜”哪个应用合适而是调用方给出 action、entities、URI 等条件目标 UIAbility 再通过module.json5中的skills声明自己能够处理哪些请求。两边条件能够匹配目标组件才有机会进入后续启动流程。华为当前官方文档也把“显式 Want 与隐式 Want 匹配规则”作为 Want 的核心内容单独说明。本文继续沿着“Want → skills”这条线用一个 URL 跳转的最小场景把 action、entities、URI 和module.json5串起来。需要先说明版本背景HarmonyOS 7.0 对应 API 26.0.0华为官方建议使用 26.0.0 开发套件进行升级适配。本文涉及的UIAbilityContext属于 Stage 模型能力其接口体系从 API version 9 开始提供文中用于 URL 跳转的openLink从 API version 12 开始支持因此在 HarmonyOS 7 / API 26.0.0 范围内可用。一、隐式 Want 为什么离不开 skills显式 Want 的思路很直接letwant:Want{bundleName:com.example.target,abilityName:EntryAbility};这里已经把目标应用和目标 UIAbility 写出来了系统不需要再根据业务意图寻找候选组件。隐式 Want 则不同。它更像是在描述letwant:Want{action:ohos.want.action.viewData,entities:[entity.system.browsable],uri:https://www.example.com/article/1001};这段代码的重点不是让大家直接把它作为 HarmonyOS 7 跨应用 URL 跳转的推荐实现而是观察隐式请求携带的三个维度action想执行什么操作entities目标组件还应该属于什么类别uri准备处理什么数据或资源。官方对 action 的定义也是“调用方要执行的通用操作”而 entities 是目标应用组件的类别信息是对 action 的补充。调用方在 Want 中声明这些条件被调用方则在配置文件的skills中通过actions、entities等字段声明自己支持什么。因此排查隐式 Want 找不到目标应用时不能只盯着调用方代码。Want 是请求条件skills 是目标组件提供给系统的匹配条件。这就是从上一篇 Want 继续往下理解 skills 的关键。二、action不是目标组件名而是“我要做什么”action最容易被误解成某个 Ability 的别名。实际上它表达的是操作意图。例如官方目前仍明确列出的ohos.want.action.viewData对应查看数据这一类操作当它和网址 URI 配合时可以表达“查看这个网址所对应的数据”。目标应用如果要参与这种匹配就需要在对应 UIAbility 的skills.actions中声明支持相应 action。也就是说调用侧和目标侧形成的是这样的关系Want.action ↓ skills.actions这里有一个 HarmonyOS 7 开发时尤其应该注意的变化华为当前文档已经将“常见 action 与 entities”标记为不推荐使用原因是 action/entity 曾被泛化使用系统难以约束应用虚假声明官方表示后续会逐步废弃非必要 action/entity并建议通过指定类型的方式拉起应用。所以本文并不建议为了自己的业务随意设计一套通用 action/entity然后期待任意第三方应用参与匹配。但这不代表skills.actions已经没有作用。恰恰相反在官方明确规定的场景中仍然需要严格配置。例如openLink处理 App Linking 时目标 UIAbility 就必须包含ohos.want.action.viewData。三、entities在 action 基础上继续缩小范围如果说 action 回答“做什么”entities 更接近“由哪一类组件来做”。官方文档将 entities 定义为目标应用组件的类别信息是对 action 的补充。例如entity.system.browsable表示浏览器类别。在 Want 中设置 entities可以进一步过滤匹配的 Ability目标组件则在skills.entities中声明自己支持的类别。关系可以继续补完整Want.action → skills.actions Want.entities → skills.entities在 App Linking 场景中这两个条件是配套出现的。官方对UIAbilityContext.openLink的要求很明确目标 UIAbility 的过滤器中actions要包含ohos.want.action.viewDataentities要包含entity.system.browsable。这也是为什么只看调用方的 URL 往往排查不出问题。URL 完全正确并不代表目标 UIAbility 已经声明“我愿意处理这种请求”。四、URI不仅要有链接还要匹配链接特征到了 URI匹配条件会更具体。URI 可以继续拆成 scheme、host、path 等部分。官方应用链接配置文档中skills.uris可以描述这些 URI 特征其中还提供path、pathStartWith、pathRegex等路径匹配方式。官方特别提醒scheme 和 host 建议使用小写配置path、pathStartWith、pathRegex时值的前后不要添加/。例如准备处理https://www.example.com/article/1001目标应用可以围绕https、www.example.com和article这几个特征声明自己的处理范围而不是笼统地认为“我的应用能打开网页所以任何 https 地址都应该找到我”。真正需要关注的是请求 URI ↓ scheme host path ↓ skills.urisaction、entities、URI 放在一起之后隐式匹配的思路就清楚很多了系统不是拿一个字符串去搜索应用名而是在用请求特征筛选具备对应处理能力的组件。五、module.json5 到底怎么参与匹配module.json5不是普通的业务参数文件。HarmonyOS 应用中的每个 Module 都有独立的module.json5其中包含 Module 基本信息、UIAbility / ExtensionAbility 等组件描述以及运行所需配置。官方应用程序包术语中也明确说明每个模块都有自己的module.json5。对于 UIAbilityskills就配置在abilities对应组件下面。下面把场景缩小到一个容易复现的例子目标应用希望处理本站文章链接https://www.example.com/article/...按照官方 App Linking 对目标组件过滤器的要求可以把关键配置组织为{ module: { // 省略其他模块配置 abilities: [ { name: EntryAbility, srcEntry: ./ets/entryability/EntryAbility.ets, exported: true, skills: [ { actions: [ ohos.want.action.viewData ], entities: [ entity.system.browsable ], uris: [ { scheme: https, host: www.example.com, pathStartWith: article, domainVerify: true } ] } ] } ] } }这里真正应该看的不是 JSON5 有多少字段而是skills里的三层条件actions → 处理什么操作 entities → 组件属于什么类别 uris → 能处理什么链接对于 App Linking官方要求actions包含ohos.want.action.viewData、entities包含entity.system.browsable并且uris中存在scheme为https、domainVerify为true的元素。pathStartWith: article则继续把处理范围限制到相应路径。URI 配置字段和路径规则可参考官方 Application Link Description。六、搭一个最小调用场景到了 HarmonyOS 7如果目标是通过 URL 打开对应应用更合适的最小示例不是继续用一个泛化 action 调用任意第三方应用而是按照官方应用间跳转能力使用openLink。UIAbilityContext.openLink从 API version 12 开始提供通过标准 URL 基于隐式 Want 匹配规则拉起目标 UIAbility。官方最新 API 文档显示该接口覆盖 Phone、PC/2in1、Tablet、TV、Wearable 对应版本并明确给出了前面提到的 skills 过滤条件。页面中可以写一个最小调用import{common}fromkit.AbilityKit;import{BusinessError}fromkit.BasicServicesKit;EntryComponentstruct Index{build(){Column(){Button(打开文章).onClick(async(){constcontextthis.getUIContext().getHostContext()ascommon.UIAbilityContext;try{awaitcontext.openLink(https://www.example.com/article/1001);}catch(err){consterrorerrasBusinessError;console.error(openLink failed, code${error.code}, message${error.message});}});}.width(100%).height(100%)}}这段代码只解决一个问题发起一个标准 URL 的应用链接跳转。真正决定目标应用能不能进入匹配范围的部分反而主要在目标方module.json5。这也是本文最想强调的排查思路调用 API 没写错并不意味着匹配条件已经成立。根据官方接口定义openLink还可能返回16000019含义就是没有找到匹配的 Ability。因此看到这类错误时与其立刻怀疑 ArkUI 按钮、Promise 或页面生命周期不如先回到目标方的 skills。七、几个比较容易理解错的地方1. skills 属于目标方不是调用方Want 描述“我要什么”skills 描述“我能处理什么”。如果 A 应用希望打开链接B 应用希望成为处理方那么需要重点检查的是 B 应用目标 UIAbility 对应的skills而不是给 A 应用也复制一份相同配置。2. skills 要放到真正负责接收请求的 UIAbility 下module.json5中可能存在多个 Ability。skills是组件级匹配条件。如果把配置写在 EntryAbility但实际设计中希望另一个 UIAbility 承接请求就需要重新核对配置归属。官方工程配置也明确把skills放在具体的abilities项内。3. 不要只检查 action这是隐式 Want 排查中很容易形成的思维惯性action 一样 应该能匹配实际上 URL 场景还要继续检查 entities 和 uris。以 App Linking 为例官方对 action、entity、HTTPS URI 和domainVerify都有明确要求。4. URI 看起来一样不代表配置一定一样下面这些差异都值得单独核对http / https example.com / www.example.com article / articles path / pathStartWith / pathRegex官方还特别提醒 scheme、host 的大小写以及路径配置中/的写法。URI 匹配失败时建议把完整链接拆成 scheme、host、path 三部分逐项比对而不是盯着整条字符串看。5. HarmonyOS 7 不应继续照搬旧版本的“万能隐式 action”思路这一点非常关键。华为当前已经明确将通用 action/entities 文档标记为“不推荐使用”并建议针对应用跳转采用指定类型等方式。与此同时startAbility最新 API 文档还列出了 API version 12 的第三方应用重定向限制错误16000018。所以学习 skills 的目的不应该变成“设计一个 action 就能随便拉起任何应用”而应该理解系统的匹配模型再根据具体业务选择官方当前推荐的应用跳转方式。URL 场景使用 Deep Linking / App Linking导航、邮件、图片编辑等垂类场景则应该继续查对应的官方“指定类型应用”能力而不是把所有需求都塞进自定义 action。八、实际项目中怎么排查如果出现“隐式 Want 发出去了但找不到目标应用”可以按下面顺序检查先确认场景和 API 版本。HarmonyOS 7 对应 API 26.0.0不要直接照搬早期 HarmonyOS NEXT 示例同时确认当前场景应该使用startAbility、openLink还是指定类型应用启动能力。确认请求是不是隐式匹配。如果已经给出 bundleName、abilityName就应优先按显式 Want 的思路排查而不是一直检查 skills。检查 action。调用侧表达的操作与目标 UIAbility 的skills.actions是否符合该能力的官方要求。检查 entities。不要因为 action 对上了就忽略类别过滤条件。拆开检查 URI。分别核对 scheme、host 和 path特别留意大小写、pathStartWith等规则。确认 skills 配置到了正确 UIAbility。一个 Module 里存在多个 Ability 时尤其容易看错位置。再检查组件启动约束。如果已经完成匹配但仍无法启动再继续核对组件可见性、应用间跳转规则以及对应 API 返回的错误码。startAbility与openLink的最新文档都列出了明确的启动错误码可以根据错误码继续缩小范围。开发经验总结从 Want 继续理解 skills真正需要建立的不是“记住几个 JSON 字段”而是一套匹配思维显式 Want 是直接指定目标隐式 Want 是描述目标应该具备什么能力。而目标应用能否被找到要看对应 UIAbility 有没有通过module.json5的skills声明匹配条件。action 解决“做什么”entities 继续描述目标类别URI 把范围收缩到具体数据或链接到了 HarmonyOS 7还要额外关注官方当前的应用间跳转规则不能把早期的通用 action/entity 用法直接当成所有场景的推荐方案。如果遇到No matching ability is found这里先别急着改业务代码。把 Want 或链接条件放在左边把目标 UIAbility 的 skills 放在右边一项一项对照通常比从页面逻辑开始翻代码更接近问题本身。而这也正好把 Want 的学习链条接了起来Want ↓ 显式 / 隐式 ↓ action entities URI ↓ module.json5 ↓ skills ↓ 目标 UIAbility理解到这里再继续看 Deep Linking、App Linking、文件处理或指定类型应用启动时会发现它们并不是几套互不相关的 API而是在不同业务约束下对“如何描述请求、如何声明接收能力”这件事做了更具体的规定。如果正在排查自己的隐式匹配问题可以先问一个很简单的问题调用方已经说清楚“我要什么”了那么目标 UIAbility 有没有在 skills 里准确声明“这个请求我能处理”❤️ 如果本文帮到了你…请点个赞让我知道你还在坚持阅读技术长文请收藏本文因为你以后一定还会用上如果你在学习过程中遇到bug请留言我帮你踩坑