应用程序在发布版本中崩溃，但在调试中没有崩溃

Question

正如我在标题中所说，我正在为iPhone编写一个应用程序，它在调试模式下运行完美，但当我将其构建为发布并通过TestFlight安装时，它崩溃了。 由于崩溃日志，它可能需要对这些行做一些事情：

let path = NSBundle.mainBundle().pathForResource("PrinterList", ofType: "plist")
if path != nil {
    let printerDic = NSDictionary(contentsOfFile: path!)
    let printerList = NSArray(array: printerDic.allKeys)
    printerNames = printerList as [String]
}

我使用Brother的框架在没有AirPrint的情况下打印，但我认为这不是问题，因为应用程序在使用框架之前崩溃了。 它只在我执行这些行的ViewController中崩溃。我也只需要在这个ViewController中使用框架。

Answer 1

有很多原因可能导致应用程序在发布模式下崩溃但在调试模式下不会崩溃（例如，内存分配差异会显示两个版本中实际存在的错误。）他们可能需要大量工作才能跟踪，即使是非beta编译器/语言。

你说如果按照我的建议去做，并且在关闭优化的情况下构建发布版本，问题就会消失。鉴于Swift编译器仍然处于测试阶段并且肯定仍然存在问题 - 我已经看到编译器在构建优化版本时会崩溃 - 这实际上可能是一个优化器错误。

因此，现在，我推迟调查。在我们获得编译器的完整发行版之前，不进行优化发布。然后，重新启用优化并查看是否仍有问题。如果你这样做，那是开始消耗能量的时间，试图找出它是编译器错误还是你自己代码中的错误。

Answer 2

我遇到了同样的问题。我终于通过启用whole module optimization来修复它。结合access control的正确实现 这应该可以解决你的崩溃问题。

根据Apple的整个模块优化：

  

使用整个模块优化来推断内部声明的最终结果。   具有内部访问权限的声明（默认情况下，如果没有声明）   仅在声明它们的模块中可见。因为   Swift通常会单独编译组成模块的文件，   编译器无法确定是否有内部声明   被覆盖在另一个文件中。但是，如果整个模块   启用优化，所有模块都在一起编译   同时。这允许编译器对其进行推断   整个模块在一起并推断最终的声明与内部   如果没有明显的覆盖。

您可以在项目设置中启用此功能：

但要注意，此选项可以优化目标中的所有文件，并以增加编译时间为代价实现更好的性能。

Answer 3

要捕获崩溃测试，优化级别设置为最快，调试模式下最小的[-Os]，以更接近地模拟将生成的代码和＆amp;在用户的设备上运行。

您可以在Swift编译器/代码生成

下的构建设置中进行设置

Answer 4

Apple还描述了一个已知的issue。我简要描述一下，以防有人寻找答案而前一个解决方案不起作用。

检查您的崩溃日志中是否有

等错误

Dyld Error Message:
  Library not loaded: @rpath/libswiftCore.dylib

或

[....] [deny-mmap] mapped file has no team identifier and is not a platform binary:
/private/var/mobile/Containers/Bundle/Application/5D8FB2F7-1083-4564-94B2-0CB7DC75C9D1/YourAppNameHere.app/Frameworks/libswiftCore.dylib

如果您有类似上面的崩溃输出，请关注apple guidance。

PS：即使在Window - ＆gt; XCode中的设备下，您也可以轻松查看日志。单击设备，然后单击查看设备日志。