iPhone 6 Plus UISplitViewController 因递归 _canBecomeDeepestUnambiguousResponder 而崩溃
iPhone 6 Plus UISplitViewController crash with recursive _canBecomeDeepestUnambiguousResponder
我有一个现有的 iPhone 应用程序，我正在向其添加 UISplitViewController。 iPad 部分就像一个魅力，但我肯定会在 iPhone 6(S) Plus 上崩溃。
设置 - Master 是 UITabBarController。初始细节是带有占位符徽标视图的视图。一旦一个对象被 selected，细节被替换为 UITabBarController.
每当我 select 一个项目并在 iPhone 6 Plus 中打开细节并将其从纵向（仅细节可见）旋转到横向（主图可见）时，它会崩溃.使用占位符详细视图旋转时不会发生这种情况。
在崩溃之前，它确实调用了委托方法 primaryViewControllerForExpandingSplitViewController 和 splitViewController(splitViewController: UISplitViewController, separateSecondaryViewControllerFromPrimaryViewController。但是，在 iPad.
上一切正常
我已经进行了大量搜索，但只在 Twitter 上看到几条提及此类崩溃的信息。设置或不设置 displayModeButtonItem 之类的事情没有帮助。
我在一个新项目中重新创建了这个崩溃 - 它可以在这里下载：
https://github.com/sschale/SplitViewCrash/
崩溃日志：
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff53609ff8
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x7fff53609ff8:
MALLOC_TINY 00007f8405000000-00007f8405300000 [ 3072K] rw-/rwx SM=PRV
--> STACK GUARD 00007fff4fe0a000-00007fff5360a000 [ 56.0M] ---/rwx SM=NUL stack guard for thread 0
Stack 00007fff5360a000-00007fff53dff000 [ 8148K] rw-/rwx SM=COW thread 0
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 liboainject.dylib 0x000000010e5e59b2
0 liboainject.dylib 0x000000010e5e59b2
_writeEventToSharedMemory + 27
1 liboainject.dylib 0x000000010e5e55d7 _OARecordFinalEvent + 1161
2 liboainject.dylib 0x000000010e5e79f1 ___swapMethods_block_invoke_6 + 338
3 libobjc.A.dylib 0x000000010f4f9b6b weak_read_no_lock + 89
4 libobjc.A.dylib 0x000000010f4fa4c6 objc_loadWeakRetained + 104
5 com.apple.UIKit 0x00000001110510b6 -[UIViewController presentedViewController] + 58
6 com.apple.UIKit 0x0000000111033fc6 -[UIViewController _canBecomeDeepestUnambiguousResponder] + 31
7 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
8 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
9 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
10 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
//(500 more of those)
....
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x0000000116e49ee2 kevent64 + 10
1 libdispatch.dylib 0x0000000116ac57f0 _dispatch_mgr_invoke + 260
2 libdispatch.dylib 0x0000000116ac558a _dispatch_mgr_thread + 54
Thread 2:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
Thread 3:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
Thread 4:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
Thread 5:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
这也会在 iPad 上崩溃。使用多任务将应用程序调整为紧凑宽度（例如 1/3 屏幕），按“启动详细信息”按钮，然后将其调整为常规宽度。
当您处于紧凑宽度时，拆分视图控制器为 "collapsed"。这意味着它不再同时显示单独的主视图控制器和辅助视图控制器——相反，它 "collapses" 它们进入单个视图控制器层次结构。当它处于那种环境中时，它通常需要您的帮助才能做出明智的行为。当您的主视图控制器和辅助视图控制器都是 UINavigationController 时，默认行为运行良好，但在其他情况下则不然。
（在您的应用程序中，您的主要是 UITabBarController，在您 "Launch Detail" 一次之后，次要也是 UITabBarController。您可能需要重新考虑该设计，因为它使事情变得更加困难。继续阅读.)
您应用的 "Launch Detail" 按钮执行 "Show Detail" 转场，这有效地调用了 UISplitViewController 上的此方法：
public func showDetailViewController(vc: UIViewController, sender: AnyObject?)
注意 header 中的注释：
// In a horizontally-compact environment the master view controller
// or detail view controller is sent the showViewController:sender:
// message. If neither one of them provide an implementation for this
// method then it will fall back to a full screen presentation.
"master view controller or detail view controller"表示当前显示的视图控制器，在您的例子中是 UITabBarController。但是 UITabBarController 没有为 showViewController() 实现任何东西，因为它没有足够的信息——它将在哪里显示视图控制器？它会添加一个新标签，还是替换旧标签，或者什么？
因此，您得到了后备 full-screen 演示文稿。我怀疑你真的想要那种用户体验。
稍后，当大小变回常规并且拆分视图控制器展开时，它会被演示混淆并最终崩溃。 （明白我说的默认值不是很好的意思了吗？）
解决此问题的一种方法是实施委托方法来处理 showDetail。当宽度为 Compact 时，明确找到要将新视图控制器放在其上的视图控制器，然后执行此操作。我认为您可能想在第一个选项卡中推送到导航控制器：
func splitViewController(splitViewController: UISplitViewController, showDetailViewController vc: UIViewController, sender: AnyObject?) -> Bool
{
if splitViewController.traitCollection.horizontalSizeClass == .Compact {
// The default implementation will not handle this properly.
// Find the appropriate navigation controller and push onto it.
// It would be better to have a direct outlet to the appropriate navigation controller,
// but this will work for an example...
if let tabBarController = splitViewController.viewControllers.first as? UITabBarController {
if let navController = tabBarController.viewControllers?.first as? UINavigationController {
navController.pushViewController(vc, animated: true)
// we handled the "show detail", so split view controller,
// please don't do anything else
return true
}
}
}
// we did not handle the "show detail", so split view controller,
// please do your default behavior
return false
}
如果这样做，您还需要实现此委托方法。当大小改回常规时，您将希望通过从同一导航控制器弹出该视图控制器然后返回它来处理 "expand"：
optional public func splitViewController(
splitViewController: UISplitViewController
separateSecondaryViewControllerFromPrimaryViewController
primaryViewController: UIViewController) -> UIViewController?
我有一个现有的 iPhone 应用程序，我正在向其添加 UISplitViewController。 iPad 部分就像一个魅力，但我肯定会在 iPhone 6(S) Plus 上崩溃。
设置 - Master 是 UITabBarController。初始细节是带有占位符徽标视图的视图。一旦一个对象被 selected，细节被替换为 UITabBarController.
每当我 select 一个项目并在 iPhone 6 Plus 中打开细节并将其从纵向（仅细节可见）旋转到横向（主图可见）时，它会崩溃.使用占位符详细视图旋转时不会发生这种情况。
在崩溃之前，它确实调用了委托方法 primaryViewControllerForExpandingSplitViewController 和 splitViewController(splitViewController: UISplitViewController, separateSecondaryViewControllerFromPrimaryViewController。但是，在 iPad.
我已经进行了大量搜索，但只在 Twitter 上看到几条提及此类崩溃的信息。设置或不设置 displayModeButtonItem 之类的事情没有帮助。
我在一个新项目中重新创建了这个崩溃 - 它可以在这里下载： https://github.com/sschale/SplitViewCrash/
崩溃日志：
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff53609ff8
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0x7fff53609ff8:
MALLOC_TINY 00007f8405000000-00007f8405300000 [ 3072K] rw-/rwx SM=PRV
--> STACK GUARD 00007fff4fe0a000-00007fff5360a000 [ 56.0M] ---/rwx SM=NUL stack guard for thread 0
Stack 00007fff5360a000-00007fff53dff000 [ 8148K] rw-/rwx SM=COW thread 0
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 liboainject.dylib 0x000000010e5e59b2
0 liboainject.dylib 0x000000010e5e59b2
_writeEventToSharedMemory + 27
1 liboainject.dylib 0x000000010e5e55d7 _OARecordFinalEvent + 1161
2 liboainject.dylib 0x000000010e5e79f1 ___swapMethods_block_invoke_6 + 338
3 libobjc.A.dylib 0x000000010f4f9b6b weak_read_no_lock + 89
4 libobjc.A.dylib 0x000000010f4fa4c6 objc_loadWeakRetained + 104
5 com.apple.UIKit 0x00000001110510b6 -[UIViewController presentedViewController] + 58
6 com.apple.UIKit 0x0000000111033fc6 -[UIViewController _canBecomeDeepestUnambiguousResponder] + 31
7 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
8 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
9 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
10 com.apple.UIKit 0x0000000111033fde -[UIViewController _canBecomeDeepestUnambiguousResponder] + 55
//(500 more of those)
....
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x0000000116e49ee2 kevent64 + 10
1 libdispatch.dylib 0x0000000116ac57f0 _dispatch_mgr_invoke + 260
2 libdispatch.dylib 0x0000000116ac558a _dispatch_mgr_thread + 54
Thread 2:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
Thread 3:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
Thread 4:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
Thread 5:
0 libsystem_kernel.dylib 0x0000000116e495e2 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x0000000116e0d578 _pthread_wqthread + 1283
2 libsystem_pthread.dylib 0x0000000116e0b341 start_wqthread + 13
这也会在 iPad 上崩溃。使用多任务将应用程序调整为紧凑宽度（例如 1/3 屏幕），按“启动详细信息”按钮，然后将其调整为常规宽度。
当您处于紧凑宽度时，拆分视图控制器为 "collapsed"。这意味着它不再同时显示单独的主视图控制器和辅助视图控制器——相反，它 "collapses" 它们进入单个视图控制器层次结构。当它处于那种环境中时，它通常需要您的帮助才能做出明智的行为。当您的主视图控制器和辅助视图控制器都是 UINavigationController 时，默认行为运行良好，但在其他情况下则不然。
（在您的应用程序中，您的主要是 UITabBarController，在您 "Launch Detail" 一次之后，次要也是 UITabBarController。您可能需要重新考虑该设计，因为它使事情变得更加困难。继续阅读.)
您应用的 "Launch Detail" 按钮执行 "Show Detail" 转场，这有效地调用了 UISplitViewController 上的此方法：
public func showDetailViewController(vc: UIViewController, sender: AnyObject?)
注意 header 中的注释：
// In a horizontally-compact environment the master view controller
// or detail view controller is sent the showViewController:sender:
// message. If neither one of them provide an implementation for this
// method then it will fall back to a full screen presentation.
"master view controller or detail view controller"表示当前显示的视图控制器，在您的例子中是 UITabBarController。但是 UITabBarController 没有为 showViewController() 实现任何东西，因为它没有足够的信息——它将在哪里显示视图控制器？它会添加一个新标签，还是替换旧标签，或者什么？
因此，您得到了后备 full-screen 演示文稿。我怀疑你真的想要那种用户体验。
稍后，当大小变回常规并且拆分视图控制器展开时，它会被演示混淆并最终崩溃。 （明白我说的默认值不是很好的意思了吗？）
解决此问题的一种方法是实施委托方法来处理 showDetail。当宽度为 Compact 时，明确找到要将新视图控制器放在其上的视图控制器，然后执行此操作。我认为您可能想在第一个选项卡中推送到导航控制器：
func splitViewController(splitViewController: UISplitViewController, showDetailViewController vc: UIViewController, sender: AnyObject?) -> Bool
{
if splitViewController.traitCollection.horizontalSizeClass == .Compact {
// The default implementation will not handle this properly.
// Find the appropriate navigation controller and push onto it.
// It would be better to have a direct outlet to the appropriate navigation controller,
// but this will work for an example...
if let tabBarController = splitViewController.viewControllers.first as? UITabBarController {
if let navController = tabBarController.viewControllers?.first as? UINavigationController {
navController.pushViewController(vc, animated: true)
// we handled the "show detail", so split view controller,
// please don't do anything else
return true
}
}
}
// we did not handle the "show detail", so split view controller,
// please do your default behavior
return false
}
如果这样做，您还需要实现此委托方法。当大小改回常规时，您将希望通过从同一导航控制器弹出该视图控制器然后返回它来处理 "expand"：
optional public func splitViewController(
splitViewController: UISplitViewController
separateSecondaryViewControllerFromPrimaryViewController
primaryViewController: UIViewController) -> UIViewController?