平行视界适配有一种特别像“渲染故障”的业务错误：左右两个页面都声明要显示同一份媒体预览节点，结果只有一边显示，或者其中一边调整透明度时，另一边的内容也跟着变化。把它当成单纯的布局宽度问题，很容易越修越乱。真正需要回到节点树本身：共享数据不等于共享一个实际挂载的UI节点；节点的拥有者、迁移顺序和页面退场时机，必须有清楚的规则。

我用一个应用侧租约模型做这件事，项目叫 PaneNodeLease。示例包含两个逻辑栏位、两份媒体预览和六个调度事件，关注的是节点所有权发生迁移时怎样拒绝跨栏抢占与迟到释放。为了不把抽象模拟说成真机执行，示例同时标记 NodeContainer=NOT_RUN、EasyGo=NOT_RUN。平台API相关的真实挂载代码采用官方NodeController/NodeContainer概念说明，业务租约则通过独立固定夹具计算。

一、问题从两个父节点同时要一个孩子开始

ArkUI的NodeContainer是放置自定义节点树的容器，NodeController负责提供makeNode等生命周期入口。华为官方的自定义占位节点指南特别提醒：一个节点应只作为一个父节点的子节点使用，否则可能出现显示与功能问题。同一个节点通过多个NodeController挂入不同NodeContainer时，往往不会如预期在两边分别出现，属性变化也可能共同影响底层节点。这不是适配规则写错了几个vp就能解决的问题，而是结构共享模型不成立。

平行视界在这里只是业务场景：同一个应用同时出现目录页和详情页，两个页面各自拥有媒体预览。系统负责页如何并排，应用仍需对自己创建和复用的节点负责。左侧目录缩略图可以与右侧详情图共用数据、图片缓存甚至某些纯模型对象，但不宜把同一个已经挂载的FrameNode直接交给两个父容器。本篇关注的正是这条所有权边界，不负责推断平行视界配置文件是否正确，也不讨论GridRow的视觉阅读顺序或Navigation的Dialog栈返回。

这里选媒体预览而不是普通文字，是因为媒体节点经常还持有解码结果、播放控制器或触摸状态。换到右栏之后，左栏的旧释放回调可能晚到；如果它只根据nodeId执行删除，就会把已经迁移到右栏的新租约也清掉。另一种风险是右栏在左栏释放之前直接请求复用当前节点，系统可能只显示其中一个，造成看似随机的空白。于是我们要给“谁可以挂载”和“谁可以释放”分别建立明确判断。

这个门禁的目标不是让两侧最终都持有同一个节点，而是让迁移像资源交接一样有序：先把旧拥有关系撤销，再允许新栏位获取新的租约；旧租约随后来的释放请求不能触碰新拥有者。设备折叠、窗口重新布局、导航切换和后台恢复会制造许多看似同步、实际乱序的触发路径；让状态清单独立存在，就能测试这些路径在同一套规则下是否仍然一致。

二、固定节点、租约、栏位和事件契约

Demo页面为 PaneNodePage，诊断页为 NodeAuditPage，逻辑代码放在 NodeLeasePlanner.ets，本地夹具脚本叫 check-node-lease.mjs。任务ID定为 NOD-1011-30，数据集 pane_nodes_06，活动布局轮次 epoch4，示意时间05:41、电量91%。这里只有LEFT与RIGHT两个业务标识，不能误当成HarmonyOS API返回的真实窗口ID。媒体节点也只是应用分配的 preview-17、preview-18，不是系统FrameNode的真实uniqueId。

六条事件的顺序已冻结：E01 LEFT请求acquire preview-17，租约1，允许；E02 RIGHT请求acquire preview-18，租约2，允许；E03 RIGHT在LEFT仍持有preview-17时尝试acquire租约3，阻断为OWNER_CONFLICT；E04 LEFT用租约1正常release preview-17，允许；E05 RIGHT再次acquire preview-17，租约3，允许；E06 LEFT用已经失效的租约1再次release preview-17，阻断为STALE_LEASE。结果恰好四个允许、两个阻断，不能把“重试被允许”说成前一次冲突根本没有发生。

