一次滑动，到底该点谁？这就是智慧手势要回答的问题。

做复杂列表页面的时候，最开始的思路很简单：每个组件自己设置 Gesture，点了就响应。简单页面没问题，按钮就是按钮，点哪就哪。

直到做了一个很复杂的页面：列表项里有卡片、有按钮、有滑动操作、有折叠展开。用户一划，有时候点到卡片了，有时候点到按钮了，有时候滑不出去。手势响应完全不可控。

这时候才意识到：手势不是"哪个组件注册了就谁响应"，系统要做判断——这次手势到底是想操作谁。

一、普通手势和智慧手势的区别

先把概念理清楚：

类型	工作方式
普通 Gesture	组件自己监听，点到谁谁响应
智慧手势	系统识别意图，判断目标，再决定响应

普通手势的问题是：页面复杂了，组件多了，手势很容易撞车。这个组件注册了滑动，那个组件也注册了滑动，到底谁响应？

智慧手势的思路是：系统先判断用户的操作意图是什么，再找对应的目标组件，最后才执行动作。

二、一次手势到底发生了什么

把手势处理的完整链路理一遍：

用户手势输入
  ↓
系统识别操作意图（点击/滑动/翻页）
  ↓
识别目标节点（点的是哪个组件）
  ↓
判断响应优先级（多个组件都想响应怎么办）
  ↓
执行最终动作

可以把整个过程想成"点外卖找地址"：

• 手势输入是用户下了单；
• 操作意图是用户想吃什么；
• 目标节点是送到哪个门店；
• 优先级是门店太远，换个近的；
• 最后才是配送上门（执行动作）。

三、目标节点识别为什么重要

很多人做手势的时候，只判断动作类型：是滑动还是点击。但不判断目标节点。

错误做法	问题
只要是滑动就响应	点到空白区域也触发了
只要是点击就响应	点到禁用按钮也触发了
不判断组件是否可用	点了灰色按钮没反应但浪费了手势

智慧手势多了一层：先判断目标节点是谁，这个节点能不能响应，再决定要不要执行。

四、响应优先级怎么判断

多个组件都想响应同一个手势的时候，谁优先？

优先级	组件类型
高	用户明确操作的按钮、可点击组件
中	列表项、卡片
低	容器、背景

系统会根据组件的类型和位置，判断这次手势最可能是想操作谁。你也可以自己配置优先级，让特定组件优先响应。

最容易踩的坑就是：所有组件都设置高优先级响应。那系统就没法判断了，最后响应的是哪个全靠运气。

五、什么时候要接管系统默认动作

有些场景，系统默认的手势响应不符合你的业务需求。这时候你可以自己接管。

比如：

• 系统默认滑动是翻页，但你的业务里滑动要触发其他操作；
• 系统默认点击是选中，但你的业务里点击要弹窗；
• 某个特殊区域的手势，系统识别错了目标。

接管的时候要注意：你接管了，就别再执行系统默认的动作了。不然用户点一次，两个动作都执行了，体验很差。

六、监听器为什么要记得清理

注册了智慧手势监听器之后，页面销毁的时候一定要记得清理。

很多人忘了这一步。结果就是：页面都退了，监听器还在后台跑，内存泄漏。更严重的是，其他页面的手势也被这个监听器影响了。

七、几个容易踩的坑

第一个坑：所有组件都设置高优先级响应。系统没法判断，响应全靠运气。

第二个坑：监听器注册后未清理。页面都退了，监听器还在跑。

第三个坑：把智慧手势和普通 Gesture 混为一谈。两套机制一起用，冲突了。

第四个坑：只判断动作不判断目标节点。点到哪都响应，精度很差。

第五个坑：自定义接管后又执行默认动作。一次操作触发两个动作，体验混乱。

这次做复杂页面手势最大的体会是：手势不是"谁注册了就谁响应"，系统要先想清楚"用户到底想操作谁"。把目标识别和优先级想清楚了，手势才可控。