我有点困惑，找不到关于这个案例的正确信息。我们从文档中都知道:
Use this function to stop the program, without impacting the performance of shipping code, when control flow is not expected to reach the call—for example, in the default case of a switch where you have knowledge that one of the other cases must be satisfied. To protect code from invalid usage in Release builds, see 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 支持响应:
I don't know of any particular Crashlytics-related behavior around assertionFailure, and unless it's terminating the main app thread I would not expect us to view it as a crash. I see there's already an answer on the stackoverflow post - does that clear things up?
最佳答案
不应该在 release 中启用断言使用 -O 构建优化级别。这意味着在最后 release那里的代码就像一个空行，因此 Crashlytics 不会崩溃。
仔细检查目标的 build settings ，如果您从头开始创建它或从调试中复制它，您可能已启用断言。
来自 docs :
In playgrounds and -Onone builds (the default for Xcode’s Debug configuration), stop program execution in a debuggable state after printing message.
In -O builds, has no effect.
In -Ounchecked builds, the optimizer may assume that this function is never called. Failure to satisfy that assumption is a serious programming error.
关于ios - Crashlytics 是否遇到 assertionFailure 崩溃？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59386400/