了解第一响应者的系统逻辑

Posted 2023-02-24

【中文标题】了解第一响应者的系统逻辑

【英文标题】：Understanding system logic for first responder

【发布时间】：2011-09-07 15:02:52

【问题描述】：

我对几个急救人员点感到困惑：

如果我调用- becomeFirstResponder，系统会先调用– canBecomeFirstResponder吗？为什么？ 为什么- becomeFirstResponder 和– canBecomeFirstResponder 同时存在？在什么情况下它们可以返回不同的值？ 应用程序每次都必须有第一响应者吗？如果是这样，当我在某个对象上调用 – resignFirstResponder 时会发生什么？ UIApplication 是立即成为第一响应者，还是在响应者链中的某个点上抛出这个“令牌”？当我想摆脱那个朝圣者令牌时，我可以在 UIApplication 对象上调用 - becomeFirstResponder 吗？ ...

请有人解释一下，系统如何管理它的第一响应者。当某个对象成为第一响应者时，幕后发生了什么，当第一响应者辞职时会发生什么。系统调用什么...谢谢！

【参考方案1】：

becomeFirstResponder 的默认实现确实调用了canBecomeFirstResponder。这是因为从 canBecomeFirstResponder 返回 NO 的响应者不应成为第一响应者。 如果成功，becomeFirstResponder 将使接收者实际上成为第一响应者。 canBecomeFirstResponder 只是检查接收者是否愿意成为第一响应者，而不实际更改任何内容。如果当前的第一响应者拒绝辞职，becomeFirstResponder 可能会失败。在其他情况下，becomeFirstResponder 也可能失败。 您的代码中不必有任何具有第一响应者状态的内容。通过私有 UIResponder 方法firstResponder 判断，在这种情况下系统没有分配任何特定的默认值。

基本上，当某物想成为第一响应者时，当前的第一响应者（如果有的话）被要求辞职，然后新对象成为第一响应者。这可能会导致系统显示屏幕键盘或采取一些其他操作。当第一响应者辞职时，这同样可能导致系统隐藏屏幕键盘或采取其他一些措施。

当一个非触摸事件进来时，它首先被传递到 UIWindow。 UIWindow 将其传递给第一响应者。该文档似乎没有指定 UIWindow 是否尝试自己处理事件（如果它自己不处理它，则照常将其传递给 UIApplication ）或者如果没有第一响应者则忽略该事件。

详情请见the documentation。