HarmonyOS 7.0 / API 26 智慧手势路由：点击、滑动和长按如何避免互相抢动作

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

先说它解决什么

智慧手势不是把几个事件绑到页面上就结束。点击、滑动、长按如果没有统一路由，很容易互相抢动作，用户看到的就是误触和状态跳变。

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

容易复现的两个场景

场景一：普通点击和滑动切换

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

场景二：低置信度和连续操作被拦截

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

最小 Demo

type GestureType = 'tap' | 'swipe' | 'longPress'

type GestureEvent = {
  type: GestureType
  confidence: number
  distance: number
  timestamp: number
}

type GestureDecision = {
  accepted: boolean
  action: string
  reason: string
}

class SmartGestureRouter {
  private lastActionAt = 0

  route(event: GestureEvent): GestureDecision {
    if (event.confidence < 0.72) {
      return { accepted: false, action: 'ignore', reason: 'confidence is too low' }
    }
    if (event.timestamp - this.lastActionAt < 280) {
      return { accepted: false, action: 'ignore', reason: 'cooldown window' }
    }
    this.lastActionAt = event.timestamp
    if (event.type === 'swipe' && event.distance > 24) {
      return { accepted: true, action: 'switch-tab', reason: 'stable swipe' }
    }
    if (event.type === 'longPress') {
      return { accepted: true, action: 'open-menu', reason: 'stable long press' }
    }
    return { accepted: true, action: 'select', reason: 'normal tap' }
  }
}

const router = new SmartGestureRouter()
console.info(JSON.stringify([
  router.route({ type: 'tap', confidence: 0.91, distance: 2, timestamp: 1000 }),
  router.route({ type: 'tap', confidence: 0.88, distance: 2, timestamp: 1100 }),
  router.route({ type: 'swipe', confidence: 0.86, distance: 42, timestamp: 1500 })
]))

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

我会怎么选方案

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

验证清单

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

最后总结

智慧手势路由要把置信度、距离和冷却窗口放到一起判断。统一决策后，页面交互会比零散监听更稳定。

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

这个 Demo 应该怎么跑

准备三种手势：点击、滑动、长按。再准备两个干扰条件：置信度不足、两次动作间隔太短。只要一个动作被拒绝，就必须给出 reason，而不是静默无响应。

智慧手势类能力最怕误触。误触不是 UI 小问题，会直接影响用户对新能力的信任。处理方式是把 confidence、distance、timestamp 放在同一个路由器里判断，不要让每个按钮自己猜。

上线前检查

• 点击和滑动是否会互相抢动作。
• 低置信度动作是否被忽略。
• 快速连续操作是否被冷却窗口拦住。
• 长按菜单是否会误触发点击。
• 日志里是否能看出 accepted、action、reason。