F1.12.2gesture-chrome conflict设计
系统手势区与固定元素冲突
别名: 手势与底栏 · home indicator conflict · 边缘固定冲突
概念解释
底栏五个标签贴着 Home 指示条。用户想滑去隔壁标签，系统当成回主屏；想回主屏，又点到了中间那个标签。左缘钉着一颗固定的筛选按钮，系统返回手势和这颗按钮抢同一条边缘。手势与壳的冲突（gesture-chrome conflict）是应用自己钉死的控件，坐进了系统已经征用的手势带，两次输入互相误认。
它不是「边缘作为廉价目标被征用」那笔账，是已经钉在那里的壳和系统手势抢同一条动作。
机制
系统手势带是一条沿边的识别区，优先级高于应用。固定壳又被设计成「永远可点」，于是同一条物理带上叠了两套接收器。短滑、斜滑、从指示条上滑，判别边界模糊，于是出现双向误认：应用吃掉离开的手势，系统吃掉切标签的手势。固定让冲突变成常驻——滚动的内容只在经过边缘时撞一次，钉死的底栏每次滑都在撞。
冲突还有方向：底栏怕上滑，侧栏怕回滑，顶栏怕下拉通知。把固定元素的可点热区画到指示条或圆角里，等于主动走进对应方向的系统手势。
边界
有实体键或屏幕内明确返回键的系统上，边缘手势弱，冲突轻。桌面没有这套边缘手势，固定工具栏不跟系统抢。全屏沉浸态下系统手势被暂时让出，冲突缓解，但退出全屏后会回来。用户关闭手势导航改回三键时，底栏冲突消失，侧缘冲突可能还在（三键没有左缘返回，但有的 OEM 仍保留侧滑）。
怎么落地
- 固定底栏的可点热区停在指示条之上，不要把标签命中区画进指示条。切标签用点按，不要用和回主屏同方向的上滑。
- 不要在屏幕左缘钉死一个常驻按钮或抽屉把手；改用屏幕内的筛选入口。
- 顶栏下拉刷新的起点离开状态栏和下拉通知的识别带。
- 验证：在手势导航的真机上，对固定底栏做切标签、回主屏、进多任务各十次，对左缘做返回十次。任何一次被另一套接收器吃掉，这颗固定元素就还在手势带里。