HarmonyOS 7 鸿蒙电脑外接屏适配：px 与 vp 混用导致断点错判，怎样验证换屏后的布局

窗口尺寸看起来没变，拖到另一块屏幕后布局却突然变宽，常见原因是把像素宽度直接当作布局宽度。不同密度的屏幕里，同样的 1200px 并不表示相同的逻辑尺寸。尺寸和密度需要作为同一份快照参与计算。

版本与适用范围

官方窗口布局文档区分窗口位置、大小与全局显示坐标，尺寸事件单位为 px。应用应使用当前窗口 UIContext 对应的转换能力获得 vp，避免使用另一窗口或旧屏幕的转换上下文。实验用显式 density 模拟这个单位转换。

官方参考文档，核对日期：2026-09-14。下面的 JavaScript 实验可以直接用 Node.js 运行；它验证应用侧算法与状态边界，不是已经在 HarmonyOS SDK 或真机上跑通的完整应用。应用接入时，SDK 调用、事件订阅和资源释放应分别验证。

问题是怎样发生的

1200px 在 density=2 时是 600vp，density=3 时是 400vp。按像素直接判断会把两者都误判为三列。

复现不依赖随机等待。测试用固定输入、显式完成的异步结果或明确的状态变化，让错误条件可以重复出现。先保留失败信号，再检查修复后的状态，避免只看“没有抛异常”就认为问题解决。

案例一：相同 px、不同屏幕密度

1200px 在 density=2 时是 600vp，density=3 时是 400vp。按像素直接判断会把两者都误判为三列。

案例二：两个窗口加旧事件晚到

主窗口接受 revision=2 后拒绝 revision=1；预览窗口使用独立状态，不应覆盖主窗口断点。

实现代码

export function windowLayout(snapshot) {
  const {widthPx, density, windowId, revision} = snapshot;
  if (!windowId || !Number.isFinite(widthPx) || widthPx <= 0 || !Number.isFinite(density) || density <= 0) throw Error('invalid_snapshot');
  const widthVp = widthPx / density;
  return {windowId, revision, widthVp, columns:widthVp >= 840 ? 3 : widthVp >= 600 ? 2 : 1};
}
export class WindowSnapshots {
  states = new Map();
  apply(snapshot) {
    const previous = this.states.get(snapshot.windowId);
    if (previous && snapshot.revision <= previous.revision) return false;
    const next = windowLayout(snapshot);
    this.states.set(snapshot.windowId, next);
    return true;
  }
}

运行验证

把上面的实现和下面的测试按顺序放进同一个 example.mjs 文件，使用 Node.js 执行 node example.mjs。测试采用 Node 内置的 assert，不需要第三方依赖。断言失败时进程报错，全部通过时正常退出。

import assert from 'node:assert/strict';
assert.equal(windowLayout({windowId:'main',revision:1,widthPx:1200,density:2}).columns, 2);
assert.equal(windowLayout({windowId:'main',revision:2,widthPx:1200,density:3}).columns, 1);
const windows = new WindowSnapshots();
assert(windows.apply({windowId:'main',revision:2,widthPx:1200,density:3}));
assert.equal(windows.apply({windowId:'main',revision:1,widthPx:1200,density:2}), false);
assert(windows.apply({windowId:'preview',revision:1,widthPx:1800,density:2}));
assert.equal(windows.states.get('main').columns, 1);
assert.equal(windows.states.get('preview').columns, 3);

核对时不要把输入样本当作性能数据。上述测试已经在 Node.js 环境逐项执行通过，验证的是代码中写出的条件。涉及窗口、材质、音频或系统入口的真实表现，需要另外在适配设备验证。

为什么选择这个方案

全局宽度变量不适合多窗口，因为最近一次回调来自哪个窗口并不确定。按 windowId 保存快照，并使用每个窗口内递增的修订号，能隔离状态和旧回调。转换是单位问题，断点是设计问题，两者不应混成一个设备判断。

检查项	实验中的做法	接入应用时要补的验证
输入边界	拒绝非法输入或区分失效请求	SDK 返回类型与错误码
状态变化	显式记录每次操作的输入和结果	页面切换、窗口销毁与后台恢复
失败路径	断言旧状态不被错误结果覆盖	弱网、权限拒绝与设备能力缺失
成功路径	检查最终状态，而非只检查无异常	目标设备界面与真实资源行为

封装与复用

把上面的纯逻辑保留为独立模块，界面层只提交输入和消费结果。系统事件适配层负责取得当前窗口、设备或入口的实际数据，不要把测试常量直接搬到正式应用。这样单元测试仍可在没有设备时运行，SDK 接入问题也能和算法问题分开排查。

复用之前先检查实例的作用域：窗口、播放器或请求协调器是否属于同一个会话。复用函数不等于共享所有状态。对于异步回调，需要同时考虑结果失效与底层任务取消；对于同步计算，需要确认单位、取样范围和输入上限。

边界与后续检查

示例 density 是测试输入，实际接入优先使用窗口上下文的 px/vp 转换方法。物理窗口宽度、可绘制区域与避让区并非同一概念；内容布局还需扣除不可绘制和设计留白区域。

回归测试应保留两个案例，再增加空输入、重复入口和生命周期结束后的操作。日志记录输入身份、状态修订与失败原因，不记录敏感内容。升级 SDK 后先检查官方接口签名、支持设备与版本说明，再运行同一组实验和设备回归，避免把旧版本假设带入新环境。