这个顺序还解释了为什么最终LEFT持有零个节点、RIGHT持有两个节点：RIGHT拥有preview-18的租约2，也拥有preview-17的新租约3；E06旧释放不能撤销它。示例在系统能力未实测的前提下，把含阻断的批次归类为NODE_LEASE_HOLD，而不是全绿完成态。它表达的是“业务策略发现并拦截了两种不安全行为”，不等同于设备发生过真实黑屏或资源已经正确卸载。

NodeController的节点生命周期与业务租约不是一回事。aboutToDisappear是组件相关回调，不能直接推导成业务拥有者一定是当前栏位；rebuild会触发节点提供逻辑，也不自动保证旧父节点的资源已经释放。本文所有权账本需要被调度者显式维护，一次迁移至少包括旧节点解绑、旧租约失效、重新挂载与状态确认。业务快照的版本号是为了防止迟到事件覆盖新状态，而不是为了伪造一个平台没有定义的“NodeContainer租约API”。

三、先用纯业务模型守住两个非法动作

租约本质是带有拥有者和版本号的资源授权。下面的ArkTS风格类型只处理业务表，不涉及NodeController或FrameNode实际操作。这样做的原因很简单：如果连输入事件的允许与拒绝都算不对，把它塞进页面生命周期只会使错误更难复现。节点所有权账本使用独立对象、由一个调度入口串行修改，读页面不能自行清空它。

export type Pane = 'LEFT' | 'RIGHT';
export type Decision = 'ALLOW' | 'OWNER_CONFLICT' | 'STALE_LEASE';
export interface NodeLease { owner: Pane; lease: number; epoch: number }
export interface NodeEvent { op: 'acquire' | 'release'; pane: Pane;
  nodeId: string; lease: number; epoch: number }
export class NodeLeasePlanner {
  private state: Map<string, NodeLease> = new Map();
  apply(e: NodeEvent): Decision {
    if (e.epoch !== 4) return 'STALE_LEASE';
    const old = this.state.get(e.nodeId);
    if (e.op === 'acquire') {
      if (old && old.owner !== e.pane) return 'OWNER_CONFLICT';
      if (old && e.lease <= old.lease) return 'STALE_LEASE';
      this.state.set(e.nodeId, { owner: e.pane, lease: e.lease, epoch: e.epoch });
      return 'ALLOW';
    }
    if (!old || old.owner !== e.pane || old.lease !== e.lease) return 'STALE_LEASE';
    this.state.delete(e.nodeId);
    return 'ALLOW';
  }
}

在E03中，old.owner是LEFT而请求者是RIGHT，模型立刻返回OWNER_CONFLICT，不会修改旧状态。E04删除旧拥有关系之后，E05才能建立RIGHT的新租约。E06继续带着LEFT和lease1，请求者与当下RIGHT的拥有关系不相等，因此只能拒绝，不能因为“这原本确实是LEFT创建的”就允许删除。这个判断是具体的，不依赖UI是否看上去已经转场完成。

对于重复点击与异步队列，还应建立输入顺序。一个事件一旦得到拒绝，调用方可以选择稍后生成新事件，但不能自动把同一失败回调当作成功。真实设备还需要把“节点从父树解除”和“业务账本释放”变成有回执的两阶段过程；示例中的ALLOW只是策略允许执行下一步，不是系统挂载完成。否则业务状态可能在FrameNode实际解绑前就提前宣布已经迁移，从而把竞态搬到另一层。

