iOS 应用程序在 Debug模式下崩溃，在 Release模式下工作

Question

有几个问题提出了与此完全相反的问题，我不明白如何/为什么在 Release模式下运行我的应用程序，但崩溃并显示 EXC_BAD_ACCESS Debug模式错误。

崩溃的方法是递归的，而且极其!!重大的;只要没有太多递归，它在调试(在 iPhone XS 上少于 ~1000，在模拟器上无限制)和 Release模式(无限制？)都可以正常工作。

我不知道从哪里开始找到如何调试 Debug模式，我想知道是否由于堆栈跟踪或其他未知原因捆绑了某种递归软限制？甚至可以归结为电缆，因为我能够在模拟器中成功运行而没有问题吗？

我应该注意到，Xcode 会在看似随机的位置报告崩溃，例如我知道已实例化且有效的属性 getter；以防万一。

我打算将它重构为更小的 block ，但我想我会在这里发帖，以防有人对可能导致此问题的原因有任何想法。

参见: https://gist.github.com/ThomasHaz/3aa89cc9b7bda6d98618449c9d6ea1e1

Answer 1

您的堆栈内存不足。

考虑这个非常简单的递归函数，将 1 到 n 之间的整数相加:

func sum(to n: Int) -> Int {
    guard n > 0 else { return 0 }
    return n + sum(to: n - 1)
}

您会发现，例如，如果您尝试对 1 到 100,000 之间的数字求和，应用程序在发布和调试版本中都会崩溃，但在调试版本中只会更快崩溃。我怀疑在调试版本中只是将更多诊断信息推送到堆栈上，导致堆栈中的空间更快耗尽。在上面的发布版本中，堆栈指针每次递归调用前移 0x20 字节，而调试构建每次前移 0x80 字节。而且，如果您在递归函数中做任何实质性的事情，这些增量可能会更大，并且可能会在递归调用更少的情况下发生崩溃。但是我的设备(iPhone Xs Max)和我的模拟器(Thread.current.stackSize)上的堆栈大小是 524,288 字节，这对应于堆栈指针前进的数量和我能够进行的递归调用的最大数量达到。如果您的设备比模拟器更早崩溃，则可能是您的设备的 RAM 较少，因此分配了较小的 stackSize。

最重要的是，如果您想享受快速性能但又不想招致巨大调用堆栈的内存开销，则可能需要将您的算法重构为非递归算法。顺便说一句，上述的非递归再现比递归再现快一个数量级。

或者，您可以异步分派(dispatch)递归调用，这消除了堆栈大小问题，但引入了 GCD 开销。上面的异步再现比简单的递归再现慢两到三个数量级，显然，比迭代再现慢另一个数量级。

诚然，我的简单 sum 方法非常简单，递归调用的开销开始占总计算时间的很大一部分，并且假设您的例程看起来更复杂，我怀疑差异不会那么明显。尽管如此，如果您想避免用完堆栈空间，我只是建议采用非递归再现。

---

我建议您观看以下 WWDC 视频:

• 2012 年全局开发者大会 iOS App Performance: Memory了解不同类型的内存，包括堆栈内存(但不会详细介绍后者)；
• WWDC 2018 iOS Memory Deep Dive是上述视频的更现代的版本；和
• 2015 年全局开发者大会 Profiling in Depth涉及尾递归优化。

---

值得注意的是，深度递归例程并不总是需要消耗大量堆栈。值得注意的是，有时我们可以使用 tail-recursion我们的递归调用是最后一次调用。例如。我上面的代码片段没有使用尾调用，因为它将 n 添加到递归调用返回的值中。但我们可以重构它以传递运行总数，从而确保递归调用是真正的“尾调用”:

func sum(to n: Int, previousTotal: Int = 0) -> Int {
    guard n > 0 else { return previousTotal }
    return sum(to: n - 1, previousTotal: previousTotal + n)
}

发布版本足够智能来优化这种尾递归(通过称为“尾调用优化”的过程，TCO，也称为“尾调用消除”)，从而减轻递归调用的堆栈增长。全局开发者大会 2015 Profiling in Depth ，而在另一个主题上，时间分析器准确地显示了优化尾调用时发生的情况。

最终效果是，如果您的递归例程使用尾调用，发布版本可以使用尾调用消除来缓解堆栈内存问题，但调试(未优化)版本不会这样做。