iOS SwiftUI应用后台_objc_msgSend崩溃排查及原因分析

崩溃根源与原因 #

EXC_BAD_ACCESS（SIGSEGV）访问0x0地址，本质是野指针访问——向已被释放的Objective-C对象发送了消息。崩溃发生在UIViewController的dealloc阶段，说明该ViewController实例已被系统回收，但仍有异步任务或回调持有它的强引用，或试图调用它的方法/关联属性。

是否与AppDelegate相关 #

大概率无关，除非你的AppDelegate在应用进入后台时执行了直接操作已释放UI组件（如ViewController）的逻辑，或持有了这些组件的无效引用。常规的AppDelegate生命周期方法（如applicationDidEnterBackground）本身不会导致这类崩溃。

定位异常代码行的方法 #

• 启用Zombie Objects检测：在Xcode的Scheme设置中，进入Diagnostics标签，勾选Zombie Objects。当程序试图访问已释放的对象时，会抛出明确的错误信息，直接指出被过度释放的对象类型和调用栈，这是定位这类问题最有效的方式。
• 符号化崩溃日志：如果只有原始崩溃日志，用Xcode的组织者（Organizer）导入日志自动符号化，或使用atos命令结合App的二进制文件、UUID和崩溃地址，解析出具体的代码行。
• 排查延迟异步任务：重点检查所有使用DispatchQueue.main.asyncAfter或类似延迟执行的代码，这类任务很可能在ViewController被释放后才触发，导致野指针访问。

疑似代码片段的风险分析 #

片段1：UINotificationFeedbackGenerator的延迟异步代码 #

大概率是崩溃原因。风险点包括：

• 如果闭包中直接捕获了self（ViewController实例）的强引用，当ViewController被释放后，闭包仍持有无效的self引用，触发objc_msgSend时访问已释放的对象。
• UINotificationFeedbackGenerator是UIKit对象，依赖活跃的UI环境，应用进入后台后相关UI资源可能被回收，延迟任务触发时调用其方法（如notificationOccurred(_:)）会访问已释放的底层对象。

片段2：延迟修改@EnvironmentObject的AppStateForUser属性 #

概率较低。如果AppStateForUser是在App入口通过.environmentObject全局注入的，它的生命周期与App一致，不会轻易被释放。只有当该对象是局部注入（仅在某个View/VC范围内有效），且延迟闭包持有了已释放的View/VC的强引用时，才可能触发崩溃，但这种场景远少于片段1的情况。

内容的提问来源于stack exchange，提问作者dhaval123