Crashlytics 是否遇到 assertionFailure 崩溃？答案

【问题标题】：Does Crashlytics encounter assertionFailure as crash?Crashlytics 是否遇到 assertionFailure 崩溃？
【发布时间】：2019-12-18 06:14:19
【问题描述】：

我有点困惑，找不到有关此案的正确信息。从文档中我们都知道：

使用此功能停止程序，而不影响程序运输代码的性能，当控制流不期望时接听电话——例如，在默认情况下，您在知道必须满足其他情况之一。到保护代码免受发布版本中的无效使用，请参阅 preconditionFailure(_:file:line:).

但是，当我的 asserionFailure 触发时，我会在 Crashlytics 中收到崩溃报告。

Crashed: com.apple.main-thread
0  libswiftCore.dylib             0x1b0c15efc specialized _assertionFailure(_:_:file:line:flags:) + 440
1  libswiftCore.dylib             0x1b0a316b8 assertionFailure(_:file:line:) + 96
2  OneFit                         0x100a3d238 AdditionalUserInfoRouter.enqueueRoute(with:animated:completion:) + 64 (AdditionalUserInfoRouter.swift:64)
3  OneFit                         0x100a53040 protocol witness for MVVMRouter.enqueueRoute(with:animated:completion:) in conformance AdditionalUserInfoRouter + 4374458432 (<compiler-generated>:4374458432)
4  OneFit                         0x100638224 MVVMRouter.enqueueRoute(with:) + 32 (MVVMRouter.swift:32)
5  OneFit                         0x100a6a6c8 closure #2 in AdditionalUserInfoViewModel.close() + 132 (AdditionalUserInfoViewModel.swift:132)
6  OneFit                         0x100a676a0 thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374541984 (<compiler-generated>:4374541984)
7  OneFit                         0x100a6fb94 partial apply for thunk for @escaping @callee_guaranteed (@guaranteed [Subscription]) -> (@error @owned Error) + 4374576020 (<compiler-generated>:4374576020)
8  PromiseKit                     0x10344d048 $s10PromiseKit8ThenablePAAE4done2on5flags_AA0A0CyytGSo17OS_dispatch_queueCSg_8Dispatch0J13WorkItemFlagsVSgy1TQzKctFyAA6ResultOyARGcfU_yycfU_ + 64
9  PromiseKit                     0x103426614 $sIeg_IeyB_TR + 28
10 libdispatch.dylib              0x1a35a9610 _dispatch_call_block_and_release + 24
11 libdispatch.dylib              0x1a35aa184 _dispatch_client_callout + 16
12 libdispatch.dylib              0x1a355c1d0 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
13 CoreFoundation                 0x1a385a3c4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
14 CoreFoundation                 0x1a38553b8 __CFRunLoopRun + 2004
15 CoreFoundation                 0x1a38548bc CFRunLoopRunSpecific + 464
16 GraphicsServices               0x1ad6c0328 GSEventRunModal + 104
17 UIKitCore                      0x1a78ea6d4 UIApplicationMain + 1936
18 OneFit                         0x1003b3784 main + 39 (AppDelegate.swift:39)
19 libdyld.dylib                  0x1a36df460 start + 4

Crashlytics 日志会断言崩溃还是我遇到了真正的崩溃？

UPD： Firebase/Crashlytics 支持响应：

我不知道任何与 Crashlytics 相关的特定行为 assertionFailure，除非它终止主应用程序线程不会期望我们将其视为崩溃。我看到已经有一个在 stackoverflow 帖子上回答 - 这是否清楚？

【问题讨论】：

据我所见，我假设您的 OneFit 模块的符号，这是 Debug 构建，那么有什么问题？所有assert* 在发布版本中都被禁用，但故意出现在调试中以向您展示意外情况。你进入了意外的行，assert 被触发了，如果它不在 Xcode 下它就是崩溃（实际上在 Xcode 中它也是崩溃，但是被拦截了）。
@Asperi 您好，感谢您的回复，但它是release build。我为dev 和prod 分离了目标。我几乎从不为开发构建发布目标，但我每周仍然有 10-15 次这种崩溃。
在 Release build 中不应该有你的应用符号，所以它只是 nominal release build。无论如何，您应该检查发生断言的代码并修复它，即使断言是合法的开发工具，我建议完全避免使用它并明确处理相应的情况（加上创建日志）。

标签： ios firebase assert crashlytics

【解决方案1】：

断言不应该在 release 构建中启用 -O 优化级别。这意味着在最终的release 代码中将有一个空白行，因此 Crashlytics 没有什么可崩溃的。

仔细检查您的目标的build settings，如果您是从头开始创建它或从调试中复制它，您可能启用了断言。

来自docs：

在 Playgrounds 和 -Onone 构建中（Xcode 调试的默认设置）配置），在可调试状态后停止程序执行打印消息。

在 -O 构建中，没有效果。

在 -Ounchecked 构建中，优化器可能假设此函数是从来没有打电话。不满足这个假设是严重的编程错误。

【讨论】：

感谢您的回答，我看到我的优化级别Release 选项等于-Onone。这是否意味着我的代码在 App Store 构建时崩溃了？
我确信我们不应该对发布使用任何类型的优化...
是的，使用 -Onone 如果断言检查失败，您的代码将崩溃，您必须将其用于调试构建。不可以，发布到公共版本必须使用 -O 进行全面优化。出于测试目的，您可以通过 TestFlight 分发带有 -Onone 的 beta 版本，但不能公开发布。
优化后的代码运行速度也更快，用户体验更好。
谢谢！让我测试一下，然后我会提交答案