由一个 SwiftData “诡异”运行时崩溃而引发的钩深索隐(一)

2024-09-04 13:20

本文主要是介绍由一个 SwiftData “诡异”运行时崩溃而引发的钩深索隐(一),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在这里插入图片描述

概述

从 WWDC 23 开始,苹果推出了全新的数据库框架 SwiftData。它借助于 Swift 语言简洁而富有表现力的特点,抛弃了以往数据库所有的额外配置文件,只靠纯代码描述就可以干脆利索的让数据库的创建和增删改查(CRUD)一气呵成。

在这里插入图片描述

在本系列博文中,我们将从一个简单而“诡异”的运行“事故”开始,有理有据的深入探寻一番 SwiftData 中耐人寻味的“那些事儿”。

在本篇博文中,您将学到如下内容:

  • 概述
  • 1. 崩溃!又见崩溃!
  • 2. 寻根问底
  • 总结

这是本系列第一篇博文。闲言少叙,让我们马上开始 SwiftData 精彩的探究之旅吧!

Let‘s dive in!!!😉


1. 崩溃!又见崩溃!

“事故”的起因很简单,我们在 SwiftData 中创建了两个简单的托管类型 Item 和 Model。

其中,Model 类型里包含了指向 Item 的关系属性 item:

@Model
class Item {var name: Stringvar timestamp: Dateinit(name: String) {self.name = nametimestamp = .now}
}@Model
class Model {static let UniqID = UUID(uuidString: "3788ABA9-043C-4D34-B119-5D69D486CBBA")!var mid: UUID@Relationshipvar item: Item?init(mid: UUID, item: Item? = nil) {self.mid = midself.item = item}static var shared: Model = {let desc = FetchDescriptor<Model>()let context = ModelContext(.preview)if let result = try! context.fetch(desc).first {return result} else {let new = Model(mid: UniqID)context.insert(new)try! context.save()return new}}()
}

从上面的代码还可以看到,我们为 Model 添加了一个单例静态属性 shared,因为我们不希望创建多个 Model 的实例。

为了更好地在 Xcode 预览中调试代码,我们为 ModelContainer 扩展了一个 preview 静态属性用来获取模型容器中的测试数据:

extension ModelContainer {static var preview: ModelContainer = {try! ModelContainer(for: .init([Model.self, Item.self]), configurations: .init(isStoredInMemoryOnly: true))}()
}

接下来,我们构建 SwiftUI 界面以生成和显示模型容器中的持久数据。

从下面的代码可以看到,当 ContentView 视图显示时我们创建了一个新的 Item 记录,并将它设置到 Model.shared 对象的 Item 关系上,然后将 Item 中随机的值显示在视图中央:

struct ContentView: View {@Environment(\.modelContext) var modelContextvar body: some View {VStack {if let item = Model.shared.item {Text(item.name)}}.padding().task {let item = Item(name: "\(Int.random(in: 0...10000))")modelContext.insert(item)let model = Model.sharedmodelContext.insert(model)model.item = itemtry! modelContext.save()}}
}

然而,就是上面这几十行简单的代码竟然会立即导致运行时的崩溃:

在这里插入图片描述

从上图中可以看到,貌似崩溃直接发生在汇编代码中并没有对应任何源代码,这看起来不妙。

让我们来仔细看看崩溃的具体描述:

SwiftData/PersistentModel.swift:172: Fatal error: attempting to relate model - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata://DCDD7A8E-316D-4281-BD5C-ED76FF2F6E46/Model/p1), implementation: SwiftData.PersistentIdentifierImplementation) with model context - SwiftData.ModelContext to destination model - Optional(SwiftData.PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-swiftdata://Item/1B72D6AD-F2B6-436D-9817-AA803717A211), implementation: SwiftData.PersistentIdentifierImplementation)) from destination’s model context - SwiftData.ModelContext

那么现在问题来了:头发茂盛的小伙伴们能不能通过上面的源代码和崩溃信息确认崩溃真正的原因呢?大家自己先试一下吧。

2. 寻根问底

