您的位置:首页 > 汽车 > 时评 > 企业名录最新_高端平面设计网站_seo推广公司排名_站长之家查询域名

企业名录最新_高端平面设计网站_seo推广公司排名_站长之家查询域名

2025/4/13 6:33:50 来源:https://blog.csdn.net/mydo/article/details/147007070  浏览:    关键词:企业名录最新_高端平面设计网站_seo推广公司排名_站长之家查询域名
企业名录最新_高端平面设计网站_seo推广公司排名_站长之家查询域名

在这里插入图片描述

概述

使用 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 inPointMark(x: .value("索引", i), y: .value("计数", trace.count))}ForEach(Array(countTraces.enumerated()), id: \.offset) { i, trace inLineMark(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 inlet 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 中所有托管对象被提前释放掉了。

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

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

我们不见不散!

总结

在本篇博文中,我们介绍了 SwiftUI 后台线程向主线程传递托管对象“神秘失踪”这一迷案,并对其缘由给出了初步猜测。

感谢观赏,下一篇再见!😎

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com