UIWindow endDisablingInterfaceAutorotationAnimated 错误仅在 iOS9 中从 collectionView 中以交互方式关闭键盘时出现在控制台中

Posted 2023-02-15

【中文标题】UIWindow endDisablingInterfaceAutorotationAnimated 错误仅在 iOS9 中从 collectionView 中以交互方式关闭键盘时出现在控制台中

【英文标题】：UIWindow endDisablingInterfaceAutorotationAnimated error appears in console when keyboard is dismissed interactively from collectionView in iOS9 only

【发布时间】：2016-01-09 08:24:50

【问题描述】：

我只在 ios 9 中遇到了这个奇怪的错误：

[UIWindow endDisablingInterfaceAutorotationAnimated:] called on UITextEffectsWindow: ...without matching
-beginDisablingInterfaceAutorotation. Ignoring.

每当我通过从我的 collectionView 中向下拖动以交互方式关闭键盘时。通过点击手势或按 Enter 键关闭键盘，我不会收到错误消息。这是非常令人沮丧的。即使我没有观察到任何键盘通知，我仍然会在此交互式键盘关闭时收到此错误。我想知道是否有其他人遇到过这个错误并找到了解决方案。我有一个inputAccessoryView，由安装在键盘上的 textView 组成。

【问题讨论】：

我也看到了这个。可能仅在 iOS 9 上值得一提。在 iOS 8 上运行相同的应用程序不会在控制台中打印任何内容。

感谢您的评论。你说得对，它只发生在 iOS9 中。我已经修改了问题以反映这一点。

这显然是系统错误

在 iOS 10 上仍然可以使用。

我在 iOS 11 上在 UISearchResultsController 的 tableView 上滑动时遇到了这个问题...在发生错误后点击单元格后应用程序崩溃

【参考方案1】：

我在 iOS9 上遇到了同样的问题，但使用的是 tableView。我与 self.tableView.keyboardDismissMode = .Interactive 一起实现了这个，它对我有用。

// Dismiss keyboard when scrolling
func scrollViewWillBeginDragging(scrollView: UIScrollView) 
    textView.resignFirstResponder()

【讨论】：

当我的字段中有inputAccessoryView 时，我遇到了同样的问题。他们隐藏在两个阶段：键盘和之后inputAccessoryView。这对我有帮助。他们现在同时躲起来了。

这也适用于我的 collectionView。非常感谢。

自从接受我注意到使用此建议后，有时 inputAccessoryView 实际消失了，因此我将不得不继续寻找解决方案。

@izilotti 它对我有用，但我已将 textView.resignFirstResponder() 更改为 view.endEditing(true)，因为我有 5 个文本字段。希望它可以帮助别人

我注意到使用这个建议 Dismiss Interactively 变成了 Dismiss on Drag （无论如何都有相同的错误问题），这将阻止用户改变主意并取消关闭操作拖动时键盘（并丢失选择）。

【参考方案2】：

检查事项

似乎其他几个 SO 用户在各种条件下都有过类似的经历。看看这个thread。由于可能会发生很多导致此问题的事情，您可能需要查看提供的线程以查看是否可以找到匹配的用例。目前尚不清楚您是如何解除键盘的，但您可能希望从方法或手势识别器中调用类似的内容（而不是直接从特定对象解除）：

UIApplication.sharedApplication().sendAction("resignFirstResponder", to: nil, from: nil, forEvent: nil)

从提供的线程来看，在大多数情况下，问题的性质是在演示或关闭视图期间重复调用。我还看到了连接故事板 segue 的问题（或者在某些情况下它已被删除但 xml 仍在故事板代码视图中）和基于代码的 segue (performSegueWithIdentifier ...) 用于相同的动画（其中导致两个显示/关闭呼叫）。

我会查看日志以查看在错误之前记录了哪些调用，然后在日志视图中进行查找以查看是否存在冗余调用。同样，情节提要上的行为/动画/布局和代码中的调用也可能存在冗余。

更新

来自 OP 的 cmets 提醒我，在某些情况下，尤其是在演示/解雇期间涉及调用的情况下，我已经看到成功让开发人员函数工作的唯一方法是将其包装到 dispatch_async 调用中的实例。如果在同一帧中引入开发人员代码，则某些关键系统调用似乎无法正常工作。

一个具体的例子是willMoveToWindow 内的这个调用。在这种情况下，我对视图有一个 weakSelf 引用，并在调用我的代码之前简单地查看 newWindow 的 nil 值（表示视图正在被关闭）。

因此，在本例中，如果删除了 dispatch 调用，那么开发人员代码将导致整个应用程序崩溃。我猜系统转换调用（与从窗口转换到/从窗口转换相关）可能与开发人员当时的请求发生冲突。

 dispatch_async(dispatch_get_main_queue(),  () -> Void in

     //the saved flag is true only when user hits the done button
     if !(weakSelf!.saved) 
         weakSelf?.completeNotes(nil)
     

 )

【讨论】：

嗨。谢谢你的帖子。我相信重复调用是因为 inputAccessoryView。似乎在安装了 inputAccessoryView 的情况下，每次显示或隐藏键盘时，keyboardDidChange 通知都会发送两次。好像首先关闭键盘，然后将 inputAccessoryView 带入视野。我认为这会导致这个问题和其他一些问题，但如果我想继续使用 inputAccessoryView，我不确定如何解决它。

我认为该错误与使用交互式解雇有关，但在我的情况下，我将此错误追溯到手动调用 resignFirstResponder 到文本视图。将resignFirstResponder 操作发送到响应程序树并不能防止错误，但至少我的输入附件视图已从屏幕上正确删除。我想知道这是否与我的输入附件视图保持对文本视图的（强）引用这一事实有关......将调查并报告任何新信息。

这应该是选择的答案。特别是关于系统事件期间需要在异步块（或现在的延迟块）中的开发人员操作的更新非常有意义并解决了我的问题。

【参考方案3】：

我遇到了这个问题，它打乱了我的看法。我就是这样解决的。

我在textFieldShouldBeginEditing 上显示了viewController。在viewController 中，textField 在viewDidLoad 中设置为becomeFirstResponder。

我的解决方案是将becomeFirstResponder 移动到viewDidAppear。

【讨论】：

即使我在viewDidAppear 中进行了becomeFirstResponder 调用，我也收到了错误消息。