Share Kit 系列做到分享内容收发之后紧接着要解决的一个问题是应用收到一次拉起怎么判断它是不是被系统分享拉起来的。这个问题我在真机上卡过一次当时页面里已经能拿到分享数据但埋点入口写错了导致分享拉起的流量全被记成了普通启动后台数据一塌糊涂。后来把Want完整打出来逐字段对比才算把这个环节彻底理顺。这篇是“鸿蒙学习实战之路”Share Kit 系列的第 12 篇我不绕弯子直接把系统分享拉起这件事的链路原理、判断思路、日志对比方法和可落地的代码模板一起讲清楚。适合正在做分享接收、应用路由分诊或者单纯想搞懂Want来源判断的鸿蒙开发者。1. 系统分享拉起的完整链路与判断场景1.1 一次系统分享到底经历了什么要判断是不是系统分享拉起先得知道系统分享这条链路本身长什么样。拿最日常的场景举例用户在图库选了一张照片点击“分享”按钮。图库这个应用是“分享源”它把图片的 URI、可能的文本描述、来源包名等信息交给系统分享服务。系统分享服务不会过早决定发给谁它先拉起一个分享面板展示所有声明过“我能接收这类数据”的应用用户选中你的应用后系统再把封装好的Want发给匹配到的应用。这里有几个关键点。第一分享源应用通常不需要知道接收方是谁Share Kit 帮它把数据统一封装成系统标准格式。第二你的应用之所以能出现在分享面板里不是因为你写了什么全局注册代码而是工程里的module.json5配置文件用skills字段告知了系统我能处理什么类型的内容。第三系统拉起你的应用时它不是直接调用你代码里的某个函数而是通过 Ability 生命周期把包含分享内容的Want对象送到你手里。这整条链路里“判断应用是否被系统分享拉起”实际要解决的就是在 Ability 收到Want的那个瞬间准确判断这个Want是来自分享面板还是来自桌面图标、应用内跳转、深链等其它入口。只有把这一步切干净后续路由和数据解析才不会乱。1.2 接收端会收到什么入口方法与 Want 结构在鸿蒙应用里一个常见的 UIAbility 收到新任务时会根据进程状态走两个入口应用进程不存在系统冷启动整个应用会先走到onCreate(want, launchParam)应用进程还活着只是从后台或某个任务切入新的Want会通过onNewWant(want, launchParam)送过来。所以在代码里只写一个入口是不行的两个方法最好都接并且共用同一套判断逻辑。很多新手只处理了onCreate结果应用在后台活着的时候从分享面板再次拉起数据到了onNewWant页面没有任何反应。这里的Want是鸿蒙应用交互的标准载体你可以把它当成一封“邮件”action是邮件标题uri是主要附件parameters是附件之外的一堆补充说明字段bundleName和abilityName是收件人信息。普通点击桌面图标启动这封“邮件”通常是空的或者只有一些基础的启动参数而从系统分享面板拉起时action会是一个分享动作标识uri和parameters里会塞入分享源提供的数据。这就是我们判断的突破口。1.3 需要区分出来的三种典型入口场景实践下来大多数应用要区分的是三类入口桌面图标正常启动、系统分享面板拉起、应用内其它业务跳转。桌面图标启动的特征比较好识别Want里基本没有额外数据uri大概率是空。系统分享面板拉起的特征是数据完整、入口固定只要配置过skills拉起时action通常是对应分享动作。应用内跳转就看你自己的路由实现可以自己在跳转参数里埋一个来源标记比如sourceTypeinner。有些场景还会碰到“从最近任务列表恢复”这种入口它走的也可能是onNewWant但Want数据通常跟你之前收到的最后一份一致不一定是新的分享。如果你的业务逻辑是在每次onNewWant来的时候先判断再处理那最近任务恢复这种场景一般不会篡改你的业务状态。不过为了严谨建议把判断逻辑做成幂等函数同样的Want重复进入也不至于重复处理。2. 判断是否被系统分享拉起的核心思路2.1 第一重判断固定动作标识判断是否被系统分享拉起最直接、最稳定的字段就是want.action。鸿蒙系统在根据skills匹配并拉起目标应用时会把匹配到的 action 原样写入Want。如果你在module.json5里配置的是ohos.want.action.sendData这类分享动作那么被分享面板拉起时want.action就是这个值。判断逻辑写成if (want.action SHARE_ACTION) { // 命中系统分享拉起 }这里有个容易踩坑的点actions数组里写什么Want里多半就是什么但系统版本不同动作标识也可能有差异。不要凭网上的旧文章直接抄一个字符串一定要对着自己工程的module.json5再配合日志确认一次。我在真机上对比过个别定制系统里分享目标匹配到的 action 会被改写或加前缀这种情况下单独用 action 判断就会漏。2.2 第二重判断参数区特征字段只看 action 有一个漏洞如果你的应用同时允许多种方式进入同一个 Ability或者某些低版本系统在分享拉起时 action 没有按预期写入那仅靠 action 就不够可靠。这时候要看want.parameters。参数区是Want里最灵活的一块。分享面板拉起时分享源应用写入的内容、系统补充的一些来源信息往往都会以键值对的形式出现在parameters里。理论上它们都有规律但实际工程里我不建议直接写死某个参数名更稳妥的做法是把分享拉起和普通启动两种情况下的完整Want打日志找出parameters里“分享拉起必有、普通启动必无”的字段把这个字段配在工程配置项里作为第二重判断依据。这种日志对比法看着笨但能应对系统版本差异。因为不同版本下系统分享服务往Want里塞的参数并不完全一样。你直接抄网上的一段参数名很可能在某个真机上就是空的到时候线上埋点全面歪掉排查成本远比多打一次日志高。2.3 第三重判断来源信息与业务兜底除了 action 和 parameters还要考虑“谁拉起你的”。部分场景下Want里会携带发起方应用的包名或一些来源描述你可以把它当作附加校验。比如你只希望某些固定应用分享内容进到你的应用那就在收到分享后校验来源包名不匹配的直接拒绝如果你做的是开放社区类应用任何来源都接收那来源字段只用于统计不参与拦截。兜底策略也很重要。判断函数必须有明确的默认值。我习惯的写法是拿到Want先判空parameters可能是undefined也先做保护如果 action 命中直接返回“是分享拉起”如果 action 没命中再看参数区特征字段特征字段也没配置或没命中就返回false。宁可把一个分享入口漏判成普通入口也不要因为误判把用户的正常启动拉进分享数据处理流程因为后者会造成更恶劣的后果。2.4 把判断逻辑收敛到一个独立函数这三个判断层次如果散落在onCreate、onNewWant和业务页面的代码里后期会很痛苦。建议从最开始就收敛成一个独立函数统一放在utils或common目录入参是Want返回布尔值。这样后续系统版本升级、字段变化时只需要改一个函数不会牵连到页面。这个函数最好还能附带输出一个枚举值比如LaunchSourceNormal、Share、Other。有些场景你不光要判断“是不是分享拉起”还要知道具体是文本分享还是文件分享。函数可以返回一个更丰富的对象把判断结果和业务类型一起吐出来。下面第三部分给出的就是这种写法。3. 实操过程日志对比法与可落地判断代码3.1 搭建一个最小实验工程要验证判断逻辑不需要一开始就把业务逻辑接进来。先建一个干净的鸿蒙工程重点在入口文件里做三件事。第一在module.json5里给入口 Ability 的skills增加分享接收声明。为了测试方便可以先接收图片配置大致如下{ skills: [ { actions: [ohos.want.action.sendData], uris: [ { scheme: file, type: image/* }, { scheme: content, type: image/* } ] } ] }配置完之后这个 Ability 才有可能出现在系统分享面板里。如果scheme或type匹配不上应用不会出现在面板后面所有的判断都无从谈起。第二在EntryAbility里重写onCreate和onNewWant两个方法里都调用同一个打印函数import { UIAbility, Want, AbilityConstant } from kit.AbilityKit; import { hilog } from kit.PerformanceAnalysisKit; export default class EntryAbility extends UIAbility { private printWant(want: Want, tag: string) { try { const json JSON.stringify(want); hilog.info(0x0000, shareDemo, ${tag}: %{public}s, json); } catch (e) { hilog.error(0x0000, shareDemo, print want failed); } } onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void { this.printWant(want, onCreate); } onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void { this.printWant(want, onNewWant); } }这里的核心不是打印本身而是通过打印把“神秘”的Want变成一个可见的 JSON 结构。Want里的uri、parameters等字段通过日志直接摊开后面判断依据就清楚了。第三把工程部署到真机准备一张图片用于分享。模拟器在分享面板的匹配逻辑上没有那么稳定真机实测最可靠。3.2 两类启动方式的日志差异对比实验分两个步骤。第一步直接点击桌面图标启动应用把onCreate里打印出的Want保存下来。正常情况下的日志会看到action为空或者只有非常常规的启动动作uri为空parameters要么为空要么只有几条系统默认参数。第二步从图库选择这张图片点分享在分享面板里选你的应用。这时候系统拉起你的应用可能是冷启动走onCreate也可能是热启动走onNewWant。保存这组日志和第一步对比。实测里比较明显的差异可以整理成一张速查表观察项桌面图标普通启动系统分享面板拉起want.action空或者常规动作分享动作标识常见为sendData一类want.uri基本为空带有分享文件或分享内容的地址want.parameters数据很少数据明显变多包含分享源和扩展参数生命周期入口以onCreate为主冷启动走onCreate热启动走onNewWant拿到这份差异之后不要急着写死字段。我把分享拉起的日志再往细看确认parameters里哪些字段在所有分享场景里都稳定出现然后选择其中一个作为特征字段配置到工程里。这一步做完判断函数的依据就确立了。3.3 一个带来源枚举的判断函数模板基于上面的对比结果可以写出一个相对通用的判断模块。注意下面的SHARE_PARAM_KEY不是某个固定的官方字段请把它当成“你通过日志确认出来的特征字段名”来使用import { Want } from kit.AbilityKit; export enum LaunchSource { NORMAL normal, SHARE share, OTHER other } const SHARE_ACTION ohos.want.action.sendData; // 这里填你在真机日志里确认过、分享拉起时稳定出现的参数键 const SHARE_PARAM_KEY your_confirmed_share_param_key; function isLaunchedByShare(want: Want | undefined): boolean { if (!want) { return false; } if (want.action SHARE_ACTION) { return true; } const params want.parameters as Recordstring, Object; if (!params) { return false; } if (SHARE_PARAM_KEY params[SHARE_PARAM_KEY] ! undefined) { return true; } return false; } export function getLaunchSource(want: Want | undefined): LaunchSource { if (isLaunchedByShare(want)) { return LaunchSource.SHARE; } return LaunchSource.NORMAL; }这个模板最大的特点是判断逻辑独立、可单测。想提高准确性就把SHARE_PARAM_KEY配成日志确认后的真实字段不想依赖参数区就把SHARE_PARAM_KEY留空只靠 action一样能工作。函数里还加了Want判空和parameters判空避免运行时 TypeError。3.4 在入口生命周期里统一接入判断函数写完之后要在两个生命周期入口里统一接入。伪代码如下onCreate(want: Want, launchParam: AbilityConstant.LaunchParam) { const source getLaunchSource(want); if (source LaunchSource.SHARE) { this.routeToSharePage(want); } else { this.routeToMainPage(); } } onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam) { const source getLaunchSource(want); if (source LaunchSource.SHARE) { this.handleShareData(want); } }我实际项目里还要多做一步把source写入一个全局状态或者通过路由参数传给页面这样页面知道自己是怎么被打开。页面拿到分享数据后如果用户再次发起新的分享还要先清理旧数据再渲染新数据否则界面上可能出现上一次分享内容的残留。4. 常见问题与排查技巧实录4.1 分享面板里压根看不到你的应用很多人的问题不是“判断不出来”而是“应用根本没出现在分享面板里”。排查顺序建议如下先看skills里有没有配分享接收动作uris的type是否包含你测试用的内容类型再看测试机应用是否安装的是最新包分享面板有时候会缓存应用能力信息卸载重装能解决不少怪问题最后确认测试时分享的数据类型是不是你声明接收的类型。比如你只声明了image/*却从文档应用分享 PDF应用当然不会出现在面板里。还有一点容易被忽略skills配置的是sendData这个动作但如果你把它配置在了一个没有开放外部访问的 Ability 上系统也无法拉起。被系统分享面板拉起的能力必须允许外部组件访问记得检查exported字段。4.2 action 和参数区字段时有时无在不同真机系统版本上同一份分享数据产生的Want字段可能不同。我在项目里就遇到过一台设备action正常uri正常另一台设备action正常但uri是空数据整个放在parameters里。如果代码里只判断uri第二台设备就会漏。所以判断逻辑要分层优先action其次参数区特征字段最后才是uri等相对不稳的数据位。同时线上保留一条低采样率的日志把每次收到的Want匿名化打印传到后台方便后续排查异常来源。线上打印时注意不要把用户图片路径或分享文本原样落盘先做脱敏。4.3 onCreate 和 onNewWant 到底会走哪个很多开发者对两个入口的关系不清。简单记应用进程不存在时冷启动走onCreate然后进入页面应用进程已经存在时新的Want走onNewWantonCreate不会再次执行。如果你的 Ability 的launchType被设成了singleton那即使进程被杀后重启后续新Want也统一走onNewWant。这意味着判断逻辑如果只在onCreate里放一份热启动场景必然漏。反过来说如果你在onNewWant里处理了分享数据但应用是冷启动onNewWant不会走所以两个入口必须同步接入。我自己写了一个统一入口函数以后这类问题基本绝迹。4.4 热启动时第二次分享内容被吞另一个高频问题应用已经在后台用户第一次从分享面板拉起页面正常显示分享内容。用户退到后台再分享一次页面还是旧内容。原因通常是onNewWant里没有重新读取Want或者读取了但页面在aboutToAppear阶段已经被初始化过一次新的数据没有触发更新。解决办法是在onNewWant里拿到新数据后用页面可观察状态变量保存并在页面侧监听这个状态变化。我通常会在收到判断结果为分享拉起后调用一个事件派发方法把Want解析结果送到当前页面页面收到事件就刷新内容。这样冷启动、热启动都能覆盖。4.5 真机调试时如何快速抓到关键日志用 DevEco Studio 看 Log 面板可以但分享场景容易混入大量系统日志。我的习惯是先用hdc连接设备清空日志再触发分享然后按标签过滤。触发分享前先执行hdc shell hilog -r触发分享后过滤自己的标签hdc shell hilog | grep shareDemo这里的shareDemo就是代码里hilog.info的 TAG。先用这种方式把完整Want打出来判断逻辑的字段依据很快就有了。调完记得把多余的日志删掉避免把用户隐私打上生产日志。5. 过程中踩过的一些坑和后续可以扩展的方向5.1 最典型的一个坑把业务代码写在 onCreate 里我第一次接分享时为了图省事在onCreate里把分享数据解析完直接丢给页面。开发阶段冷启动测得很顺利后来测试从后台热启动再分享无论如何都不生效。检查半天才发现onCreate只会在进程首次创建时执行一次第二次分享走的是onNewWant。从那以后我给自己定了一条规矩所有和入口来源相关的逻辑一律先抽成纯函数再在onCreate和onNewWant里共同调用绝不允许只写在一个生命周期里。5.2 拿 URI 直接读文件踩到权限和格式的坑分享过来的图片 URI 在不同系统版本里可能有两种表现一种是指向应用沙箱内临时文件的路径另一种是带权限描述的远端地址。直接拿字符串去拼接路径、再丢给图片组件加载很容易踩到“文件不存在”或者“没有权限”的报错。稳妥的做法是拿到 URI 后先用fs.open或图片加载框架统一处理不要自己拼路径。同时要注意分享数据本质来自别的应用处理前最好做一下类型和大小校验避免异常数据撑爆内存。5.3 后续可以扩展的三个方向第一把判断逻辑从应用级抽取成公共库。团队里多个应用都要接分享接收字段确认、日志对比这套方法完全可以沉淀成一个 ohpm 公共包每个应用只需要配置自己的特征字段。第二把“分享拉起”作为埋点维度纳入数据看板。判断准确之后我能看到分享拉起的用户占比、分享内容类型分布、来源应用排行这对运营和产品迭代很有价值。第三结合路由框架做统一入口管理。让Want先经过一个统一分发层再进入页面后续增加新的入口类型时业务代码改动量会很小。我现在的项目已经把这套判断逻辑固定下来了后续计划把它抽成一个内部小组件加上分享来源统计和异常告警。等跑一段线上数据再回来写更细的经验。
