HarmonyOS 7.0 / API 26 折叠屏悬停输入保护：半折状态下输入法为什么会遮住表单

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

先说它解决什么

折叠屏半折状态下，输入法、底部按钮和表单焦点很容易互相遮挡。只按普通手机高度处理，用户一输入就看不到当前字段。

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

容易复现的两个场景

场景一：折叠屏悬停输入保护 的正常路径

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

场景二：折叠屏悬停输入保护 的异常回退路径

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

最小 Demo

type CheckMode = 'full' | 'fallback' | 'blocked'

type FoldInputInput = {
  apiLevel: number
  deviceType: 'phone' | 'tablet' | 'foldable' | 'pc'
  scene: string
  stable: boolean
  value: number
}

type FoldInputResult = {
  mode: CheckMode
  pass: boolean
  reason: string
}

class FoldInputGuard {
  check(input: FoldInputInput): FoldInputResult {
    if (input.apiLevel < 26) {
      return { mode: 'fallback', pass: false, reason: 'api level below 26' }
    }
    if (!input.stable) {
      return { mode: 'blocked', pass: false, reason: 'runtime state is changing' }
    }
    if (input.value <= 0) {
      return { mode: 'blocked', pass: false, reason: 'invalid measure value' }
    }
    return { mode: 'full', pass: true, reason: input.deviceType + ':' + input.scene + ' ready' }
  }
}

const guard = new FoldInputGuard()
console.info(JSON.stringify([
  guard.check({ apiLevel: 26, deviceType: 'phone', scene: 'normal', stable: true, value: 1 }),
  guard.check({ apiLevel: 26, deviceType: 'foldable', scene: 'switching', stable: false, value: 1 }),
  guard.check({ apiLevel: 25, deviceType: 'pc', scene: 'legacy', stable: true, value: 1 })
]))

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

我会怎么选方案

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

验证清单

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

最后总结

折叠屏悬停输入保护 要把 HarmonyOS 7.0 / API 26 的版本边界、设备状态和失败回退放在一起判断。代码要能输出 reason，方便复现和排查。

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

这个 Demo 应该怎么跑

先跑 API 26 的正常路径，再跑窗口或设备状态变化时的回退路径，最后跑 API 低于 26 的兼容路径。三组结果都要输出 mode、pass、reason。

这里不要只看页面有没有显示出来。真正要验证的是：版本不满足时有没有回退，设备状态变化时有没有阻断，输入数据异常时有没有明确 reason。只有这些信息都能打出来，线上问题才不会变成猜。

验证矩阵

写到项目里怎么维护

这类判断不要散在页面按钮里。建议放在 Guard 或 Adapter 里，页面只拿结果展示。后续 HarmonyOS 文档更新、设备能力变更、审核要求调整时，只改这一层，风险最小。