Xcode 9运行分屏应用在iPhone上崩溃问题求助

针对你遇到的Xcode 9应用在iPhone端（模拟器/真机）快速崩溃、iPad端正常，且疑似和分屏主/详情视图相关的问题，给你整理一套逐步排查的思路和实用调试技巧：

1. 先抓崩溃日志，跳过实时调试的局限 #

既然崩溃太快来不及复制调试器信息，先绕开实时调试，直接拿崩溃日志：

• 真机：连接设备后打开Xcode的Window > Devices and Simulators，选中你的设备，点击View Device Logs，找到对应应用的崩溃记录。日志里的Exception Type和Thread 0的调用栈是核心，能直接定位崩溃的代码位置。
• 模拟器：崩溃日志存在~/Library/Logs/DiagnosticReports/目录下，找以你应用名开头的.crash文件，用文本编辑器打开就能看到完整的崩溃详情。

2. 聚焦分屏视图的iPhone/iPad差异化逻辑 #

因为iPad正常、iPhone异常，大概率是iPhone端的主/详情视图适配逻辑出了问题：

• 检查UISplitViewController的collapsed状态处理：iPhone上默认是折叠状态，有没有代码强制调用了只有iPad分屏模式才支持的方法？比如直接访问secondaryViewController但在折叠状态下它是空的？
• 核对界面跳转逻辑：比如在iPhone上触发主视图到详情视图的跳转时，有没有因为未正确初始化详情控制器导致空指针崩溃？
• 对比布局约束：有没有在iPhone上存在约束冲突，或者某个视图的frame计算异常导致的崩溃？哪怕视图层级捕获报错，也可以先在iPad上捕获正常的视图层级，再对比iPhone端的布局代码差异。

3. 优化断点策略，精准定位崩溃触发点 #

你说设置异常断点会停在AppDelegate，试试调整断点规则：

• 编辑All Objective-C Exceptions断点：右键点击这个断点选择Edit Breakpoint，把Exception选项改成Throw，这样会在异常抛出时就停下来，而不是等到捕获时，能抓到更早的调用栈，更容易定位根源。
• 添加符号断点：如果从崩溃日志里看到了关键方法名，直接添加符号断点（点击断点导航栏的+，选Symbolic Breakpoint），输入方法名（比如-[UISplitViewController collapseSecondaryViewController:ontoPrimaryViewController:]），这样能在调用这个分屏核心方法时直接停下。
• 启用僵尸对象检测：打开Edit Scheme > Run > Diagnostics，勾选Zombie Objects，如果是野指针访问已释放对象，会在崩溃时明确提示你哪个对象被过度释放了，这在内存相关崩溃里非常有用。

4. 排查视图层级捕获报错的关联问题 #

你遇到的Unable to capture view hierarchy错误，有时候和应用内存异常、或某个视图对象状态异常有关：

• 先清理项目缓存：执行Product > Clean Build Folder，然后重启Xcode和模拟器/设备，再尝试捕获视图层级，很多时候缓存问题会导致这类奇怪的报错。
• 临时注释分屏相关代码：如果注释后视图层级能正常捕获，说明问题就出在你注释的那部分分屏逻辑里，再逐步恢复代码，就能定位到具体的异常代码块。

5. 最小化测试+代码回滚，兜底排查 #

如果上面的方法都没找到根因，试试这两个兜底方案：

• 最小化测试项目：新建一个空项目，只添加分屏主/详情视图的核心逻辑，测试是否会崩溃。如果不崩溃，再逐步把原项目的代码、资源迁移过来，每迁移一部分就测试一次，直到出现崩溃，就能精准定位问题代码。
• Git代码回滚：回滚到一个月前应用正常的版本，测试是否还会崩溃。如果正常，对比当前版本和旧版本的代码差异，找出引入问题的提交记录，这是定位代码变更导致问题的高效方法。

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