关于iOS UIKit中first responder相关属性与方法的疑问

你的猜测是对的，isFirstResponder、becomeFirstResponder、canBecomeFirstResponder这套API确实仅针对非触摸类的全局事件设计，和触摸事件的临时第一响应者判定逻辑完全独立，你遇到的疑问本质是苹果官方文档没有把两种「first responder」的适用场景明确区分开导致的。

1. 两种first responder的核心差异 #

• 触摸事件临时第一响应者：就是你提到的每次触摸事件触发时，UIKit通过hitTest:withEvent:遍历视图层级找到的命中视图，这个判定逻辑是完全动态的，仅和触摸位置、视图的userInteractionEnabled属性、可见性、frame相关，完全不校验canBecomeFirstResponder的返回值，也不需要提前调用becomeFirstResponder，这就是普通UIView即使canBecomeFirstResponder默认返回NO，也能正常处理触摸事件的核心原因。
• 全局持久第一响应者：针对没有明确位置绑定的非触摸事件设计，包括键盘输入、摇动手势、远程控制事件、UIMenuController编辑菜单响应、硬件键盘焦点导航、tvOS焦点切换等，这类事件无法通过hitTest找到接收对象，必须有一个全局的唯一响应者来接收，你提到的这套API就是用来管理这个身份的。

2. 相关API的具体作用 #

• canBecomeFirstResponder：标记当前响应者是否有资格申请成为全局持久第一响应者，普通UIView默认返回NO，因为普通视图不需要接收上述非触摸事件；UITextField、UITextView等需要接收输入的控件会默认重写返回YES，自定义视图如果要支持编辑菜单、键盘输入等能力，也需要重写该方法返回YES。
• becomeFirstResponder：主动申请成为全局持久第一响应者，申请成功后，后续所有非触摸全局事件都会优先发给该对象。比如点击输入框时，系统内部会自动调用该方法让输入框成为第一响应者，之后弹出键盘，所有键盘输入都会直接发给这个输入框。
• isFirstResponder：查询当前对象是否为全局持久第一响应者。
• resignFirstResponder：主动放弃全局持久第一响应者身份，比如输入完成后收起键盘就可以调用该方法。

3. 逻辑验证 #

你可以做一个简单的测试验证上述逻辑：自定义一个普通UIView，不重写任何方法，添加点击手势，点击时打印isFirstResponder的返回值，你会发现即使它能正常响应点击手势，返回值永远是NO。如果你要让这个视图长按后弹出编辑菜单，就必须重写canBecomeFirstResponder返回YES，长按触发时调用becomeFirstResponder，之后再打印isFirstResponder就会返回YES，编辑菜单也能正常显示。

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