稍微“剧透一下”:如果在上述数据模型中不使用 @Relationship 来描述对象之间的关系,那么崩溃就会“烟消云散”。

这似乎意味着,上述错误和 SwiftData 中的 Relationship 连接有着“如胶似漆”的关系,果真如此吗?

再仔细观察一下崩溃信息的内容,它仿佛暗示着错误和模型上下文(ModelContext)息息相关:

… with model context - SwiftData.ModelContext to … model context - SwiftData.ModelContext

回忆一下,在 CoreData 中如果父托管对象包含一个子对象,那么如果它们承载于不同的托管对象上下文(NSManagedObjectContext)在保存时就会发生崩溃

为什么会出现这种情况?一种可能是父对象和子对象不是由同一个 NSManagedObjectContext 创建的,比如:子对象出生于后台线程中的托管对象上下文。


关于 CoreData 中更多后台线程执行的介绍,请小伙伴们移步如下链接观赏进一步内容:

  • Swift进一步优化CoreData后台线程读取数据时间的方法
  • CoreData从后台线程读取数据仍然阻塞UI界面的原因及解决

在 SwiftData 中,情况与此几乎如出一辙。回顾一下 Model.shared 静态属性的代码:

static var shared: Model = {let desc = FetchDescriptor<Model>()let context = ModelContext(.preview)if let result = try! context.fetch(desc).first {return result} else {let new = Model(mid: UniqID)context.insert(new)try! context.save()return new}
}()

看到了吗?我们根据 ModelContainer.preview 创建了一个新的 ModelContext,但这个模型上下文和 Model#items 关系中对应对象的上下文真的一致吗?

马上确认一下:我们新建 Item 托管对象的模型上下文是如何诞生的

在代码中不难发现,它是通过 modelContainer 修改器方法从 App 的 WindowGroup 中传入的:

@main
struct MyWatch_App: App {var body: some Scene {WindowGroup {ContentView().modelContainer(.preview)}}
}

然后在 ContentView 中通过 @Environment 引入到视图中:

struct ContentView: View {@Environment(\.modelContext) var modelContext
}

注意,貌似它们都对应同一个 ModelContainer.preview 模型容器,但其实它们却有着云泥之别:

  • 用 modelContainer 修改器从 App 的 WindowGroup 传入的上下文实际对应着 ModelContainer 容器中的主上下文
  • 而在 Model.shared 中用 ModelContext 创建的上下文则是容器的一个私有上下文

主上下文必须在主线程或 MainActor 中使用,而私有上下文可以运行在任何其它线程或 Actor 中。

在这里插入图片描述

所以,上面崩溃的前因后果已经很明晰了:**我们的 Model 是从私有上下文中创建的,而它 Item 关系所对应的对象却是从主上下文中创建的。**这在将数据保存到 SwiftData 的持久存储中时必然会引起上下文不一致,从而导致榱崩栋折。

知道了原因,解决起来就很简单了。

一种直观的方法是,同样在 ModelContainer.preview 的主上下文中创建 Model 的共享实例:

@MainActor
static var shared: Model = {let desc = FetchDescriptor<Model>()// 获取 ModelContainer.preview 的主上下文let context = ModelContainer.preview.mainContextif let result = try! context.fetch(desc).first {return result} else {let new = Model(mid: UniqID)context.insert(new)try! context.save()return new}
}()

注意:因为 ModelContainer.preview.mainContext 必须在主线程上使用,所以它是被 @MainActor 所修饰着的,因而这一修饰符也必须“传染”到 shared 静态属性自身上。

在这里插入图片描述

运行代码,一切崩溃都变得风吹云散了!我们 Model.shard 关系中 Item 的随机值顺利显示在了视图的中心,棒棒哒!💯

总结

在本篇博文中,我们介绍了一个导致 SwiftData 支持的应用发生轰然崩溃的问题,并随后讨论了它的前因后果以及解决之道。

在下一篇博文里,我们会接着讨论 SwiftData 如何在后台处理数据以及如何将它们同步到界面中;我们还会在后续文章中介绍 SwiftData 2.0 中新祭出的 History Trace 和“墓碑”机制,敬请期待吧。

