VoiceOver模式下pickerView:didSelectRow:inComponent被调用两次求助

这确实是VoiceOver交互场景里的一个常见小坑！我之前做无障碍适配时也碰到过一模一样的问题，给你几个实用的思路和解决办法：

原因解析 #

VoiceOver对UIPickerView的交互逻辑和普通触摸不一样：

• 普通模式下，用户点击/滑动选择行时，只会触发一次pickerView:didSelectRow:inComponent
• 但VoiceOver模式中，用户先通过手势聚焦到目标行（此时picker会触发一次回调），再通过双击完成确认选择（又会触发一次回调），所以就出现了两次调用的情况。

解决办法 #

方法一：记录上次选中状态，过滤重复调用 #

这是最直接的方案，在回调里判断如果是VoiceOver激活状态，且当前选中的行和组件和上次一致，就跳过重复执行：

// 定义变量记录上次选中的行和组件
private var lastSelectedRow: Int = -1
private var lastSelectedComponent: Int = -1

func pickerView(_ pickerView: UIPickerView, didSelectRow row: Int, inComponent component: Int) {
    // 处理VoiceOver下的重复回调
    if UIAccessibility.isVoiceOverRunning {
        guard row != lastSelectedRow || component != lastSelectedComponent else {
            return
        }
        lastSelectedRow = row
        lastSelectedComponent = component
    }
    
    // 在这里写你的业务逻辑代码
    print("选中了第\(component)组的第\(row)行")
}

方法二：通过Accessibility动作区分聚焦和确认 #

如果你需要更精准地区分“聚焦”和“确认”这两个动作，可以监听无障碍相关的通知或者实现UIAccessibility代理方法：

• 监听UIAccessibilityElementFocusedNotification来捕捉聚焦事件，标记当前是聚焦状态
• 在pickerView:didSelectRow:inComponent中，结合聚焦状态判断是否是用户的确认动作，再执行业务逻辑

不过方法一已经能解决大部分场景，实现起来更简单。

补充说明 #

这个现象并非bug，而是VoiceOver为了让视障用户清晰感知选择过程的设计逻辑。苹果原生的一些picker控件内部做了处理，所以不会暴露这个问题，但自定义实现的picker就需要我们自己适配啦。

内容的提问来源于stack exchange，提问作者Jared