Question

有几个问题正好与此相反，我不了解在发布模式下运行应用程序的方式/原因，但是在调试模式下因EXC_BAD_ACCESS错误而崩溃。

崩溃的方法是递归的，而且非常！！实质只要没有太多的递归，它就可以在调试（iPhone XS上少于1000左右，在模拟器上不受限制）和发布模式（无限制吗？）中都可以正常工作。

我对从哪里开始寻找调试模式的调试感到困惑，我想知道是否由于堆栈跟踪或其他未知原因而捆绑了某种递归软限制？因为我可以在模拟器中成功运行而不会出现问题，甚至还可以解决电缆问题吗？

我应该注意，Xcode报告在看似随机的位置崩溃，例如我知道已实例化和有效的属性获取器；如果有帮助的话。

我将把它分解成较小的块，但是我想我会在这里张贴，以防任何人对可能导致这种情况的任何想法。

请参阅： 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。

最重要的是，如果您想享受快速的性能，但又不想增加庞大的调用堆栈的内存开销，则可能希望将算法重构为非递归算法。顺便说一句，以上的非递归表示比递归表示快一个数量级。

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

诚然，我的简单sum方法太琐碎了，以至于递归调用的开销开始占整个计算时间的很大一部分，并且考虑到您的例程看起来会更复杂，我怀疑差异将更少。尽管如此，如果您想避免堆栈空间用完，我只建议您采用非递归格式。

我希望您参考以下WWDC视频：

WWDC 2012 iOS App Performance: Memory承认不同类型的内存，包括堆栈内存（但没有详细介绍后者）；
WWDC 2018 iOS Memory Deep Dive是上述视频的较现代版本；和
WWDC 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（也称为“尾调用消除”）的过程），从而减轻了递归调用的堆栈增长。 WWDC 2015 Profiling in Depth在另一个主题上是时间分析器，它准确地显示了优化尾部调用时发生的情况。

最终结果是，如果递归例程正在使用尾部调用，则发布版本可以使用尾部调用消除来减轻堆栈内存问题，但是调试（未优化）版本将无法做到这一点。

Answer 2

EXEC_BAD_ACCESS通常意味着您正在尝试访问不在内存中或可能未正确初始化的对象。

签入代码，是否以某种方式删除了Dictionary变量后正在访问它？您的变量是否正确初始化？您可能已经声明了变量，但没有初始化它并访问它。

可能有很多原因，并且在看不到任何代码的情况下不能说太多。

尝试打开NSZombieOjects-这可能会为您提供更多调试信息。请参阅此处如何在Xcode中启用NSZombie？

如果您想知道错误的确切位置和发生时间，则可以使用仪器检查内存泄漏。这可能会有所帮助http://www.raywenderlich.com/2696/instruments-tutorial-for-ios-how-to-debug-memory-leaks

iOS应用在调试模式下崩溃，在发布模式下工作

2 个答案: