由一个 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

相关文章

如何用Docker运行Django项目

本章教程,介绍如何用Docker创建一个Django,并运行能够访问。 一、拉取镜像 这里我们使用python3.11版本的docker镜像 docker pull python:3.11 二、运行容器 这里我们将容器内部的8080端口,映射到宿主机的80端口上。 docker run -itd --name python311 -p

跨系统环境下LabVIEW程序稳定运行

在LabVIEW开发中,不同电脑的配置和操作系统(如Win11与Win7)可能对程序的稳定运行产生影响。为了确保程序在不同平台上都能正常且稳定运行,需要从兼容性、驱动、以及性能优化等多个方面入手。本文将详细介绍如何在不同系统环境下,使LabVIEW开发的程序保持稳定运行的有效策略。 LabVIEW版本兼容性 LabVIEW各版本对不同操作系统的支持存在差异。因此,在开发程序时,尽量使用

如何在运行时修改serialVersionUID

优质博文:IT-BLOG-CN 问题 我正在使用第三方库连接到外部系统,一切运行正常,但突然出现序列化错误 java.io.InvalidClassException: com.essbase.api.base.EssException; local class incompatible: stream classdesc serialVersionUID = 90314637791991

win7+ii7+tomcat7运行javaWeb开发的程序

转载请注明出处:陈科肇 1.前提准备: 操作系统:windows 7 旗舰版   x64 JDK:jdk1.7.0_79_x64(安装目录:D:\JAVA\jdk1.7.0_79_x64) tomcat:32-bit64-bit Windows Service Installer(安装目录:D:\0tomcat7SerV) tomcat-connectors:tomcat-connect

php 7之PhpStorm + Nginx + Xdebug运行调试

操作环境: windows PHP 7.1.10 PhpStorm-2017.2.4 Xdebug 2.5.4 Xdebug helper 1.6.1 nginx-1.12.2 注意查看端口占用情况 netstat -ano //查看所以端口netstat -aon|findstr "80" //查看指定端口占用情况 比如80端口查询情况 TCP 0.0.0.0:8

[轻笔记] ubuntu Shell脚本实现监视指定进程的运行状态,并能在程序崩溃后重启动该程序

根据网上博客实现,发现只能监测进程离线,然后对其进行重启;然而,脚本无法打印程序正常状态的信息。自己通过不断修改测试,发现问题主要在重启程序的命令上(需要让重启的程序在后台运行,不然会影响监视脚本进程,使其无法正常工作)。具体程序如下: #!/bin/bashwhile [ 1 ] ; dosleep 3if [ $(ps -ef|grep exe_name|grep -v grep|

stl的sort和手写快排的运行效率哪个比较高?

STL的sort必然要比你自己写的快排要快,因为你自己手写一个这么复杂的sort,那就太闲了。STL的sort是尽量让复杂度维持在O(N log N)的,因此就有了各种的Hybrid sort algorithm。 题主你提到的先quicksort到一定深度之后就转为heapsort,这种是introsort。 每种STL实现使用的算法各有不同,GNU Standard C++ Lib

Docker进入容器并运行命令

在讨论如何使用Docker进入容器并运行命令时,我们需要先理解Docker的基本概念以及容器的工作原理。Docker是一个开放平台,用于开发、交付和运行应用程序。它使用容器来打包、分发和运行应用程序,这些容器是轻量级的、可移植的、自包含的,能够在几乎任何地方以相同的方式运行。 进入Docker容器的几种方式 1. 使用docker exec命令 docker exec命令是最常用的进入正在运

运行.bat文件,如何在Dos窗口里面得到该文件的路径

把java代码打包成.jar文件,编写一个.bat文件,执行该文件,编译.jar包;(.bat,.jar放在同一个文件夹下) 运行.bat文件,如何在Dos窗口里面得到该文件的路径,并运行.jar文件: echo 当前盘符:%~d0 echo 当前路径:%cd% echo 当前执行命令行:%0 echo 当前bat文件路径:%~dp0 echo 当前bat文件短路径:%~sdp0 nc

如何让应用在清除内存时保持运行

最近在写聊天软件。一个聊天软件需要做到在清除内存时仍能保持其应有的状态。      首先,我尝试在应用的Service中的onDestroy()进行重启应用,经过测试,发现被强制清除内存的应用不会调用Service的onDestroy,只会调用activity的onDestroy(),于是我决定在触发activity的onDestroy( )处发送广播给应用的静态广播接收器,然后让广播