Gesture Navigation — 结构、类型与实现

什么是 Gesture Navigation

Gesture Navigation — 是用户通过触摸屏识别的一系列触摸、移动和按压与移动设备交互的方法。与传统按键不同，手势在屏幕上没有固定位置，而是根据运动模式识别：从边缘滑动、双指捏合、长按。

向手势导航的过渡 始于 iPhone X（2017年），苹果完全移除了 Home 按键，用从底部边缘滑动替代。谷歌在 Android 10（2020年）跟随这一趋势，为用户提供了选择：三键导航、两键导航和全手势导航。根据 StatCounter（2025年）的数据，超过 75% 的 Android 设备和 95% 的 iOS 设备使用手势导航。

从架构上讲，手势识别包括三个阶段：Capture（捕获触摸事件）、Recognition（确定运动模式）和 Action（执行指定的操作）。在系统层面，Android 和 iOS 内置了基本导航手势的处理程序——向后滑动、返回主屏幕、打开应用切换器。开发者只需将自己的手势正确地集成到该系统中即可。

移动导航中的手势类型

所有触摸手势可以根据目的和执行方式分为三类。每种类型都有自己的处理规则和在界面中使用的建议。

导航手势

导航手势控制屏幕之间的切换：从左侧边缘滑动返回（iOS）、向上滑动打开应用切换器、从底部边缘滑动返回主屏幕。这些手势由系统在 Window 级别处理，不应与应用内部的用户手势冲突。

操作手势

操作手势改变屏幕上对象的位置、大小或方向。捏合（双指缩放）、旋转、拖拽、快速滑动——所有这些手势在 View 或 Composabale 级别处理，不影响系统导航。

上下文手势

上下文手势激活额外功能而无需切换到另一个屏幕。长按（用于上下文菜单）、双击（用于点赞或缩放）、边缘滑动（用于打开抽屉）。这些手势需要最谨慎的实现，因为它们可能与系统导航手势重叠。

Android 上的手势导航：GestureDetector 和 MotionEvent

Android SDK 提供多层手势处理系统，从低级的 MotionEvent 到高级的 GestureDetector 和 GestureOverlayView。正确选择级别取决于手势的复杂性和性能要求。

GestureDetector — 基础类

GestureDetector — 是一个高级类，将 MotionEvent 序列转换为具体手势：onDown、onShowPress、onSingleTapUp、onScroll、onLongPress、onFling。开发者重写 GestureDetector.SimpleOnGestureListener 所需的方即可获得已识别的事件。GestureDetector 推荐用于所有标准手势，缩放除外——为此有 ScaleGestureDetector。

val gestureDetector = GestureDetector(this, object : GestureDetector.SimpleOnGestureListener() {
    override fun onFling(
        e1: MotionEvent?, e2: MotionEvent,
        velocityX: Float, velocityY: Float
    ): Boolean {
        val deltaX = e2.x - (e1?.x ?: 0f)
        return if (Math.abs(deltaX) > Math.abs(e2.y - (e1?.y ?: 0f))) {
            if (deltaX > 0) onSwipeRight() else onSwipeLeft()
            true
        } else false
    }
})

view.setOnTouchListener { _, event -> gestureDetector.onTouchEvent(event) }

用于自定义目标的 TouchDelegate

TouchDelegate — 一种扩展 View 触摸区域的机制。当目标元素小于最小触摸尺寸 48dp 时使用。例如，屏幕角落的一个小 “关闭” 按钮获得一个 TouchDelegate，在不改变可见大小的情况下扩展其点击区域。谷歌推荐所有小于 48x48dp 的交互元素使用 TouchDelegate。

Jetpack Compose 中的手势

Compose 提供了用于手势处理的修饰符：clickable、draggable、swipeable、combinedClickable（用于双击和长按）。在内部，Compose 使用 PointerInputScope 进行低级处理，但对大多数开发者来说，高级修饰符已足够。对于自定义手势，使用带有 awaitPointerEvent 的 pointerInput。

iOS 上的手势导航：UIGestureRecognizer 和 SwiftUI

iOS SDK 使用 UIGestureRecognizer 架构——一个抽象基类，分析 UITouch 序列并确定是否与已知手势匹配。苹果建议尽可能使用标准识别器，仅对独特的手势创建自定义子类。

UIKit 中的 UIGestureRecognizer

