HarmonyOS 7 精准碰一碰发送文件选谁接收文件插哪两个决策别混在一起电脑里已经选中了两张照片手机却碰到了第三张应该分享哪几张另一边手机把图片传给电脑文件还没到电脑上的列表已经重新排序原先记住的下标还能拿来插入吗这两个问题都发生在精准碰一碰但不能共用一个“命中哪个下标就操作哪个下标”的实现。发送端处理的是选择优先级接收端处理的是异步过程中的位置稳定性。前者选错会发错文件后者选错会把文件插到意料之外的位置。本文以官方API26电脑精准碰一碰示例为起点把这两个决策独立出来。平台负责分享能力与数据回调应用负责选择文件、确定插入位置和处理列表变化。这次新增的究竟是什么碰一碰本身不是HarmonyOS 7才出现。本文关注的是API26新增的触点信息以及电脑端结合触点实现精准分享的方式。官方文件分享最佳实践更新于2026年9月15日手机与电脑、平板互传指南更新于6月12日本文核对日期为9月27日。开发指南说明API26可以通过分享目标的getInfo获取触点坐标坐标原点在屏幕左上角。coordinate可能不存在不能把缺失的触点强行变成(0,0)。坐标原点本身也可能是有效位置判断时不能写成“x或y等于0就无效”。本文按当前最佳实践的电脑/2in1路径展开。手机与电脑需要登录同一华为账号设备能力、系统版本和实际硬件条件也要满足。不能因为一个回调类型出现在公共参考里就认为每类设备都能走相同的窗口注册和接收流程。本地验证范围也提前说明下文选择与插入算法、回归断言在Node.js中运行Share Kit接入片段按官方接口整理未完成API26 SDK编译和设备间传输实测。示意图不是实机截图模型测试不代表设备兼容性验证。案例一有选中项时触点不应该覆盖选择官方示例先检查手动选中的文件。如果有选中项就分享选中项没有选中项时才使用触点去命中文件。没有命中则终止发送。这样处理符合文件管理器的常见操作习惯明确选择表达了更强的意图碰到屏幕的某个位置不应悄悄改写已有选择。下面把这一规则改写成不依赖UI的函数输入使用稳定文件ID而不是会随排序变化的数组下标。type FileItem { id: string; uri: string; utd: string }; type SendPlan { ids: string[]; reason: string }; function planSend(items: FileItem[], selectedIds: string[], hitId?: string): SendPlan { const existing new Set(items.map(item item.id)); if (existing.size ! items.length) throw new Error(duplicate item id); const selected [...new Set(selectedIds)]; if (selected.length 0) { // A stale explicit selection must not silently turn into a different file. if (selected.some(id !existing.has(id))) { return { ids: [], reason: selection-stale }; } return { ids: selected, reason: explicit-selection }; } if (hitId ! undefined existing.has(hitId)) { return { ids: [hitId], reason: coordinate-hit }; } return { ids: [], reason: no-target }; }这里有一处刻意比最小示例更保守选中的文件如果已经被删除返回selection-stale不退化成发送触点下的另一张。界面可以提示重新选择不能在不告知的情况下替换发送对象。复现过程很简单准备A、B、C三张图片选中A和B让触点落到C。预期发送A、B。清空选择后再碰C预期只发送C。最后让触点落到空白处预期不调用share。const files: FileItem[] [ { id: A, uri: file://example/A.jpg, utd: general.jpeg }, { id: B, uri: file://example/B.jpg, utd: general.jpeg }, { id: C, uri: file://example/C.jpg, utd: general.jpeg } ]; function check(value: unknown, expected: unknown): void { if (JSON.stringify(value) ! JSON.stringify(expected)) { throw new Error(JSON.stringify({ value, expected })); } } check(planSend(files, [A, B], C).ids, [A, B]); check(planSend(files, [], C).ids, [C]); check(planSend(files, [], undefined).ids, []); check(planSend(files, [removed], C).reason, selection-stale); check(planSend(files, [A, A], C).ids, [A]);测试里的file://example只是模型数据不能拿去发文件。平台接入时需要实际可访问的文件URI。应用私有文件路径应通过fileUri.getUriFromPath转换不能把普通文件系统路径当URI传进去。命中测试不是简单拿两组数直接比较target.getInfo().coordinate里的screenX、screenY处于屏幕坐标系。卡片几何数据如果来自父容器局部坐标二者不能直接比较。窗口偏移、滚动和组件变换都可能让“看起来差不多”的坐标失效。官方最佳实践用KnockRectUtil.hitTestComponentIds完成组件命中。它是配套示例中的工具不是可以从Share Kit直接导入的系统API。接入时应检查工具源码与组件ID提供方式使用与触点一致的坐标基准。本文没有实现多屏、旋转和缩放转换也不提供一个随意除以density就算完成的公式。我们只在命中适配器已经返回稳定ID后调用planSend。这样便于分层定位屏幕点找错了卡片检查几何适配卡片找对了但发送对象不对检查选择规则。两类故障不必混在一个回调里排查。把发送计划接到Share Kit下面是平台适配片段。records必须是从当前文件集合重新解析出的记录uri与utd都要对应实际文件。不能直接信任几秒前保存的数组下标。import { harmonyShare, systemShare } from kit.ShareKit; function sendRecords(target: harmonyShare.SharableTarget, records: systemShare.SharedRecord[]): void { if (records.length 0) return; const data new systemShare.SharedData(records[0]); for (let i 1; i records.length; i) { data.addRecord(records[i]); } target.share(data); }UTD不是装饰标签。图片、视频、普通文件会影响接收端如何识别与处理。可根据文件扩展名使用uniformTypeDescriptor.getUniformDataTypeByFilenameExtension获取类型同时核实扩展名和真实文件内容是否一致。官方也明确提醒内容分享与文件分享不能混合在同一次数据构建中否则可能丢失数据或提示类型无效。本例让构建记录时的异常中断整次发送没有在addRecord失败后继续发送剩余部分。原因是界面表达的是“发送已选中的这些文件”部分成功需要单独的交互说明。业务确实允许部分发送时再返回具体失败项并让界面展示不能静默略过。案例二传输过程中列表排序旧下标指向了别人假设电脑列表是A、B、C手机碰到B准备把新图片N插在B前面。回调最初保存了hitIndex1。传输过程中列表被调整成C、A、BN到达后仍然splice(1,0,N)结果就变成C、N、A、B。代码没越界也没有异常但插入位置已经错了。这个问题靠多判一次数组长度解决不了因为下标仍然合法。更稳妥的方法是先保存“B的ID”文件到达时再根据当前列表寻找B。目标被删除时本文采用追加到末尾的策略文档已经切换时直接拒绝应用这次结果避免把图片放到另一个文档。这两个分支是应用设计选择不是系统强制行为。type ReceiveAnchor { documentId: string; beforeId?: string }; type InsertResult { items: FileItem[]; reason: string }; function captureAnchor(documentId: string, items: FileItem[], hitId?: string): ReceiveAnchor { return { documentId, beforeId: items.some(item item.id hitId) ? hitId : undefined }; } function applyReceived(documentId: string, current: FileItem[], incoming: FileItem[], anchor: ReceiveAnchor): InsertResult { if (documentId ! anchor.documentId) { return { items: [...current], reason: document-changed }; } const ids new Set(current.map(item item.id)); if (ids.size ! current.length) throw new Error(duplicate existing id); for (const item of incoming) { if (ids.has(item.id)) throw new Error(duplicate incoming id); ids.add(item.id); } const index anchor.beforeId undefined ? -1 : current.findIndex(item item.id anchor.beforeId); const at index 0 ? current.length : index; return { items: [...current.slice(0, at), ...incoming, ...current.slice(at)], reason: index 0 ? append : insert-before-anchor }; }函数不修改传入数组先完成重复ID检查再创建新列表。如果处理多个接收记录时逐个异步生成缩略图再逐个splice顺序可能受异步完成时间影响。建议先构建有序incoming再一次性提交列表变更。缩略图生成失败如何显示占位图也应由适配层处理。const anchor captureAnchor(doc-1, files, B); const incoming: FileItem[] [ { id: N, uri: file://example/N.jpg, utd: general.jpeg } ]; const reordered [files[2], files[0], files[1]]; check(applyReceived(doc-1, reordered, incoming, anchor).items.map(x x.id), [C, A, N, B]); check(applyReceived(doc-1, [files[0], files[2]], incoming, anchor).items.map(x x.id), [A, C, N]); check(applyReceived(doc-2, reordered, incoming, anchor).reason, document-changed); let duplicateRejected false; try { applyReceived(doc-1, files, [files[0]], anchor); } catch { duplicateRejected true; } check(duplicateRejected, true); check(files.map(x x.id), [A, B, C]);这个ID应来自应用的数据模型不是文件名、列表位置也不是随意假定平台存在的transferId。重复ID检查只防止本次列表写入冲突不等于实现了跨进程、跨启动的传输幂等。如果需要断点恢复或重复回调消重需要额外的持久化记录与明确的业务键。窗口注册与接收回调别漏掉这几步电脑端监听knockShare需要实际窗口ID。接收端dataReceive还需要声明capabilities包括支持的数据UTD与maxSupportedCount不能传空数组。不要照抄示例里的占位windowId也不要把主窗口和当前子窗口混用。在注册时保存窗口ID注销时用同一个ID比在销毁阶段重新getLastWindow更容易保证对称。应用离开相关页面、退到不需要该能力的状态时及时注销。canIUse检查SystemCapability.Collaboration.HarmonyShare精准交互再按官方示例检查电脑设备与API26可用性旧版本保留原有普通分享入口不调用新接口。接收过程按以下顺序组织在dataReceive得到的ReceivableTarget中读取可选触点完成命中并捕获稳定锚点。调用receive传入通过fileUri.getUriFromPath(context.filesDir)生成的沙箱URI。onDataReceived里从SharedData.getRecords读取接收记录过滤缺少uri的记录异步准备缩略图和应用ID。回到当前文档状态执行applyReceived把新列表交给页面状态管理。onResult以ShareResultCode.SHARE_SUCCESS判断传输结果失败时记录具体结果不把列表预览当成传输成功。onDataReceived处理的应用数据转换与onResult报告的传输结果不是同一个含义。即使系统传输成功应用仍可能因为文档切换而没有插入这时应该展示“文件已接收未放入当前文档”等真实状态并给出查看入口而不是笼统地说整个操作失败或成功。三种方案怎么选方案好处代价与限制一律发送已选文件接收一律追加逻辑少适合作为兼容路径没利用精准触点用户需要额外整理保存命中下标回调直接插入实现短静态列表看起来正确排序、删除、筛选后容易插错明确选择优先接收保存稳定锚点保留意图能应对列表异步变化需要稳定ID、文档身份和失效分支如果只是一次性静态文件列表第一种可以作为起点。需要持续编辑、排序或多文档切换时我会选择第三种。这里的收益是操作语义稳定而不是未经测量的速度提升。这两个纯函数也可以复用于拖放、剪贴板导入和文件选择器返回结果把各入口转换为稳定ID与有序文件记录再交给同一决策层。平台注册、URI权限和设备能力仍然留在各自适配层不能因为决策函数复用就认为所有入口的安全条件都相同。本地与设备验收清单本地回归覆盖选择优先、空选择命中、空白触点、失效选择、去重选择、列表重排、锚点删除、文档切换、重复ID和原数组不变。运行时提取本文两个模型代码块与两个断言块排除带kit导入的接入片段按出现顺序组合后使用TypeScript类型移除执行。设备侧仍需验证同账号支持设备、普通分享降级、窗口移动与滚动后的命中、两个窗口并存、文件UTD匹配、传输取消与失败、接收期间切换文档、后台注销、重新进入注册。尤其要把“几何命中正确”和“文件传输成功”分别记录不能只看一张成功提示截图。精准碰一碰减少的是操作步骤不应该减少应用对选择意图和状态变化的判断。把发送与接收拆成两个可验证的决策后排查时就能具体回答文件选错了、位置找错了还是数据传输出了问题。官方参考碰一碰文件分享最佳实践2026-09-15更新手机与电脑、平板互传内容2026-06-12更新官方多设备交互示例工程