下图为DevEco Studio白色主题的生成式演示界面。左侧工程树、中央代码、最右侧模拟器以及底部HiLog都采用了同一份任务ID、租约计数与结果状态；这些并不是实际DevEco编译或真机NodeContainer运行的证据。图中标注的OWNER_CONFLICT、STALE_LEASE属于本文应用层Decision枚举，不是HarmonyOS系统错误码。

四、真实挂载留给NodeController，而不是账本对象

业务账本通过之后，才有资格进入真实ArkUI节点阶段。华为文档中的NodeController使用makeNode(uiContext)返回FrameNode，NodeContainer接收对应控制器；同一个节点迁移时，应该先从旧容器移除，随后再交给目标容器。下面这段ArkTS只保留可核对的核心接口形状，说明如何把实际NodeController的可见节点入口收束在一个地方。这里没有创建或持有真实媒体节点，也没有把“业务释放”冒充成ArkUI的自动解绑。

import { NodeController, FrameNode, UIContext } from '@kit.ArkUI';

export class PreviewController extends NodeController {
  private root: FrameNode | null = null;
  makeNode(uiContext: UIContext): FrameNode | null {
    return this.root;
  }
  attachAfterLeaseGranted(node: FrameNode): void {
    this.root = node;
    this.rebuild();
  }
  detachBeforeRelease(): void {
    this.root = null;
    this.rebuild();
  }
}

实际产品需要按官方指南让root来自有效的自定义FrameNode或BuilderNode根，不能把查询得到但不能挂载的代理节点直接返回。detachBeforeRelease只是给渲染层一个解绑入口，异步动画或复杂组件卸载还要等待真实生命周期证据；业务新租约应在确认旧容器不再持有该节点后才授予。官方文档也提醒同一节点只可成为一个父节点的子节点，这正是先解绑、再挂载的依据。

为什么不在E03被拒绝时直接创建一份新的节点？如果业务可以容忍两个独立渲染实例，这确实是另一条实现路线，而且可能更简单。但代价是双实例内存、播放器会话和图片解码资源，需要额外预算。本篇聚焦真正需要迁移的单一节点，不把复制节点和移动节点当成同一个动作。对于目录缩略图和详情大图，两个独立节点共享不可变图片缓存通常更容易维护；只有昂贵且不可随便重建的组件，才值得增加所有权协议。

五、从日志复核一次迁移，而不是看最终两张缩略图

本轮FIXTURE_ONLY流程先按E01、E02建立左右两份拥有关系。E03模拟右栏抢占左栏preview-17，模型把它挡住；这时LEFT依然持有preview-17。E04是唯一一次有效的旧租约释放，之后E05才能合法地把preview-17交给RIGHT。E06是典型的“迟到的释放回调”，它已经没有权力触碰当前RIGHT的租约。页面最后显示LEFT零个节点、RIGHT两个节点，因此可以复算出四个允许、两个拒绝。

可视化演示中，RIGHT栏位用两张示意媒体卡显示preview-17和preview-18，LEFT显示空态。这个布局是模型结果图，不是EasyGo已成功并排布局的证据；即使右栏卡片画得正确，也不等于节点独占约束在实际设备上得到验证。我们把模拟器中的“NodeContainer NOT_RUN”和“EasyGo NOT_RUN”明确写在状态区，就是为了避免一张逼真画面替代真正需要发生的系统挂载。

为了把页面指标和逻辑结果绑定，下面是同一事件序列的Node.js固定夹具。与上面的ArkTS类同理，真实脚本可以引用同构实现进行断言；这里用内建Map和数组重放六条事件，不依赖任何尚未确认的系统SDK调用。调试时更重要的是验证最终所有者和租约值，而不只是看允许次数是不是四。

