HarmonyOS 7.0 / API 26 DevEco 预览矩阵：手机、平板和折叠屏为什么要一起跑

这篇只讲一个点：DevEco 多设备预览矩阵。版本边界先说清楚：下面的写法面向 HarmonyOS 7.0 / API 26。老版本工程不要直接照搬，先确认 SDK、DevEco Studio、设备系统版本和模拟器镜像是否一致。

先说它解决什么

单设备预览很容易漏掉布局断点问题。7.0/API26 的文章和项目更应该把手机、平板、折叠屏、鸿蒙电脑按矩阵验证。

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

容易复现的两个场景

场景一：手机和平板断点切换

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

场景二：折叠屏半折和鸿蒙电脑窗口缩放

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

最小 Demo

type DeviceKind = 'phone' | 'tablet' | 'foldable' | 'pc'

type PreviewCase = {
  name: string
  device: DeviceKind
  width: number
  height: number
  foldState?: 'flat' | 'half'
  expectColumns: number
}

type PreviewResult = {
  name: string
  pass: boolean
  reason: string
}

class PreviewMatrixRunner {
  private cases: PreviewCase[] = [
    { name: '手机竖屏', device: 'phone', width: 390, height: 844, expectColumns: 1 },
    { name: '平板横屏', device: 'tablet', width: 1280, height: 800, expectColumns: 2 },
    { name: '折叠屏半折', device: 'foldable', width: 900, height: 720, foldState: 'half', expectColumns: 2 },
    { name: '鸿蒙电脑窗口', device: 'pc', width: 1440, height: 900, expectColumns: 3 }
  ]

  run(): PreviewResult[] {
    return this.cases.map((item) => {
      const columns = this.resolveColumns(item)
      const pass = columns === item.expectColumns
      return {
        name: item.name,
        pass,
        reason: pass ? 'layout matched' : 'columns=' + columns + ', expected=' + item.expectColumns
      }
    })
  }

  private resolveColumns(item: PreviewCase): number {
    if (item.device === 'pc' && item.width >= 1200) {
      return 3
    }
    if (item.device === 'tablet' || item.device === 'foldable') {
      return item.width >= 840 ? 2 : 1
    }
    return 1
  }
}

const result = new PreviewMatrixRunner().run()
console.info(JSON.stringify(result))

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

我会怎么选方案

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

验证清单

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

最后总结

DevEco 预览矩阵的价值是把多设备适配提前暴露出来。不要只看手机预览，应该按设备形态写出可复核的断点结果。

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

这个 Demo 应该怎么跑

第一步先把四个设备形态列出来：手机、平板、折叠屏、鸿蒙电脑。第二步给每个形态写期望列数，不要靠肉眼看页面差不多。第三步把结果打出来，哪一个设备不符合预期，就先查断点规则，不要直接改 UI。

这里的重点是把预览变成矩阵，而不是打开一次预览窗口。尤其是 HarmonyOS 7.0 / API 26 相关内容，如果只用手机尺寸验证，很容易漏掉折叠屏半折、平板横屏、电脑窗口缩放这些问题。

上线前检查

• 手机竖屏至少检查 360 到 430 宽度。
• 平板要检查横屏和分屏。
• 折叠屏要检查展开、折叠和半折。
• 鸿蒙电脑要检查窗口拖拽后的布局恢复。
• 每次结果都要有 pass 和 reason，失败时能直接定位到断点。