做鸿蒙接入Share Kit的这几个月我遇到过最迷惑的一个问题就是用户明明从系统分享面板里点了你的App但你在onCreate里拿到的Want跟用户正常点击图标打开应用的Want几乎一模一样。如果判断错了轻则收不到分享数据重则把分享入口当成普通启动业务直接白屏。这篇就是Share Kit系列里专门讲“判断应用是否被系统分享拉起”的一篇。我会从入口链路的本质讲起给出完整的判断骨架、冷启动/热启动的差异、还有我实际踩过的四个判断失效的坑。适合已经配置好分享接收、正准备处理业务分发逻辑的鸿蒙应用开发者也适合想搞明白分享链路背景的新手。1. 为什么“是不是被分享拉起”这么难判断1.1 同一个入口两种完全不同的打开方式系统分享面板拉起应用走的是隐式Want拉起。用户点图库里的“分享”系统把图片URI封装成一个带动作、类型和数据的Want然后匹配到声明了对应接收能力的应用。整个过程看起来非常像一个普通的Want跳转跟App之间互相拉起业务页面在机制上没有本质区别。问题就出在这里你能不能判断出“这个Want是系统分享面板丢过来的还是某个页面业务代码主动发出来的”很多人以为判断action就够了实际不是。分享拉起时action通常是ohos.want.action.sendToApp但一些深链、第三方拉起也可能带自定义action甚至空action单靠action拦不住所有误判。1.2 want里到底藏了什么一套完整的系统分享拉起Want里会携带这几样东西action系统分享动作标识例如ohos.want.action.sendToApp。data或parameters里的ohos.extra.param.key.uri分享内容的URI可能是文件、图片、文本等。typeMIME类型例如image/png、text/plain。发起方标识通常通过Share Kit的拦截器提供不只是包名字符串。判断的核心思路就是**动作标识匹配 内容数据存在 发起方校验通过三者同时满足才认为是系统分享拉起。**只匹配其中一个早晚会出问题。1.3 判断错首尾的代价有多大我举两个真实场景。第一个App被分享拉起时直接走了正常首页流程用户在分享面板里等半天看到App打开的是一个空白首页分享的图片却不知道去哪儿了。这是“漏判断”。第二个业务里有个自定义deep link路径里碰巧也带了一段URI结果被分享判断逻辑误命中走了分享消费路由用户一打开页面就卡在处理分享数据的逻辑里。这是“误判断”。所以这一篇真正要解决的不是“能不能判断”而是“怎么判断才能不漏、不错”。下面的实现骨架就是围绕这个目标展开的。2. 判断“被分享拉起”的完整实现骨架2.1 初始化Share Kit并挂上拦截器在鸿蒙里接入Share Kit第一步是在EntryAbility的onCreate里初始化服务。这里有个顺序问题Share Kit一定要在判断逻辑使用之前初始化否则后面拿不到合法的调用方信息。我常用的初始化写法大概是这样的SDK版本以你手头为准API名在不同版本里会有细微差异。// EntryAbility.etsArkTS代码示意 import { AbilityConstant, UIAbility, Want } from kit.AbilityKit; import { ShareKit } from kit.InteractionKit; export default class EntryAbility extends UIAbility { onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void { // 初始化要在所有分享判断之前完成 ShareKit.initShareKit({ context: this.context }); // 挂载拦截器 ShareKit.setInterceptor({ onIntercept: (token: string, callback: (result: number) void) { // token 是发起方标识可用于校验。 // 这里返回 0 表示放行本次分享返回非 0 表示拒绝。 const allowed this.verifyCaller(token); callback(allowed ? 0 : 10001); } }); // 解析入口参数判断来源 if (this.isShareLaunch(want)) { this.handleShareIntent(want); } } }注意initShareKit的上下文建议传应用级别的context不要传一个可能随页面销毁的临时上下文。拦截器挂载得越早分享请求进来时越不容易漏。2.2 用action和type做第一层过滤第一层判断尽量简单、稳定。系统分享面板拉起的Wantaction固定为ohos.want.action.sendToApp。判断逻辑可以这样private isShareLaunch(want: Want): boolean { // 第一层动作标识必须匹配系统分享的标准动作 if (want.action ! ohos.want.action.sendToApp) { return false; } // 第二层分享的数据必须真实存在 const content want.parameters?.[ohos.extra.param.key.content]; const uri want.data ?? want.parameters?.[ohos.extra.param.key.uri]; if (content null uri null) { return false; } return true; }这里有两个细节值得展开讲。第一个want.data和want.parameters[ohos.extra.param.key.uri]在很多SDK版本里是等价的但有时系统只塞其中一个。代码里两条路都要取避免因为字段位不同导致漏判。第二个ohos.extra.param.key.content是文本分享场景下的常用字段。如果用户分享的是图库图片、文件管理器里的文件走的则是uri字段。所以第一层判断里要把“文本内容”和“文件URI”都覆盖到后面再根据数据类型走不同分支。2.3 用发起方信息做第二层校验只做action和type判断仍然有一个安全漏洞任何应用都可以自己拼一个ohos.want.action.sendToApp的隐式Want来拉起你的App并且在parameters里塞一段看起来很像分享内容的数据。如果你只是判断action就会把这种伪造请求当成系统分享处理。所以第二层校验要用Share Kit给的token。在拦截器里拿到的token是系统签发的调用方标识你可以用它查发起方的包名、应用名再跟自己的白名单比对。private verifyCaller(token: string): boolean { // 获取调用方信息示例方法名以SDK为准 const callerInfo ShareKit.getCallerInfo(token); if (callerInfo null) { return false; } // 常见校验包名是否在允许列表内、签名是否匹配等 return this.allowedPackages.includes(callerInfo.packageName); }这段逻辑背后真正的价值是区分“系统分享面板”和“应用内伪造Want”。**系统分享面板发起的请求token是合法有效的伪造请求要么token为空要么校验不通过。**有这层把关误判的概率会大幅下降。2.4 把分享内容转成业务可用的数据判断完成之后紧接着就是消费数据。文本分享可以直接读取ohos.extra.param.key.content文件分享则需要处理URI。系统分享传递进来的URI通常是一种带临时授权的内容URI不是你应用沙箱里的路径。直接拿这个URI去做业务处理大概率会失败。正确做法是把它转换成本地可读的文件路径再交给后续逻辑。转换过程中要关心两件事一是转换接口需要在授权有效期内调用二是转换后的临时文件用完要记得清理。private handleShareIntent(want: Want): void { const text want.parameters?.[ohos.extra.param.key.content]; const uri want.data ?? want.parameters?.[ohos.extra.param.key.uri]; if (text ! null) { // 走文本分享分支 this.processSharedText(text); } else if (uri ! null) { // 走文件分享分支转成本地路径再读取 const filePath ShareKit.convertUriToPath(this.context, uri); this.processSharedFile(filePath); } }这里的convertUriToPath在真实项目里可能是封装后的工具方法内部调用的是文件服务相关接口。重点是URI转换不要拖到子线程里慢悠悠处理系统临时授权有时效能尽早转换就尽早转换。3. 冷启动与热启动判断逻辑必须两处同时挂载3.1 第一次被拉起走onCreate第二次走onNewWant这是我觉得整个判断链路里最容易翻车的地方。应用第一次被系统分享拉起时进程可能刚创建系统会走onCreate你在里面做判断没问题。可如果应用已经在后台活着用户又一次从系统分享面板点进来此时不会重新走onCreate而是会回调到onNewWant。很多开发者在onCreate里写满了判断逻辑却忘了在onNewWant里同样挂一份。结果就是冷启动第一次分享一切正常热启动第二次分享就完全没反应。在用户看来就是“分享有时候好使有时候不好使”这类问题实际排查起来非常费劲因为你自己测试的时候常常是杀掉进程测的。3.2 把公共判断抽成一个函数解决办法不复杂把“判断是否为分享拉起”这段逻辑从onCreate里抽出来作为EntryAbility的一个私有方法然后在onCreate和onNewWant里都调用。onNewWant(want: Want): void { super.onNewWant(want, launchParam); // 热启动时入口不重建在这里同样做判断 if (this.isShareLaunch(want)) { this.handleShareIntent(want); } }这么做看起来只是减少重复代码实际意义是避免两处逻辑漂移。你要是图省事复制粘贴了一份后面改了一层过滤条件很容易漏改另一处判断规则迟早不一致。3.3 避免重复消费的幂等设计还有一个连带问题如果应用既走了onCreate又因为某些原因再次进入onNewWant同一个分享请求可能被消费两次。分享数据不是无限可用的尤其是文件URI第一次读取后可能就失效了。我的做法是在handleShareIntent入口加一个请求指纹判断。用URI加时间戳生成一个简单key记录在内存集合里短时间内相同请求直接忽略。这样即使入口重复回调也不会把一份分享内容消费两遍。4. 判断失败的真实排查链路四个最常踩的坑4.1 坑一9000001拦截器拿token失败有段时间分享面板拉起后我的拦截器总是收到一个失败回调错误码是9000001说明token获取或校验失败。日志里token一直是空。排查后发现根因不在拦截器逻辑而在初始化时机。当时我把ShareKit.initShareKit放在了EntryAbility的onWindowStageCreate里而分享请求可能在onCreate阶段就已经开始尝试走拦截器了。初始化还没完成拦截器自然拿不到有效token。修复方式是把初始化提前到onCreate的入口并且最好在第一个耗时操作之前。如果你用的是远程配置文件驱动白名单初始化之后还要注意异步加载完成前不要放行任何分享请求否则会存在一个很短的校验空窗。4.2 坑二热启动后分享无响应我自己第一次测的时候是在DevEco Studio里直接运行然后从图库分享图片。第一次分享成功第二次再分享同一个文件应用毫无反应。排查链路是这样的先看日志发现第二次根本没有走到handleShareIntent再看生命周期发现第二次没有走onCreate最后翻文档确认热启动走的是onNewWant。问题一下就清晰了确实是判断逻辑没挂到onNewWant上。这个坑的隐蔽之处在于如果你每次测分享都先杀掉进程再测永远测不出来。只能说这种测试习惯本身就得改热启动场景是分享消费的高频路径必须专门覆盖。4.3 坑三URI临时授权过期处理到一半没权限文件分享场景下我遇到过一种更隐蔽的情况分享判断成功了URI转换也做了但是子线程读取文件内容时报权限异常。原因在于文件URI是带临时授权的授权有效期非常短。我把URI传给了后台任务队列前面排了几个耗时任务轮到真正读取时授权已经失效。系统此时只能拒绝访问而不是一直保留着临时权限等你去消费。解决思路是把“URI转成本地文件路径”这个动作压缩到入口阶段完成转换成功后后续操作都基于本地路径。如果文件特别大需要异步处理那也要在转换前后就完成授权续期或复制操作。4.4 坑四MIME类型过滤太宽或太窄判断逻辑里type字段同样很关键。有人为了省事只判断action是否为sendToApp不管type有人则把type写得特别死只允许image/*结果文本分享、PDF分享全被拒之门外。正确做法是type和业务分支绑定文本走文本处理分支图片走图片预览分支其他文件走文件保存分支。type不能作为“是否分享拉起”的唯一判断条件但它是“分享内容如何处理”的重要分流条件。过滤太宽会把不该收的数据收进来过滤太窄又会把正常分享挡在外面。4.5 错误码速查现象常见错误码根因处理方式token获取为空9000001ShareKit初始化晚于分享请求初始化提前到onCreate入口拦截器回调失败9000001上下文传错或重复初始化统一使用应用级contextURI读取权限异常自定义安全异常临时授权过期入口阶段立刻转换URI分享无响应无热启动走了onNewWant判断逻辑同步挂到onNewWant表格里这个问题清单本质上代表了一个排查顺序先看初始化时机再看生命周期入口再看授权有效期最后才是过滤条件。我也是踩了几轮之后才把顺序固定下来按这个顺序查能少走很多弯路。5. 真机验证与日志复盘把判断过程“看”清楚5.1 用系统分享面板做端到端测试代码写完能不能判断最终要用系统分享面板做端到端验证。最直接的操作是从图库分享一张图片然后在分享面板里找到你的App点下去看应用能不能正确进入分享消费流程。分享面板里如果没有你的App通常不是判断逻辑的问题而是接收配置没声明完整要回到module.json5里检查接收分享的配置项。有接收配置但进不了消费逻辑才轮到这篇文章里的判断逻辑出场。建议至少覆盖四类场景图库分享图片、文件管理器分享PDF、文本选中后分享文本、App热启动状态下再次分享同一个文件。四类都过一遍判断逻辑才算基本可靠。5.2 用hdc构造分享意图有时候手动从图库分享太麻烦尤其要在自动化测试里覆盖判断逻辑。可以通过hdc直接构造一个带分享动作的启动命令验证入口判断是否生效。hdc shell aa start -a ohos.want.action.sendToApp -d file:///data/test.png -t image/png这条命令的意思是模拟一次系统分享拉起action是分享动作data指向一个图片路径type是图片MIME。执行之后观察应用是否进入了分享处理分支就能快速验证判断逻辑。需要注意file:///data/test.png这个路径必须真实存在且权限允许访问。否则命令会启动应用但后续URI读取失败容易混淆“判断通过但数据读取失败”和“判断没通过”两种问题。5.3 关键日志埋点与复盘示例判断逻辑是否可靠最终要靠日志来复盘。我在isShareLaunch和handleShareIntent里都埋了日志记录action、type、uri、token校验结果、命中分支。分享出现问题时会看这几行日志很快就知道是哪一层拦截住了。一个典型的通过日志[ShareTrace] actionohos.want.action.sendToApp [ShareTrace] typeimage/png [ShareTrace] uricontent://media/external/images/media/123 [ShareTrace] tokenVerifypass [ShareTrace] branchfile一个判断失败的日志[ShareTrace] actionohos.want.action.viewData [ShareTrace] typeimage/png [ShareTrace] uricontent://media/external/images/media/123 [ShareTrace] tokenVerifynone [ShareTrace] branchignore看到action不是sendToApp判断逻辑把它归为普通跳转这往往是上一层的深链入口逻辑没处理好把分享请求先一步截胡了。顺着日志往上查要比盲改判断条件高效得多。说句实在话我在做分享接入的时候一半时间花在了“判断来源”上另一半花在“判断来源之后的数据消费”上。判断这件事看上去只是几行if但和生命周期、授权有效期、MIME分流、token校验缠在一起之后就变得很细碎。把入口逻辑抽成公共方法拦截器尽早挂载两处生命周期入口都覆盖到这套框架跑稳之后后面再接入其他类型分享内容就只是加分支的事了。
鸿蒙Share Kit分享拉起判断：从Want解析到冷热启动避坑指南
做鸿蒙接入Share Kit的这几个月我遇到过最迷惑的一个问题就是用户明明从系统分享面板里点了你的App但你在onCreate里拿到的Want跟用户正常点击图标打开应用的Want几乎一模一样。如果判断错了轻则收不到分享数据重则把分享入口当成普通启动业务直接白屏。这篇就是Share Kit系列里专门讲“判断应用是否被系统分享拉起”的一篇。我会从入口链路的本质讲起给出完整的判断骨架、冷启动/热启动的差异、还有我实际踩过的四个判断失效的坑。适合已经配置好分享接收、正准备处理业务分发逻辑的鸿蒙应用开发者也适合想搞明白分享链路背景的新手。1. 为什么“是不是被分享拉起”这么难判断1.1 同一个入口两种完全不同的打开方式系统分享面板拉起应用走的是隐式Want拉起。用户点图库里的“分享”系统把图片URI封装成一个带动作、类型和数据的Want然后匹配到声明了对应接收能力的应用。整个过程看起来非常像一个普通的Want跳转跟App之间互相拉起业务页面在机制上没有本质区别。问题就出在这里你能不能判断出“这个Want是系统分享面板丢过来的还是某个页面业务代码主动发出来的”很多人以为判断action就够了实际不是。分享拉起时action通常是ohos.want.action.sendToApp但一些深链、第三方拉起也可能带自定义action甚至空action单靠action拦不住所有误判。1.2 want里到底藏了什么一套完整的系统分享拉起Want里会携带这几样东西action系统分享动作标识例如ohos.want.action.sendToApp。data或parameters里的ohos.extra.param.key.uri分享内容的URI可能是文件、图片、文本等。typeMIME类型例如image/png、text/plain。发起方标识通常通过Share Kit的拦截器提供不只是包名字符串。判断的核心思路就是**动作标识匹配 内容数据存在 发起方校验通过三者同时满足才认为是系统分享拉起。**只匹配其中一个早晚会出问题。1.3 判断错首尾的代价有多大我举两个真实场景。第一个App被分享拉起时直接走了正常首页流程用户在分享面板里等半天看到App打开的是一个空白首页分享的图片却不知道去哪儿了。这是“漏判断”。第二个业务里有个自定义deep link路径里碰巧也带了一段URI结果被分享判断逻辑误命中走了分享消费路由用户一打开页面就卡在处理分享数据的逻辑里。这是“误判断”。所以这一篇真正要解决的不是“能不能判断”而是“怎么判断才能不漏、不错”。下面的实现骨架就是围绕这个目标展开的。2. 判断“被分享拉起”的完整实现骨架2.1 初始化Share Kit并挂上拦截器在鸿蒙里接入Share Kit第一步是在EntryAbility的onCreate里初始化服务。这里有个顺序问题Share Kit一定要在判断逻辑使用之前初始化否则后面拿不到合法的调用方信息。我常用的初始化写法大概是这样的SDK版本以你手头为准API名在不同版本里会有细微差异。// EntryAbility.etsArkTS代码示意 import { AbilityConstant, UIAbility, Want } from kit.AbilityKit; import { ShareKit } from kit.InteractionKit; export default class EntryAbility extends UIAbility { onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void { // 初始化要在所有分享判断之前完成 ShareKit.initShareKit({ context: this.context }); // 挂载拦截器 ShareKit.setInterceptor({ onIntercept: (token: string, callback: (result: number) void) { // token 是发起方标识可用于校验。 // 这里返回 0 表示放行本次分享返回非 0 表示拒绝。 const allowed this.verifyCaller(token); callback(allowed ? 0 : 10001); } }); // 解析入口参数判断来源 if (this.isShareLaunch(want)) { this.handleShareIntent(want); } } }注意initShareKit的上下文建议传应用级别的context不要传一个可能随页面销毁的临时上下文。拦截器挂载得越早分享请求进来时越不容易漏。2.2 用action和type做第一层过滤第一层判断尽量简单、稳定。系统分享面板拉起的Wantaction固定为ohos.want.action.sendToApp。判断逻辑可以这样private isShareLaunch(want: Want): boolean { // 第一层动作标识必须匹配系统分享的标准动作 if (want.action ! ohos.want.action.sendToApp) { return false; } // 第二层分享的数据必须真实存在 const content want.parameters?.[ohos.extra.param.key.content]; const uri want.data ?? want.parameters?.[ohos.extra.param.key.uri]; if (content null uri null) { return false; } return true; }这里有两个细节值得展开讲。第一个want.data和want.parameters[ohos.extra.param.key.uri]在很多SDK版本里是等价的但有时系统只塞其中一个。代码里两条路都要取避免因为字段位不同导致漏判。第二个ohos.extra.param.key.content是文本分享场景下的常用字段。如果用户分享的是图库图片、文件管理器里的文件走的则是uri字段。所以第一层判断里要把“文本内容”和“文件URI”都覆盖到后面再根据数据类型走不同分支。2.3 用发起方信息做第二层校验只做action和type判断仍然有一个安全漏洞任何应用都可以自己拼一个ohos.want.action.sendToApp的隐式Want来拉起你的App并且在parameters里塞一段看起来很像分享内容的数据。如果你只是判断action就会把这种伪造请求当成系统分享处理。所以第二层校验要用Share Kit给的token。在拦截器里拿到的token是系统签发的调用方标识你可以用它查发起方的包名、应用名再跟自己的白名单比对。private verifyCaller(token: string): boolean { // 获取调用方信息示例方法名以SDK为准 const callerInfo ShareKit.getCallerInfo(token); if (callerInfo null) { return false; } // 常见校验包名是否在允许列表内、签名是否匹配等 return this.allowedPackages.includes(callerInfo.packageName); }这段逻辑背后真正的价值是区分“系统分享面板”和“应用内伪造Want”。**系统分享面板发起的请求token是合法有效的伪造请求要么token为空要么校验不通过。**有这层把关误判的概率会大幅下降。2.4 把分享内容转成业务可用的数据判断完成之后紧接着就是消费数据。文本分享可以直接读取ohos.extra.param.key.content文件分享则需要处理URI。系统分享传递进来的URI通常是一种带临时授权的内容URI不是你应用沙箱里的路径。直接拿这个URI去做业务处理大概率会失败。正确做法是把它转换成本地可读的文件路径再交给后续逻辑。转换过程中要关心两件事一是转换接口需要在授权有效期内调用二是转换后的临时文件用完要记得清理。private handleShareIntent(want: Want): void { const text want.parameters?.[ohos.extra.param.key.content]; const uri want.data ?? want.parameters?.[ohos.extra.param.key.uri]; if (text ! null) { // 走文本分享分支 this.processSharedText(text); } else if (uri ! null) { // 走文件分享分支转成本地路径再读取 const filePath ShareKit.convertUriToPath(this.context, uri); this.processSharedFile(filePath); } }这里的convertUriToPath在真实项目里可能是封装后的工具方法内部调用的是文件服务相关接口。重点是URI转换不要拖到子线程里慢悠悠处理系统临时授权有时效能尽早转换就尽早转换。3. 冷启动与热启动判断逻辑必须两处同时挂载3.1 第一次被拉起走onCreate第二次走onNewWant这是我觉得整个判断链路里最容易翻车的地方。应用第一次被系统分享拉起时进程可能刚创建系统会走onCreate你在里面做判断没问题。可如果应用已经在后台活着用户又一次从系统分享面板点进来此时不会重新走onCreate而是会回调到onNewWant。很多开发者在onCreate里写满了判断逻辑却忘了在onNewWant里同样挂一份。结果就是冷启动第一次分享一切正常热启动第二次分享就完全没反应。在用户看来就是“分享有时候好使有时候不好使”这类问题实际排查起来非常费劲因为你自己测试的时候常常是杀掉进程测的。3.2 把公共判断抽成一个函数解决办法不复杂把“判断是否为分享拉起”这段逻辑从onCreate里抽出来作为EntryAbility的一个私有方法然后在onCreate和onNewWant里都调用。onNewWant(want: Want): void { super.onNewWant(want, launchParam); // 热启动时入口不重建在这里同样做判断 if (this.isShareLaunch(want)) { this.handleShareIntent(want); } }这么做看起来只是减少重复代码实际意义是避免两处逻辑漂移。你要是图省事复制粘贴了一份后面改了一层过滤条件很容易漏改另一处判断规则迟早不一致。3.3 避免重复消费的幂等设计还有一个连带问题如果应用既走了onCreate又因为某些原因再次进入onNewWant同一个分享请求可能被消费两次。分享数据不是无限可用的尤其是文件URI第一次读取后可能就失效了。我的做法是在handleShareIntent入口加一个请求指纹判断。用URI加时间戳生成一个简单key记录在内存集合里短时间内相同请求直接忽略。这样即使入口重复回调也不会把一份分享内容消费两遍。4. 判断失败的真实排查链路四个最常踩的坑4.1 坑一9000001拦截器拿token失败有段时间分享面板拉起后我的拦截器总是收到一个失败回调错误码是9000001说明token获取或校验失败。日志里token一直是空。排查后发现根因不在拦截器逻辑而在初始化时机。当时我把ShareKit.initShareKit放在了EntryAbility的onWindowStageCreate里而分享请求可能在onCreate阶段就已经开始尝试走拦截器了。初始化还没完成拦截器自然拿不到有效token。修复方式是把初始化提前到onCreate的入口并且最好在第一个耗时操作之前。如果你用的是远程配置文件驱动白名单初始化之后还要注意异步加载完成前不要放行任何分享请求否则会存在一个很短的校验空窗。4.2 坑二热启动后分享无响应我自己第一次测的时候是在DevEco Studio里直接运行然后从图库分享图片。第一次分享成功第二次再分享同一个文件应用毫无反应。排查链路是这样的先看日志发现第二次根本没有走到handleShareIntent再看生命周期发现第二次没有走onCreate最后翻文档确认热启动走的是onNewWant。问题一下就清晰了确实是判断逻辑没挂到onNewWant上。这个坑的隐蔽之处在于如果你每次测分享都先杀掉进程再测永远测不出来。只能说这种测试习惯本身就得改热启动场景是分享消费的高频路径必须专门覆盖。4.3 坑三URI临时授权过期处理到一半没权限文件分享场景下我遇到过一种更隐蔽的情况分享判断成功了URI转换也做了但是子线程读取文件内容时报权限异常。原因在于文件URI是带临时授权的授权有效期非常短。我把URI传给了后台任务队列前面排了几个耗时任务轮到真正读取时授权已经失效。系统此时只能拒绝访问而不是一直保留着临时权限等你去消费。解决思路是把“URI转成本地文件路径”这个动作压缩到入口阶段完成转换成功后后续操作都基于本地路径。如果文件特别大需要异步处理那也要在转换前后就完成授权续期或复制操作。4.4 坑四MIME类型过滤太宽或太窄判断逻辑里type字段同样很关键。有人为了省事只判断action是否为sendToApp不管type有人则把type写得特别死只允许image/*结果文本分享、PDF分享全被拒之门外。正确做法是type和业务分支绑定文本走文本处理分支图片走图片预览分支其他文件走文件保存分支。type不能作为“是否分享拉起”的唯一判断条件但它是“分享内容如何处理”的重要分流条件。过滤太宽会把不该收的数据收进来过滤太窄又会把正常分享挡在外面。4.5 错误码速查现象常见错误码根因处理方式token获取为空9000001ShareKit初始化晚于分享请求初始化提前到onCreate入口拦截器回调失败9000001上下文传错或重复初始化统一使用应用级contextURI读取权限异常自定义安全异常临时授权过期入口阶段立刻转换URI分享无响应无热启动走了onNewWant判断逻辑同步挂到onNewWant表格里这个问题清单本质上代表了一个排查顺序先看初始化时机再看生命周期入口再看授权有效期最后才是过滤条件。我也是踩了几轮之后才把顺序固定下来按这个顺序查能少走很多弯路。5. 真机验证与日志复盘把判断过程“看”清楚5.1 用系统分享面板做端到端测试代码写完能不能判断最终要用系统分享面板做端到端验证。最直接的操作是从图库分享一张图片然后在分享面板里找到你的App点下去看应用能不能正确进入分享消费流程。分享面板里如果没有你的App通常不是判断逻辑的问题而是接收配置没声明完整要回到module.json5里检查接收分享的配置项。有接收配置但进不了消费逻辑才轮到这篇文章里的判断逻辑出场。建议至少覆盖四类场景图库分享图片、文件管理器分享PDF、文本选中后分享文本、App热启动状态下再次分享同一个文件。四类都过一遍判断逻辑才算基本可靠。5.2 用hdc构造分享意图有时候手动从图库分享太麻烦尤其要在自动化测试里覆盖判断逻辑。可以通过hdc直接构造一个带分享动作的启动命令验证入口判断是否生效。hdc shell aa start -a ohos.want.action.sendToApp -d file:///data/test.png -t image/png这条命令的意思是模拟一次系统分享拉起action是分享动作data指向一个图片路径type是图片MIME。执行之后观察应用是否进入了分享处理分支就能快速验证判断逻辑。需要注意file:///data/test.png这个路径必须真实存在且权限允许访问。否则命令会启动应用但后续URI读取失败容易混淆“判断通过但数据读取失败”和“判断没通过”两种问题。5.3 关键日志埋点与复盘示例判断逻辑是否可靠最终要靠日志来复盘。我在isShareLaunch和handleShareIntent里都埋了日志记录action、type、uri、token校验结果、命中分支。分享出现问题时会看这几行日志很快就知道是哪一层拦截住了。一个典型的通过日志[ShareTrace] actionohos.want.action.sendToApp [ShareTrace] typeimage/png [ShareTrace] uricontent://media/external/images/media/123 [ShareTrace] tokenVerifypass [ShareTrace] branchfile一个判断失败的日志[ShareTrace] actionohos.want.action.viewData [ShareTrace] typeimage/png [ShareTrace] uricontent://media/external/images/media/123 [ShareTrace] tokenVerifynone [ShareTrace] branchignore看到action不是sendToApp判断逻辑把它归为普通跳转这往往是上一层的深链入口逻辑没处理好把分享请求先一步截胡了。顺着日志往上查要比盲改判断条件高效得多。说句实在话我在做分享接入的时候一半时间花在了“判断来源”上另一半花在“判断来源之后的数据消费”上。判断这件事看上去只是几行if但和生命周期、授权有效期、MIME分流、token校验缠在一起之后就变得很细碎。把入口逻辑抽成公共方法拦截器尽早挂载两处生命周期入口都覆盖到这套框架跑稳之后后面再接入其他类型分享内容就只是加分支的事了。
