HarmonyOS 7 ArkUI Drag + Window Kit：折叠切换中跨栏拖拽的坐标重映射与事务回滚【鸿蒙心迹】-开发者社区

卡片从“待处理”拖向“进行中”，手还没松，设备正好折回单栏。松手以后，卡片消失了半秒，又同时出现在两个列表里。数据没有丢，用户却完全不知道这次拖拽到底算成功还是失败。

我用BoardMorph Lab把这条边界单独复现出来。拖拽会话drag_20261001_11，对象card_042，pointerId 为 3。11:32 时窗口从 840 vp 的SPLIT切到 420 vp 的STACK，系统记录原因WINDOW_CHANGED；这次跨栏事务被回滚，状态ROLLED_BACK，幽灵预览已释放，重复卡片 0，回滚收口耗时 12 ms。

这不是普通的响应式布局问题。拖拽开始以后，起点坐标、目标区域、列表版本和预览资源已经组成一次临时事务；窗口变化会让原来的坐标系和目标栏同时失效。如果 UI 只重新排版，不通知拖拽事务，最终 drop 就会拿着旧世界的数据提交。

一、看起来是坐标错了，实际是事务没有失效

第一版实现把DragEvent.getX()与目标栏的全局 rect 比较，命中后立即把卡片从 backlog 移到 doing。840 vp 双栏时工作正常，因为两个栏位同时存在，坐标也在同一个窗口快照里。

设备折成 420 vp 后，doing 栏被 Navigation 收进下一页，原来的目标 rect 已经不存在。拖拽框架仍会结束当前手势，业务onDrop也可能收到最后事件。代码拿旧 rect 判断为命中，先删除 backlog 中的卡片；新的单栏页面随后根据旧数据快照又把卡片插回，于是出现短暂消失和重复。

修复的第一步不是重新计算一个 x 值，而是承认窗口变化后，这次跨栏拖拽已经失去原有提交条件。我们允许预览继续跟手到事件结束，但业务事务立即进入INVALIDATED；drop 只能回滚，不能在新布局里猜一个目标。

为了证明问题不是列表组件偶发刷新，我给每次 drag move 都记录 windowEpoch。出错那次，start 与前十二个 move 都是 epoch 8，窗口回调后变成 9，最后的 drop 还带着 8。旧代码只看 pointerId 相同就继续提交，新代码把 epoch 视为提交前置条件。日志从“drop failed”变成“epoch 8 rejected by 9”，问题第一次有了可复现证据。

我也去掉了拖拽开始时给源卡片设置hidden=true的做法。视觉上可以降低透明度，但数据节点必须继续存在；否则布局重建期间源节点被销毁，回滚就找不到稳定锚点。现在源卡片仅进入dragging样式，真正删除只发生在 commit 产生新 board 的那一刻。

二、拖拽开始时冻结业务快照

下面这段代码解决的是“拖拽过程中源列表变化，drop 时不知道该删除哪一版数据”。会话保存卡片 ID、源列、源索引、列表版本、pointerId 和窗口 epoch，不直接修改业务数组。

exportinterfaceDragTxn{sessionId:stringcardId:stringsourceColumn:'backlog'|'doing'sourceIndex:numberboardVersion:numberwindowEpoch:numberpointerId:numberstate:'DRAGGING'|'INVALIDATED'|'COMMITTED'|'ROLLED_BACK'}exportfunctionbeginDrag(card:BoardCard,index:number,board:BoardState,windowEpoch:number,pointerId:number):DragTxn{return{sessionId:'drag_20261001_11',cardId:card.id,sourceColumn:'backlog',sourceIndex:index,boardVersion:board.version,windowEpoch,pointerId,state:'DRAGGING'}}

拖拽开始后，页面只生成预览，不提前 splice 源数组。card_042仍然留在 backlog，直到 commit 事务一次性移动；因此窗口变化或手势取消时，回滚不需要把卡片“猜着放回去”。boardVersion 用于检测拖拽期间其他操作是否改过列表，windowEpoch 用于检测坐标系是否更换。

这个结构只保存业务键，不持有组件引用或PixelMap。预览资源交给独立的 DragPreviewHandle 管理，事件结束时释放。页面重组以后旧组件会销毁，如果事务持有它，回调既可能访问失效对象，也会延迟资源回收。