const events = [
  ['E01','acquire','LEFT','preview-17',1],
  ['E02','acquire','RIGHT','preview-18',2],
  ['E03','acquire','RIGHT','preview-17',3],
  ['E04','release','LEFT','preview-17',1],
  ['E05','acquire','RIGHT','preview-17',3],
  ['E06','release','LEFT','preview-17',1]
];
const ownership = new Map();
function step([id, op, pane, node, lease]) {
  const old = ownership.get(node);
  if (op === 'acquire' && old?.pane && old.pane !== pane) return [id,'OWNER_CONFLICT'];
  if (op === 'acquire') { ownership.set(node,{pane,lease}); return [id,'ALLOW']; }
  if (!old || old.pane !== pane || old.lease !== lease) return [id,'STALE_LEASE'];
  ownership.delete(node); return [id,'ALLOW'];
}
const decisions = events.map(step);
console.log(decisions);
console.log([...ownership.entries()]); // preview-17 RIGHT/3; preview-18 RIGHT/2

这个夹具没有任何真实页面，因而可以稳定地检查E03先被阻断、E04释放后E05再进入、E06旧回调不能删除新状态三个关键转折。正式项目还应给同一节点的并发事件加序列号，并确保所有权状态写入具有单线程顺序或原子事务。若状态保存在进程内Map，应用进程死亡后它会消失；那时节点也应随生命周期销毁，业务详情可以通过稳定ID重建，但不能用旧租约对象恢复一份没有底层UI资源的节点。

六、过期租约为什么必须明确拒绝

在折叠或窗口缩窄过程中，同一个媒体预览可能经历详情页隐藏、目录页显示、右栏重建和页面退场。回调到达顺序未必与用户看到的视觉顺序一致。如果把aboutToDisappear等同于“释放当前nodeId”，旧页面可以在右栏新节点已经出现后误删它。加入租约版本后，释放必须同时匹配nodeId、owner和lease，缺一不可。E06这类事件应该进入审计日志而非被忽略到看不见，因为它能暴露页面生命周期与所有权迁移没有同步的问题。

另一个需要说明的边界是事件代次。epoch4表示本文固定输入属于同一次布局恢复流程，并不代表真实屏幕折叠次数，也不是任何系统枚举值。当下一轮布局从四升到五时，所有尚未消费的旧事件应该被审计为过期；但资源清理不能因此永久跳过，必须有独立于UI回调的最终清理路径。否则以保护新状态为名拒绝旧回调，却让旧资源一直不释放，最终会留下内存问题。业务回调拒绝与底层资源回收需要分层设计。

当节点迁移异常时，不能只在UI上显示一个空框。应记录源拥有者、目标栏位、节点唯一业务ID、租约版本、请求序号、解绑开始与完成、目标挂载结果和失败原因。日志不宜包含图片像素内容或用户隐私元数据，媒体ID在需要时也应脱敏。如果来源页面已经彻底销毁，目标栏位可以选择重新创建新节点，而不是盲目依赖一份失效的FrameNode引用。

七、验收表不能只写“看得到两个窗格”

把这套模型放进测试用例，应先检查六个事件的决策：E01和E02建立所有权；E03被OWNER_CONFLICT阻断且原owner不变；E04释放成功；E05变更到RIGHT；E06被STALE_LEASE阻断且最终owner仍为RIGHT。随后检查RIGHT拥有两个节点、LEFT零个节点，以及两个不同节点各有一份独占的租约。所有判断都来自输入序列，和模拟器画面中的视觉装饰没有关系。

实际DevEco验证要再增加节点与容器层面的检查：一份FrameNode不能同时显示于两个NodeContainer，解绑之后目标才尝试挂载，重新挂载时触摸事件和状态订阅不能遗留在旧页面。关闭详情页、恢复应用、调整分屏宽度与折叠形态都要进入验收矩阵。对于含视频、相机或自绘渲染资源的节点，还需要同时检查解码器/渲染资源生命周期和后台耗电。当前既没有创建真实NodeContainer，也没有调用EasyGo系统布局能力，所以这些都只能标记为待验证项。