感谢观赏,再会!😎

这篇关于由一个 SwiftData “诡异”运行时崩溃而引发的钩深索隐(一)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1136129

相关文章

Java -jar命令如何运行外部依赖JAR包

《Java-jar命令如何运行外部依赖JAR包》在Java应用部署中,java-jar命令是启动可执行JAR包的标准方式,但当应用需要依赖外部JAR文件时,直接使用java-jar会面临类加载困... 目录引言:外部依赖JAR的必要性一、问题本质:类加载机制的限制1. Java -jar的默认行为2. 类加

java -jar命令运行 jar包时运行外部依赖jar包的场景分析

《java-jar命令运行jar包时运行外部依赖jar包的场景分析》:本文主要介绍java-jar命令运行jar包时运行外部依赖jar包的场景分析,本文给大家介绍的非常详细,对大家的学习或工作... 目录Java -jar命令运行 jar包时如何运行外部依赖jar包场景:解决:方法一、启动参数添加: -Xb

eclipse如何运行springboot项目

《eclipse如何运行springboot项目》:本文主要介绍eclipse如何运行springboot项目问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目js录当在eclipse启动spring boot项目时出现问题解决办法1.通过cmd命令行2.在ecl

使用nohup和--remove-source-files在后台运行rsync并记录日志方式

《使用nohup和--remove-source-files在后台运行rsync并记录日志方式》:本文主要介绍使用nohup和--remove-source-files在后台运行rsync并记录日... 目录一、什么是 --remove-source-files?二、示例命令三、命令详解1. nohup2.

Spring Boot项目打包和运行的操作方法

《SpringBoot项目打包和运行的操作方法》SpringBoot应用内嵌了Web服务器,所以基于SpringBoot开发的web应用也可以独立运行,无须部署到其他Web服务器中,下面以打包dem... 目录一、打包为JAR包并运行1.打包为可执行的 JAR 包2.运行 JAR 包二、打包为WAR包并运行

防止SpringBoot程序崩溃的几种方式汇总

《防止SpringBoot程序崩溃的几种方式汇总》本文总结了8种防止SpringBoot程序崩溃的方法,包括全局异常处理、try-catch、断路器、资源限制、监控、优雅停机、健康检查和数据库连接池配... 目录1. 全局异常处理2. 使用 try-catch 捕获异常3. 使用断路器4. 设置最大内存和线

Java NoClassDefFoundError运行时错误分析解决

《JavaNoClassDefFoundError运行时错误分析解决》在Java开发中,NoClassDefFoundError是一种常见的运行时错误,它通常表明Java虚拟机在尝试加载一个类时未能... 目录前言一、问题分析二、报错原因三、解决思路检查类路径配置检查依赖库检查类文件调试类加载器问题四、常见

Python如何精准判断某个进程是否在运行

《Python如何精准判断某个进程是否在运行》这篇文章主要为大家详细介绍了Python如何精准判断某个进程是否在运行,本文为大家整理了3种方法并进行了对比,有需要的小伙伴可以跟随小编一起学习一下... 目录一、为什么需要判断进程是否存在二、方法1:用psutil库(推荐)三、方法2:用os.system调用

Python运行中频繁出现Restart提示的解决办法

《Python运行中频繁出现Restart提示的解决办法》在编程的世界里,遇到各种奇怪的问题是家常便饭,但是,当你的Python程序在运行过程中频繁出现“Restart”提示时,这可能不仅仅是令人头疼... 目录问题描述代码示例无限循环递归调用内存泄漏解决方案1. 检查代码逻辑无限循环递归调用内存泄漏2.

Java终止正在运行的线程的三种方法

《Java终止正在运行的线程的三种方法》停止一个线程意味着在任务处理完任务之前停掉正在做的操作,也就是放弃当前的操作,停止一个线程可以用Thread.stop()方法,但最好不要用它,本文给大家介绍了... 目录前言1. 停止不了的线程2. 判断线程是否停止状态3. 能停止的线程–异常法4. 在沉睡中停止5