概述
在 SwiftUI 日常撸码过程中，头发尚且还算茂盛的小码农们经常会犯这样那样的错误。虽然犯这些错的原因都很简单，但有时想要快速准确的定位它们却并不容易。
况且这些错误还可能在模拟器和 Xcode 预览（Preview）表现的行为不甚一致，这无疑加大了“驯服”它们的难度。
在本篇博文中，您将学到如下内容：
- 概述
- 1. TabView 每个标签页 tag 类型需要谨慎对待
- 2. 视图中 @FetchRequest 定义不完整导致的崩溃
- 总结
本文出现的问题在 Xcode 16.1 + iOS 18.1 中仍会存在。
相信学完本课后，小伙伴们倘若以后再遇到与此类似的问题，必将胸有成竹、迎刃而解。
那还等什么呢？Let‘s fix it！！！😉
本文对应的视频课在此，欢迎小伙伴们恣意观赏：
SwiftUI 撸码常见错误 2 例漫谈
1. TabView 每个标签页 tag 类型需要谨慎对待
在下面这个简单的例子中，点击 TabView 内部每个标签页竟然毫无反应！
下面上源代码，你能看出是哪里的问题吗？
enum TabTag: Int {
case home = 0, worry, game, user
}
@available(iOS 17, *)
@Observable
class Model {
var currentSelectingTab = 0
}
@available(iOS 17.0, *)
struct Main: View {
@State var model = Model()
var body: some View {
NavigationStack {
TabView(selection: $model.currentSelectingTab) {
Text("Home")
.tabItem {
Label("Home", systemImage: "house")
}
.tag(TabTag.home)
Text("Worry")
.tabItem {
Label("Worry", systemImage: "figure.fall")
}
.tag(TabTag.worry)
Text("Game")
.tabItem {
Label("游戏", systemImage: "gamecontroller.fill")
}
.tag(TabTag.game)
Text("User")
.tabItem {
Label("用户", systemImage: "person.fill")
}
.tag(TabTag.user)
}
.navigationTitle("SwiftUI 初学者常见错误")
}
}
}
其实原因很简单：问题就出在 TabView 中每个标签页的 tag 类型上。我们实际使用的是 TabTag 类型，但是向 TabView 构造器 selection 形参绑定的却是整形类型。
所以这个问题解决起来也很容易，只需要将 Model 中对应的属性改为 TabTag 类型即可：
@available(iOS 17, *)
@Observable
class Model {
var currentSelectingTab = TabTag.home
}
再次运行代码一切都回归正常了。
但是故事到这里并没有结束。假如我们将代码修改为如下形式，却是能够选择 TabView 中每个标签页的：
struct Main: View {
@State var currentSelectingTab = 0
var body: some View {
NavigationStack {
TabView(selection: $currentSelectingTab) {
Text("Home")
.tabItem {
Label("Home", systemImage: "house")
}
.tag(TabTag.home)
Text("Worry")
.tabItem {
Label("Worry", systemImage: "figure.fall")
}
.tag(TabTag.worry)
Text("Game")
.tabItem {
Label("游戏", systemImage: "gamecontroller.fill")
}
.tag(TabTag.game)
Text("User")
.tabItem {
Label("用户", systemImage: "person.fill")
}
.tag(TabTag.user)
}
}
}
}
在上面的代码中，我们仅仅将原来在 Model 中 Int 类型的 currentSelectingTab 直接放到视图 @State 中，并将其与 TabView 的选中操作绑定起来而已。但是这样的话，同样造成了 TabView 标签页 tag 类型的不一致，为何又没有问题呢？
其实，这波“走位”表面看起来貌似可以恣意切换 TabView 各个标签页，但实际却是有问题的。为了拨开迷雾见青天，我们特地为 currentSelectingTab 状态增加了 onChange 监听器：
struct Main: View {
@State var currentSelectingTab = 0
var body: some View {
NavigationStack {
TabView(selection: $currentSelectingTab) {
//...
}
}
.onChange(of: currentSelectingTab) {_,new in
// 永远不会进入此闭包中
print("\(new)")
}
}
}
运行代码可以发现：尽管我们可以切换到不同标签页中，但我们的 currentSelectingTab 状态却从未发生过改变！
所以，最终我们发现了 SwiftUI 中一个“不一致”的场景：在 @Observable 对象中属性类型和 TabView 标签页 tag 不匹配会导致“正确”的交互行为（标签页无法切换），但在 @State 同样的属性却不能。
希望苹果在将来可以将它们一致化。
2. 视图中 @FetchRequest 定义不完整导致的崩溃
另一个隐蔽的问题涉及到 CoreData 为 SwiftUI 视图添加的 @FetchRequest 属性包装器。
@available(iOS 17, *)
struct WorriesView: View {
@FetchRequest(sortDescriptors: [.init(keyPath: \Worry.occurrenceTime, ascending: false)]) var worries
var body: some View {
NavigationStack {
List {
Section("最近担忧") {}
Section("严重担忧") {}
Section("其它担忧") {}
}
.navigationTitle("担忧终结者")
}
}
}
上面的代码貌似人畜无害，而且在 Xcode 预览中的显示也是无懈可击：
不过，如果我们编译并胆敢在模拟器或真机上运行上述代码，App 就会立即崩溃:
而且从提示来看，很难发现究竟是哪里出了问题。如果不是我们已将问题局限在 @FetchRequest 那行代码上，大家恐怕很难轻易找出罪魁祸首，更何况如果它匿影藏形隐身在海量视图中了。
经常在 SwiftUI 中使用 @FetchRequest 属性修饰器来获取 CoreData 数据的小伙伴们，应该能一眼看出上面代码中的问题，实际上它缺少了 FetchedResults 后半部分的定义，是不完整的：
@FetchRequest(sortDescriptors:
[.init(keyPath: \V3_Worry.occurrenceTime, ascending: false)])
var worries: FetchedResults<V3_Worry>
只要将其补全即可。
该问题的另一个特点是它在 Xcode 预览中讳莫如深、深藏不露，只为在实际运行时给秃头码农们“当头一棒”，实属可恨！
不过，通过上面条分缕析的介绍，现在小伙伴们对它们一定能够火眼金睛、无所畏惧，棒棒哒！💯
更多 Xcode 预览调试中的技巧和陷阱，请小伙伴们移步如下链接观赏精彩的内容：
- Xcode编写SwiftUI代码时一个编译通过但导致预览(Preview)崩溃的小陷阱
- Xcode如何在预览(Preview)调试中避免与SwiftUI正常运行时环境不一致导致的崩溃
- Xcode预览(Preview)显示List视图内容的一个Bug及解决
- Xcode 15 预览 SwiftUI 视图中 @FetchRequest 查询结果不能正确刷新的解决
总结
在本篇博文中，我们讨论了 Xcode 16.1（iOS 18.1）中仍然存在 SwiftUI 的两个“鸱张鼠伏”、较难发现缘由小问题的“症状”和解决之道，希望可以帮助到大家。
感谢观赏，再会啦！😎