UIKit 提供了一组现成的识别器：UITapGestureRecognizer、UISwipeGestureRecognizer、UIPanGestureRecognizer、UIPinchGestureRecognizer、UIRotationGestureRecognizer、UILongPressGestureRecognizer。每个识别器都有状态（possible、began、changed、ended、cancelled、failed）——开发者跟踪状态以在手势的不同阶段做出响应。

let swipeBack = UISwipeGestureRecognizer(
    target: self,
    action: #selector(handleSwipeBack)
)
swipeBack.direction = .right
view.addGestureRecognizer(swipeBack)

@objc func handleSwipeBack() {
    navigationController?.popViewController(animated: true)
}

SwiftUI 中的手势

SwiftUI 使用声明式手势修饰符，类似于 Compose：onTapGesture、onLongPressGesture、MagnificationGesture、RotationGesture、DragGesture。SwiftUI 通过 simultaneousGesture、sequencedGesture 和 exclusiveGesture 自动处理手势之间的冲突——这些修饰符确定同时激活时手势的优先级。

Image("photo")
    .gesture(
        MagnificationGesture()
            .onChanged { scale in
                self.currentScale = scale
            }
            .sequenced(before: DragGesture())
    )

InteractivePopGestureRecognizer

InteractivePopGestureRecognizer — 管理 UINavigationController 中向后滑动的系统识别器。默认情况下，它对除根屏幕外的所有屏幕有效。如果您的应用使用自定义 NavigationBar，interactivePopGestureRecognizer 可能停止工作——需要通过 navigationController.interactivePopGestureRecognizer?.delegate 进行程序化激活。

系统手势与用户手势的冲突

手势冲突——手势导航中最困难的问题之一。当用户手势（例如，从左侧边缘滑动打开抽屉）与系统手势（iOS 或 Android 上的向后滑动）重叠时，系统必须确定哪个手势具有优先级。正确处理此冲突对用户体验至关重要。

Android 上的解决方案：Insets 和 SystemGestureExclusionRects

Android 10+ 允许应用通过 WindowInsets 为自身手势保留屏幕区域。使用 ViewCompat.setSystemGestureExclusionRects 指示系统手势不应触发的区域。例如，对于左侧的抽屉，可以将屏幕左边缘（宽度至 200dp）从系统向后滑动中排除。谷歌设定了限制：每侧最多排除 200dp。

val exclusionRect = Rect(0, 0, 200, height)
ViewCompat.setSystemGestureExclusionRects(
    drawerView,
    listOf(SystemGestureExclusionRect(exclusionRect))
)

iOS 上的解决方案：UIGestureRecognizerDelegate

iOS 在 UIGestureRecognizerDelegate 中提供 gestureRecognizerShouldBegin 方法，允许自定义识别器决定是否开始识别。对于从左侧边缘的抽屉滑动，可以检查触摸位置：如果用户拖拽抽屉（距离大于阈值），自定义手势接管控制。如果手势未被识别，系统将控制权返回给 InteractivePopGestureRecognizer。

常见错误与最佳实践

Gesture Navigation 需要精心的设计，尤其是在具有系统手势导航的设备上。让我们看看常见错误及其解决建议。

错误：忽略屏幕边缘的冲突区域

最常见的错误——在系统手势区域（左边缘、右边缘、下边缘）放置交互元素或实现自定义滑动。用户尝试执行操作，但系统导航反而被触发。始终为系统手势留出空间，并通过 exclusion rects 处理冲突。

错误：Android 和 iOS 上不同的识别速度

手势参数（速度阈值、最小距离）在平台之间默认不同。如果您的应用是跨平台的，不要将参数从一个平台复制到另一个平台——在 Android 和 iOS 上分别测试每个手势。Flutter 和 React Native 会自动适配某些参数，但不是全部。

最佳实践：视觉反馈

每个手势都应有视觉反馈伴随：颜色变化、变换、动画。用户必须理解手势已被识别且操作正在执行。在 iOS 上，系统识别器自动提供触觉反馈，在 Android 上需要通过 HapticFeedbackConstants 添加。

最佳实践：手势的无障碍访问

并非所有用户都能执行手势——行动受限的人使用 VoiceOver 和 TalkBack 进行导航。每个手势都应有按钮替代方案。谷歌和苹果要求所有手势操作都由可访问的控制元素复制实现。