性能判断上，可以采用“共享数据、必要时独立节点”的优先级。假如一张封面图本身开销很小，复制一个显示节点通常比开发复杂迁移协议划算；如果节点持有昂贵播放器或离屏渲染上下文，迁移才更值得考虑。任何跨父节点转移的成本都应与内存峰值、可见性、重新初始化耗时一起衡量。本轮模型只证明独占语义，不能证明迁移一定比重建快，也没有产生真实帧率、内存或GPU指标。

如果把这套逻辑用于真实媒体编辑器，还需要研究一个容易忽略的场景：源栏位和目标栏位同时发出“释放”和“获取”的异步请求，两个回调分别经过队列和动画框架，再回到UI线程。单纯依靠时间戳大小并不可靠，因为不同组件拿到的时间可能属于不同阶段。更稳妥的方式是让同一nodeId的操作进入单一串行调度器，所有请求携带单调递增的操作号，只有持有当前租约的人能提交改变。失败的请求保留原始ID供诊断，不应悄悄改写历史结果。

在多形态测试中，还要区分资源对象身份与展示位置。某张媒体图在左栏和右栏看起来内容一样，不意味着它们应该共享同一个FrameNode；如果共享的是不可变字节和解码后的图片缓存，两边仍可使用各自独立的展示节点。反过来，如果业务确实需要保留播放器播放位置等内部状态，就应说明哪些状态属于可迁移的数据模型，哪些只存在于旧节点生命周期内。将这两种状态拆开以后，即便决定重新创建节点，也不必把用户的选择和进度全部丢掉。

租约拒绝还可能导致暂时空态。真实界面不应一直转圈等待那次已经被判定冲突的挂载请求，而应转为“正在等待旧页面释放”或“使用静态缩略图”的可解释降级视图。待释放回执返回后再发起新租约，这比在每次动画帧中反复尝试挂载安全得多。若最终无法完成迁移，应当按产品预算重建独立节点，且必须避免继续沿用旧的触摸监听、回调闭包和播放会话；这些资源需要与租约的退役一同核算。

调试报告建议同时记录策略决定和真实NodeController结果，分别使用两个字段，而不是只写一个success。比如业务模型允许E05，并不代表makeNode返回的FrameNode已成功挂载，真正的系统测试还必须检查容器拥有的子节点是否唯一、旧控制器是否已解绑、可见性和触摸命中是否保持正确。如果在设备侧观察到差异，就从“策略ALLOW之后、真实挂载之前”的阶段入手定位，而不是推翻整套租约模型。这也是本文故意把所有FIXTURE_ONLY结果与设备运行状态分开的原因。

八、把可复核的结论留给下一次集成

这次给出的结论有明确范围：固定夹具六事件中四次允许、两次拒绝，成功挡住一次跨栏抢占和一次旧租约释放，最后preview-17与preview-18都归RIGHT所有，LEFT没有被挂载的节点，业务状态为NODE_LEASE_HOLD。这里的“HOLD”不是失败渲染，而是批次包含被拒绝的风险操作，提醒集成阶段仍需审查。它比凭屏幕截图宣布“节点生命周期已解决”更可用。

真正集成时，建议先在普通单窗口里完成NodeController的attach/detach和节点唯一父容器约束测试，再扩展到Navigation页面切换，最后进入平行视界或折叠屏多窗格流程。如此一来，出现空白时能知道是业务租约、节点解绑还是系统布局条件的问题。应用自定义的租约标识仍由业务层管理，不要把它挂到官方API的名义下。官方可核对依据包括华为NodeContainer/NodeController自定义占位节点文档、共享元素跨容器迁移指南及EasyGo多端布局资料。

最后要保留工程判断：可视化双栏只是结果，真正支撑可维护性的，是每个节点始终只有一个明确拥有者、每一次迁移都有先后顺序、每个迟到释放都有可解释的拒绝原因。未经DevEco编译和设备挂载前，这仍是一份可运行规则模型与设计说明，而不是系统能力已经通过验收的证明。