概述

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

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

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

Let‘s dive in！！！😉

---

1. 崩溃！又见崩溃！

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

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

@Model
class Item {
    var name: String
    var timestamp: Date
    
    init(name: String) {
        self.name = name
        timestamp = .now
    }
}

@Model
class Model {
    
    static let UniqID = UUID(uuidString: "3788ABA9-043C-4D34-B119-5D69D486CBBA")!
    var mid: UUID
    
    @Relationship
    var item: Item?
    
    init(mid: UUID, item: Item? = nil) {
        self.mid = mid
        self.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 modelContext
        
    var 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.shared
            modelContext.insert(model)
            model.item = item
            
            try! 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.mainContext
    
    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.mainContext 必须在主线程上使用，所以它是被 @MainActor 所修饰着的，因而这一修饰符也必须“传染”到 shared 静态属性自身上。

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

总结

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

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

感谢观赏，再会！😎