三、窗口变化只做两件事：递增 epoch，标记失效

Window Kit 回调可能因为折叠、旋转、分屏或自由窗口调整而触发。布局层根据 720 vp 阈值把 840 vpSPLIT改成 420 vpSTACK，拖拽层不关心具体 UI，只关心 windowEpoch 已经变化。

下面这段代码解决的是“窗口回调与 drop 几乎同时到达时，谁有权提交”。控制器串行更新 epoch，并把活动事务标记为INVALIDATED。

exportclassDragWindowGuard{privateepoch:number=1privateactive?:DragTxnbind(txn:DragTxn):void{this.active=txn}onWindowChanged(widthVp:number):void{++this.epoch AppStorage.setOrCreate('layoutMode',widthVp>=720?'SPLIT':'STACK')if(this.active?.state==='DRAGGING'){this.active.state='INVALIDATED'}}canCommit(txn:DragTxn):boolean{returntxn.state==='DRAGGING'&&txn.windowEpoch===this.epoch}currentEpoch():number{returnthis.epoch}}

窗口变化不立即销毁预览，因为此时手指可能还按着，粗暴移除会造成明显闪烁。它只撤销业务提交资格；手势结束后统一执行 preview release。canCommit()在 drop 前最后检查一次，即使 Window Kit 回调只早了几毫秒，也会让旧事务走回滚。

如果窗口宽度变化但布局模式仍是 SPLIT，也仍然递增 epoch，因为目标 rect 已经改变。正式项目可以在新的布局稳定后允许“可迁移拖拽”，但需要重新投影起点、目标、滚动偏移和 hit-test 树；当前 Demo 选择回滚，是更可预测的产品取舍。

窗口回调本身也要去抖，但去抖不能延迟失效判断。第一次尺寸变化立即递增 epoch 并 invalidated，后续连续尺寸只合并布局刷新；如果等 100 ms 后再统一处理，drop 可能已经在这段空窗里提交。安全判断要及时，视觉重排可以节流，这两个动作不能共用一个防抖器。

多窗口场景下，每个窗口拥有自己的 epoch 和活动事务，不能把它们放进应用级单例。用户在两个窗口分别拖拽时，A 的尺寸变化不应让 B 回滚。BoardStore 可以共享业务数据，但 DragWindowGuard 必须绑定具体窗口实例，并在窗口销毁时解除监听。

四、坐标重映射只服务预览，不决定提交

折叠期间为了让预览看起来连续，我保留归一化坐标。开始拖拽时将屏幕位置转换为u=x/width、v=y/height；窗口变为 420 vp 后，预览位置用新的宽高反算。这样幽灵卡片不会突然跑到屏幕外，但这个新位置不代表目标栏仍然有效。

这段代码解决的是“预览需要跟随新窗口，而业务命中仍不能使用旧 rect”。它明确把视觉坐标与业务 drop 分开。

exportfunctionremapPreview(point:Point,from:Size,to:Size):Point{constu=Math.max(0,Math.min(1,point.x/from.width))constv=Math.max(0,Math.min(1,point.y/from.height))return{x:Math.round(u*to.width),y:Math.round(v*to.height)}}exportfunctionresolveDrop(txn:DragTxn,guard:DragWindowGuard,target:DropTarget|undefined):DropDecision{if(!guard.canCommit(txn))return{action:'ROLLBACK',reason:'WINDOW_CHANGED'}if(!target)return{action:'ROLLBACK',reason:'TARGET_MISSED'}return{action:'COMMIT',target:target.column}}

本次预览从 840 vp 坐标系映射到 420 vp，只保证视觉连续；resolveDrop()看到 epoch 不一致，返回WINDOW_CHANGED。不能因为映射后预览碰巧落在某张卡片上，就把它当成新目标。用户开始操作时看到的是双栏语义，折叠后产品结构已经变化，自动猜测可能把卡片送到完全不同的列表。

预览坐标还要考虑安全区和内容滚动偏移。Demo 使用窗口内容区域坐标，不把状态栏高度重复减两次；目标命中使用布局稳定后的局部 rect。不同坐标空间必须用类型或命名区分，screenX、windowX、localX混用比计算公式本身更容易出错。

五、提交与回滚都从同一个出口收口

