HarmonyOS 7.0 / API 26 鸿蒙电脑窗口尺寸记忆：多窗口恢复后布局如何回到上次状态

这篇只讲一个点：鸿蒙电脑窗口尺寸记忆。版本边界先说清楚：下面的写法面向 HarmonyOS 7.0 / API 26。老版本工程不要直接照搬，先确认 SDK、DevEco Studio、设备系统版本和模拟器镜像是否一致。

先说它解决什么

鸿蒙电脑上用户会拖窗口、开多实例、接外屏。窗口恢复后如果布局重新按默认值走，用户刚才的工作状态会丢。

如果还按 5.0 或 6.0 的旧习惯处理，通常会遇到三个问题：第一，代码能编译，但设备上行为和预期不一致；第二，页面状态看起来正常，切换场景后就暴露边界；第三，性能或体验问题不是马上炸，而是用户连续操作后才出现。

容易复现的两个场景

场景一：鸿蒙电脑窗口尺寸记忆 的正常路径

复现方式很简单：先把页面打开到目标状态，再连续做两次切换或刷新。这个时候要观察的不是按钮有没有响应，而是状态有没有丢、动画有没有抖、资源有没有重复申请。

场景二：鸿蒙电脑窗口尺寸记忆 的异常回退路径

第二个场景更接近线上问题：用户不是按开发者预设路径走，而是会来回切页面、锁屏、恢复、换方向、切到后台再回来。这个时候如果只看单次点击，问题会被遮住。

最小 Demo

@Entry
@Component
struct DemoPage {
  @State private message: string = 'HarmonyOS 7.0';

  build() {
    Column({ space: 12 }) {
      Text(this.message).fontSize(22).fontWeight(FontWeight.Bold)
      Button('刷新状态').onClick(() => {
        this.message = '已完成一次可复现验证'
      })
    }.padding(20).width('100%')
  }
}

这个 Demo 的重点不是炫技，而是把问题压到最小：一个入口、一个状态变化、一个验证点。先把这个跑通，再往复杂页面里搬，排查成本会低很多。

我会怎么选方案

我的选择是第三种。只要这个能力会被多个页面用到，就不要把判断逻辑塞在页面里。页面只负责展示，能力边界、异常兜底、版本判断放到独立函数或组件里。这样后面改 SDK、换设备、补兼容逻辑，影响面会小很多。

验证清单

• DevEco Studio 使用支持 HarmonyOS 7.0 / API 26 的版本。
• 真机或模拟器系统版本和文章里的 API 版本一致。
• 至少跑通上面两个场景，不只看首屏。
• 如果涉及多设备、窗口、后台恢复，要补一次切换测试。
• 如果要发到线上，日志里要能看出失败原因，而不是只看到一个空状态。

最后总结

鸿蒙电脑窗口尺寸记忆 要先把版本边界、失败路径和验证方式讲清楚。写代码时把判断收口成可复用模块，页面只接收明确结果，这样更容易排查和维护。

这类特性真正有价值的地方，不是知道一个新名字，而是知道它在什么场景该用、什么时候不该用、怎么复现问题、怎么把修复沉淀成可复用代码。后面再接复杂页面时，先把这个小 Demo 跑通，基本能避开一半低级返工。

再补一层容易漏掉的边界

这个点还要特别注意三类边界。第一类是版本边界：同一段代码在 API 26 上能跑，不代表低版本、旧模拟器或旧工程配置里也能稳定。第二类是设备边界：手机、平板、折叠屏、鸿蒙电脑的窗口形态不同，状态恢复和布局刷新顺序也不同。第三类是用户操作边界：用户会连续点击、切后台、换设备、拒绝权限、断网后再回来。

我自己的处理习惯是先把这三类边界写成检查项，再写页面逻辑。这样文章里的 Demo 不是为了凑代码，而是为了证明这个知识点在真实开发里经得起复现。真正上线前，还应该把成功路径、失败路径和恢复路径都打到日志里。只要日志能看出版本、设备、入口、模式和失败原因，后面定位问题就不会只靠猜。

上架和团队协作时怎么用

如果这个能力会影响权限、设备能力、性能、窗口适配或审核材料，不建议只在个人页面里临时处理。更稳的方式是把判断封装成一个小 adapter，再配一份检查清单。代码评审时看 adapter 是否覆盖边界，测试时按清单跑场景，写文档时把版本范围写清楚。这样即使后续 HarmonyOS 文档继续更新，也能知道应该改哪一层，而不是全项目搜索同一个判断条件。