当前位置：首页 > news >正文

消失的它：揭开 CoreData 托管对象神秘的消失之谜（上）

news 来源：原创 2025/6/20 13:44:39

在这里插入图片描述

概述

使用 CoreData 作为 App 持久存储“定海神针”的小伙伴们想必都知道，我们需要将耗时的数据库查询操作乖巧的放到后台线程中，以便让主线程负责的 UI 获得风驰电掣般地享受。

在这里插入图片描述

不过，如何将后台线程中查询获得的托管对象稳妥的传送至主线程中，这却是一个问题。稍有不慎，原本“老实本分的”托管对象可能会立即消失的无影无踪，让一切前功尽弃。

在本篇博文中，您将学到如下内容：

概述
1. 一次“平淡无奇”的优化
2. 阿欧！对象全部不见鸟
总结

相信学完本系列课程后，小伙伴们倘若再遇到类似的问题都会胸有成竹，迎刃而解。

那还等什么呢？让我们马上开始探案大冒险吧，Let‘s go！！！😉

1. 一次“平淡无奇”的优化

小伙伴们都知道，要想在苹果系统中更新界面内容，我们必须在主线程中勇敢的承担起所有责任。

这在 SwiftUI 中也不例外。何曾几时，Apple 已将 UIKit 以及 SwiftUI 所有与界面相关的对象都用 MainActor 修饰起来，从而彰显出主线程这一神圣使命。

在这里插入图片描述

于是乎，我们必须将所有耗时操作都统统放到后台线程中以便让主线程“北窗高卧”。那么，哪些属于耗时操作呢？CoreData 海量数据的查询妥妥的算是一个。

在下面的代码中，视图里的 countTraces 属性包含了一切图表（Chart）所需的计数记录（CountTrace）。毫无疑问，它已被牢牢打上 MainActor 的烙印，这不禁让我们必须牢记——把对它的任何更新操作都放到主线程上去：

@State private var countTraces = [CountTrace]()

Chart {
    ForEach(Array(countTraces.enumerated()), id: \.offset) { i, trace in
        PointMark(x: .value("索引", i), y: .value("计数", trace.count))
    }
    
    ForEach(Array(countTraces.enumerated()), id: \.offset) { i, trace in
        LineMark(x: .value("索引", i), y: .value("计数", trace.count))
            .foregroundStyle(.blue.opacity(0.33))
    }
}

当用户触发显示图表的操作时，我们从后台线程查询这些计数记录，然后再回到主线程里将它们赋予 countTraces 属性：

let container = Model.shared.controller.container
container.performBackgroundTask { bgContext in
	// 获取最近 30 条计数记录
    let traces = try! counter.querySortedTraces(30, context: bgContext)
    
    DispatchQueue.main.sync {
    	// 回到主线程中更新 countTraces 属性
        countTraces = traces
    }
}

这些都看起来是那么的驾轻就熟，不是吗？

2. 阿欧！对象全部不见鸟

不过，当我们意气风发地在 Xcode 预览中执行上述代码时，就会发现结果似乎有些不太对劲：

在这里插入图片描述

在显示的图表中所有记录的计数都一样，这貌似不大可能。我们可以完全肯定这些计数值都是随机生成的，所以它们全部相同的概率几乎为零。

俗话说得好：不会调试的厨师不是好司机。为了让真相逐渐浮出水面，我们首先需要对之前的实现增加调试辅助代码：

let container = Model.shared.controller.container
container.performBackgroundTask { bgContext in
    let traces = try! counter.querySortedTraces(30, context: bgContext)
    print("#1: \(traces.map {$0.count})")
    
    DispatchQueue.main.async {
        print("#2: \(traces.map {$0.count})")
        countTraces = traces
    }
}

接着，重新在 Xcode 预览中触发图表展开操作，从调试控制台的输出可以看到，前脚我们获取到的所有 CountTrace 对象都表现正常，而后一秒它们将会让我们瞠目结舌：

#1: [10, 1, 7, 4, 3, 4, 4, 7, 8, 3, 5, 6, 8, 3, 3, 2, 2, 10, 3, 9, 7, 1, 9, 1, 7, 6, 4, 8, 1, 8]
#2: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

从上面的调试输出不难发现：进入主线程后，traces 所有对象的 count 属性竟然全部“神秘地”变为 0 了。

在这里，请允许我们先猜测一下问题的根本症结：之所以会如此，是因为 traces 中所有托管对象被提前释放掉了。

至于为什么它们会被释放，我们在后面再给出真正的原因。

在下一篇文章中，大家将基于我们的推测来尝试解决一下这个问题，当然这些尝试都将先以失败而告终。

我们不见不散！