drop 结束后，控制器根据 decision 进入 commit 或 rollback。commit 先校验 boardVersion 和 cardId 仍然存在，再一次性生成新 board；rollback 不改业务数组，只清除高亮、释放预览并记录原因。两条路径最终都解绑活动事务。

如果列表在拖拽期间被协同更新，boardVersion 已变化，即使窗口没动也要回滚。否则 sourceIndex 可能已经指向另一张卡片。正式工程可以按 cardId 重新定位并做乐观合并，但必须有明确冲突策略，不能悄悄使用过期 index。

资源释放顺序也有讲究：先让事务进入终态，阻止新的 move 回调；再取消自动滚动定时器；随后释放 DragPreviewHandle；最后清除 active。这样晚到的手势事件会看到终态并直接返回，不会在 preview 已销毁后继续更新位置。

commit 使用不可变 board 快照计算下一状态，再一次性交给 Store；不会先从 backlog 删除、随后向 doing 添加。两步式修改在第二步失败时最容易产生丢卡或双卡。rollback 更简单，它不重建数据，只确认原卡仍在 sourceColumn；如果协同更新已经删除该卡，就显示“内容已变化”，不擅自复活旧对象。

自动滚动是另一个容易漏的资源。拖拽靠近栏底时会启动定时器，窗口折叠后旧栏已经不可见；若只释放预览，定时器仍可能修改销毁列表的 offset。事务收口器把 timerId、preview handle 和高亮目标放在同一个 cleanup 中，并用 released 标记保证多次调用安全。

DevEco Studio 图中，左侧目录按drag / window / board / model拆分，中间打开DragWindowGuard.ets，右侧模拟器显示BoardMorph Lab从 840 vpSPLIT到 420 vpSTACK的结果。底部 HiLog 记录session=drag_20261001_11、card=card_042、pointer=3、reason=WINDOW_CHANGED、state=ROLLED_BACK、previewReleased=YES、duplicate=0、rollback=12ms。

六、我故意把窗口回调塞进 drop 前一帧

手工折叠只能证明“某一次没出错”，不能覆盖竞争窗口。我在测试适配器里让窗口变化分别发生在 drag start 后、move 中、drop 前一帧和 commit 校验后。前三种都必须回滚；最后一种已经完成原子提交，新布局只能重新渲染新 board，不能再撤销已提交结果。

另一个测试是重复触发窗口回调。840→700→420 vp 可能产生多次尺寸事件，事务第一次失效后保持INVALIDATED，后续事件只推进 epoch，不重复释放预览。手势结束时 release 一次，live preview 归零。修复前的双释放会在第二次回调里暴露为空句柄异常。

我还在拖拽时让协同数据更新，把card_042排到另一个位置。即使窗口保持 840 vp，boardVersion 不一致也会回滚，重复卡片仍为 0。这样证明我们的事务门禁不是只针对折叠，而是对所有使源快照失效的变化都有效。

测试里还覆盖了手指离开屏幕、系统取消手势和页面被路由替换。三种情况都不会触发 commit，而是生成不同 reason 后走同一 rollback。这样 HiLog 能区分WINDOW_CHANGED、POINTER_CANCELLED与PAGE_DISPOSED，资源释放却只有一套实现，减少异常分支各写一遍造成的遗漏。

性能上，12 ms 是从 invalidated 到预览、定时器和活动事务全部清理的耗时，不包含窗口重新布局。回滚不复制整个看板，只清理会话状态，所以卡片数量增加时耗时基本稳定。若业务需要回放动画，可以在终态后单独执行，不能让动画完成回调决定数据是否回滚。

七、运行结果要让用户知道“没有移动”

回滚不能静默。单栏重建完成后，页面保留card_042在 backlog，并显示短提示“窗口形态已变化，本次移动未生效”。提示不会挡住下一次操作，读屏也会播报一次。状态页同时显示原始与当前窗口、布局模式、回滚原因、预览释放和重复数。

11:32 的手机截图沿用同一组数据：会话drag_20261001_11，卡片card_042，pointer 3，窗口 840→420 vp，布局SPLIT→STACK，原因WINDOW_CHANGED，状态ROLLED_BACK，幽灵预览释放YES，重复 0，耗时 12 ms。红色批注只标出“坐标系已切换”和“事务已回滚”。