译自 Random Lessons from the SwiftUI Digital Lounge
建议横屏阅读代码
本文接 《漫步SwiftUI数字长廊(上)》继续原文翻译
封面来自 Karolina Kolacz on Unsplash
并发
refreshable 是否是 SwiftUI 中唯一支持异步代码的属性呢?♦️
task
modifier 也提供了开箱即用的异步代码支持。通常来说,我们只有在能为开发者提供附加的实用工具时才会将你们提供的闭包放进异步环境中执行,比如在 task
附着的视图生命周期结束时取消 task
,或者结束刷新动画。当然,如果你希望在别的地方也能把代码分发到异步环境中执行,可以使用 async
代码块!
Swift并发可以向后发布吗?♦️ ⭐️
目前为止你可以认为 Swift 并发无法向后发布,不过开发团队理解这是一个很受欢迎的需求,正在评审。
有趣的部分在于 Swift 是开源的,你可以访问 forums.swift.org 来查看 Swift 并发的开发进度,他们会对这个话题进行讨论。
数据管理
@StateObject 和 ObservedObject 该怎么选?
**原问题:**假设我们有一个纯 SwiftUI 的数据流。我有一个 List
视图,它拥有一个 @StateObject var listFetcher
属性,这个属性会请求列表项。点击一个列表项会导航到详情视图 DetailView
,这个详情视图有一个 detailFetcher
的 ObservableObject
属性,它会请求列表项的详情。那么,以什么样的方式组织 DetailView
更好呢?detailFetcher
属性应该采用哪个属性包装器?
-
提供一个
init(itemID: Int)
构造器,然后使用@StateObject
这种方式。这样最终会要求我们在body
的onAppear
里执行类似detailFetcher.itemID = itemID
这样的更新操作。 -
把
detailFetcher
传入构造器,比如init(detailFetcher: ObservableObject)
并且将属性标记为@ObservedObject
。如果采取这种方式,那么这个detailFetcher
应当存放在哪里?
**答复:**通常情况下,我们在视图拥有关联对象时使用 @StateObject
,比如对象是在视图被创建的时候创建,且需要跟随视图销毁而销毁。对应的,在视图需要引用其他视图或者别的东西拥有的对象时使用 @ObservedObject
。这时视图虽然依赖该对象,但两者的生命周期不绑定。
例如,你可以在应用的主屏幕使用 @StateObject
来初始化 app 的 model,然后用 @ObservedObject
把 model 传给详情界面。建议看一看 “解密 SwiftUI” 以了解更多这方面的内容。
@SceneStorage 的存储时机可以自己控制吗?
**原问题:**有没有办法控制 @SceneStorage
的存储时机呢?我的应用里这个存储大部分都是在根视图,它们似乎只有在应用进入后台时才会被保存,而不是进入后台之前。
**答复:**我们没有提供控制 场景存储时机的 API,因为我们的本意就是让它们在后台保存,在应用回到前台或者场景重建时恢复。
@State 和 @StateObject 通常是不是都应该定义成 private ?
是的!将它们标记为 private
可以明确状态是属于该视图及其子孙视图的。
当视图的 identity 发生改变时,采用 @State,@StateObject 和 @ObservedObject 有没有一些关键性的区别?
是的,ObservedObject
不包含任何生命周期的暗示 —— 当你使用这个属性包装器时,你需要自行负责管理对象的生命周期。这个对象可能存在于任何地方 —— 比如来自某个 StateObject
或者 app 里的另一个数据结构。
在根视图中以单个 @StateObject 保持整个应用的状态有哪些坏处?⭐️
原问题: 我有一个 class Store<State, Action>: ObservableObject
,它持有整个 app 的状态,作为 @StateObject
在整个 App 的生命周期内存在,并且以环境对象的方式传递给所有视图。视图发送 action 给这个 store,并根据 store 的状态来更新自己。这种做法让我可以保持 app 状态的一致性。你能说一说这种做法的坏处吗?
答复: 这种做法会使得应用中的所有视图都依赖单一的 Observable
对象。任何一个 Published
属性变化都会强制引用该环境对象的视图刷新。
**追加的问题:**那么你的建议是什么呢?假设我们有多个视图都依赖相同的数据,并且需要保持视图之间状态的一致性?
**答复:**对不起,架构问题是依赖具体上下文的,没有放之四海而皆准的策略。收敛你的模型是一种方法,把状态以绑定的方式传递给子组件也是一种方法。
@State/@Binding 相比 @EnvironmentObject 有什么区别?
**原问题:**把 State
以绑定的形式传递给层级中的每个视图和以环境对象的方式注入,并在需要用到的子视图中访问它们,这两种方式有什么区别?会不会有一者的 dependency graph 比另一者更糟糕的情况?
**答复:**环境对象与 State
相比稍有不同,因为它必须是 ObservableObject
。我们对环境对象做了优化,只会触发实际读取它的视图的更新。
至于 State
,当你以绑定的形式传递给子视图时,改变绑定将会反过来改变状态,从而刷新所有持有该状态的视图及其子视图。
出于性能考虑,我们应该如何取舍 ObservableObject 和 @EnvironmentObject?
**原问题:**从性能角度考虑,我们应该优先使用显式传递 ObservableObject
到子视图的方式还是使用 EnvironmentObject
?
**答复:**这两种方式对于任何给定视图都没有大的区别。不过假如你在某些中间层级的视图中并不需要使用目标对象 ,那么 EnvironmentObject
是一种减少样板代码的绝佳方式,而且可以避免创建偶然的依赖。
可以使用 Core Data 的子上下文作为 @StateObject 吗?
**原问题:**可以使用 CoreData 的子上下文作为 SwiftUI 视图的 @StateObject
变量吗?或者你会建议我以环境对象的方式传递它们,还是在 SwiftUI 之外保存它们?
**答复:**没有使用 @StateObject
的必要,而且上下文也不是 ObservableObject
。通过 environment
向下传递是一个好选择。
“view environmentObject may be missing as an ancestor of this view? ”这个错误是怎么回事呢?
**原问题:**在使用 @EnvironmentObject
时,貌似我需要给所有层级的子视图传入 .environmentObject
modifier。假如我不这么做,编译器就会抛出 “view environmentObject may be missing as an ancestor of this view” 的错误。但我以为 EnvironmentObject
的作用不就是让数据可以不用写很多代码就能让所有的视图使用吗?这是一个设计上的选择还是我的打开方式有误?
**答复:**感谢提出这个问题。多数情况下,.environmentObject(…)
是能够顺着视图层级往下传递的,但是有一些情况我们是有意地不传递环境对象。例如,一个 NavigationLink
的目标视图不会得到环境对象,因为这里面存在一个冲突:对象是该由发起链接的地方传入呢?还是目标视图的占位符传入,又或者是导航栈里的前一个视图传入?
Sheet 和 Popover 因为 bug 的关系也无法得到环境对象,不过这个问题已经被修复了(iOS 15)。
假如你有发现其他地方环境对象没有被传递的情况,请给我们发送反馈,这对于我们修复这个功能很重要。
我可以直接调用 @StateObject 的构造器吗?⭐️
**原问题:**当需要注入数据给一个详情视图,且要让该视图拥有这个数据的 StateObject
时,我直接使用了 StateObject(wrappedValue:)
构造器,就像这样:
public struct PlanDetailsView: View {
@StateObject var model: PlanDetailsModel
public init(plan: Plan) {
self._model = StateObject(wrappedValue: PlanDetailsModel(plan: plan))
}
}
复制代码
这种使用构造器的方式是可以接受的吗?据我所知 StateObject
本应该在视图生命周期开始的时候被初始化,而不是放在 View
值的实例化中。我想要确认我的这种写法有没有迫使对象的存储在 View
重新实例化时被再次分配内存。
**答复:**是的,构造器的这种用法是可以的。你的理解没错:对象会在视图生命周期开始时被创建并且保持。 StateObject
的包装值是一个自动闭包,它只会在视图生命周期开始被调用一次。这也意味着 SwiftUI 会在 plan
第一次创建时捕获它的值。值得注意的是,假如你的视图 identity 没有变化,但传了一个不同的 plan
,SwiftUI 不会注意到这个变化。
**追加的问题:**我能建议文档更新一下以体现这一点吗? StateObject.init(wrappedValue:)
文档的描述现在是这样的:
你不需要直接调用这个构造器, 而应该在
View
,App
或者Scene
中声明一个@StateObject
属性,并提供初始值。
**答复:**谢谢你的反馈。如果你还发现任何我们可以改进文档的地方,欢迎提交反馈给我们。
可以往已有的属性包装器(比如 State, ObservedObject )中嵌入自定义的属性包装器吗?⭐️
**原问题:**假如我们的自定义属性化字符串嵌入了已有的属性包装器,比如 State, ObservedObject,SwiftUI 能够“看见”这些嵌入的属性包装器并且正确工作吗? 比如,我创建了一个 @Whatever
包装器作为 @Environment(\.whatever)
的快捷方式,那么它能像后者一样运行吗?
**答复 (工程师 #1):**可以,前提是你的包装器遵循了 DynamicProperty
协议。
**追加的问题:**我也需实现 update()
是吗,还是它的默认实现就足够了?
**答复 (工程师 #1):**不要求实现 update()
。
**追加的问题:**在给我的自定义属性包装器实现 DynamicProperty
时,只有那些 SwiftUI 的属性包装器(State
, ObservedObject
)会触发 SwiftUI 视图的更新,对吧?
**答复 (工程师 #2):**或者是任何其他的 DynamicProperty
。 State
, ObservedObject
都实现了 DynamicProperty
协议。
**追加的问题:**哦,我明白了。所以我没办法自己实现 DynamicProperty
。
**答复 (工程师 #2):**正解,你的 DynamicProperty
需要基于已有的 DynamicProperties
实现。
@State 变量可以在主线程之外更改吗?
原问题: State
的文档上说 “It is safe to mutate state properties from any thread.” 那为什么在非主线程发布 SwiftUI 会发布 PassthroughSubject
会收到运行时警告呢?
答复: State
是线程安全的,可以在任何线程修改。至于 PassthroughSubject
,我假设你是在 @StateObject
, @ObserverdObject
, 或者 @EnvironmentObject
上下文使用的 ObservableObject
。ObservableObject
的确要求其属性在主线程修改。 我建议你查阅我的同事 Curt 和 Jessica 在 Discover Concurrency in SwiftUI session 中对于 Swift 并发的讨论。
**追加的问题:**我是用 onReceive
和 CurrentValueSubject
在一个 modifier 里设置一个 State
,所以我应该报告一个反馈给你们吗?
**答复:**我明白了。 目前 onReceive
也是期望你在主线程发布变化。
一般来说,在主线程通知或者更改与 UI 交互的代码能帮你避免很多麻烦。
假如一个 @ObservedObject 被传入视图,但视图并未使用它的值,@ObservedObject 变化时视图会刷新吗?⭐️ 💬
**原问题:**当一个 ObservedObject
对象被传入一个视图时,SwiftUI 会区分实际使用它的视图(body 里用到)和“中间视图”(只是为了把视图传递给子孙)吗?还是所有的视图都会被更新?
**答复:**是的,两者是有区别的。如果你没有使用 ObservableObject
的属性包装器 (指 @StateObject
, @ObservedObject
) ,那么视图不会观察和更新。假如你只是需要在中间视图传递 ObservableObject
,可以使用常规属性。反之如果你的视图读取了其中的任何值,则应当使用属性包装器,否则视图可能与数据状态不一致。
另外, @EnvironmetObject
可以用来取代人工传递 ObservableObject
的好工具。
为了明确说明,我用下面的代码演示 IntermediaryA 是如何做了不必要的 body 计算,而 IntermediaryB 没有这个问题:
class Model: ObservableObject {
@Published var flag = false
}
struct ExampleView: View {
@StateObject var model = Model()
var body: some View {
HStack(spacing: 20) {
Button("Toggle") {
model.flag.toggle()
}
IntermediaryA(model: model)
IntermediaryB(model: model)
}
}
}
struct IntermediaryA: View {
@ObservedObject var model: Model
var body: some View {
print("IntermediaryA body computed!")
return Flag(model: model)
}
}
struct IntermediaryB: View {
var model: Model
var body: some View {
print("IntermediaryB body computed!")
return Flag(model: model)
}
}
struct Flag: View {
@ObservedObject var model: Model
var body: some View {
Image(systemName: model.flag ? "flag.fill" : "flag.slash.fill")
.font(.largeTitle)
}
}
复制代码
好在这正是 EnvironmentObject
发挥作用的场景,它能极大地简化代码。 Intermediary
和 Flag
不再需要构造器里的参数。
class Model: ObservableObject {
@Published var flag = false
}
struct ExampleView: View {
@StateObject var model = Model()
var body: some View {
HStack(spacing: 20) {
Button("Toggle") {
model.flag.toggle()
}
Intermediary()
.environmentObject(model)
}
}
}
struct Intermediary: View {
var body: some View {
print("Intermediary body computed!")
return Flag()
}
}
struct Flag: View {
@EnvironmentObject var model: Model
var body: some View {
Image(systemName: model.flag ? "flag.fill" : "flag.slash.fill")
.font(.largeTitle)
}
}
复制代码
为什么在 sheet 里我的 @EnvironmentObject 会得到 nil ?⭐️
**原问题:**我遇到过几次环境对象为 nil
的情况,发生在我把它们传给一个 sheet 或者 NavigationLink
的场景。因为复现有点难,并且偶然出现,我通常解决这个问题的办法是重新组织我的代码,避免传递环境对象。你知道为什么会这样吗?我怀疑 environmentObject
的内存在视图层级传递过程中被销毁了。希望你能提供帮助!
答复 (工程师 #1):NavigationLink
是设计上有意不传递 EnvironmentObjects
。因为 environmentObject
的继承关系在这里无法明确。我怀疑这是导致你的问题的原因。为了得到预期的结果,你需要显式地传入 environmentObject
。
**答复 (工程师 #2):**你也可以把 environmentObject
应用到 NavigationView
本身,那么能够让环境对象对所有推入(导航栈)的内容可用。
我需要支持 iOS 13,但我又需要 @StateObject,我该怎么做?
**原问题:**为了支持 iOS 13, 我在模型中用的是 @ObservedObject
,但我知道 @StateObject
的行为才是我要的。有没有建议的方法可以实现向后兼容。我原以为 if #available
可能可以工作,但它不能用于属性。
**答复:**为了支持 OS 13,你需要使用 @ObservedObject
,并以某种别的方式保持对象,比如使用静态属性或者在应用委托中持有引用。
我不认为在 ObservedObject
和 @StateObject
之间切换会给你的场景带来好处,因为通过可用性检查改变对象的所有者的做法不合适。
@EnvironmentObject 和 @ObservedObject 哪个更好?
**原问题:**通常情况下,在视图里用 EnvironmentObject
更好还是用传递的 ObservedObject
更好?
**答复:**两种用法都有用户,这取决于你的代码架构。如果你有一个或者很少的大型 ObservableObjects
,大部分视图层级都需要看到它,我通常建议用 EnvironmentObject
,因为 SwiftUI 会帮你照顾到所有实际使用该对象的视图。 当然,用 ObservedObject
也能做到,只是相对笨重。前者也不会因为视图没有实际使用对象而让代码变得凌乱。
也就是说,如果你的模型很大程度上不是基于你的视图层级构建的对象图,那么在视图中使用 ObservedObject
抓取自己需要的那部分可能会更合理。
调试
如何调试 AttributeGraph 崩溃?⭐️
**原问题:**有没有方法可以调试 AttributeGraph 的崩溃?我遇到 AttributeGraph precondition failure: "setting value during update": 696.
这样的错误,可能是哪里的某个 hosting controller,但我不知道如何追踪。
**答复:**这个错误说明某个 body
或者 updateUIViewController
(or NS…
) 里的代码正在修改状态。
我们在新的 SDK 里提供了一个新的调试工具,可以帮助你缩小排查的范围。
在 body
里,如果你写了 Self._printChanges()
, SwiftUI 会把导致视图重绘的属性名称通过日志的形式输出到调试区域。(注意下划线。这不是一个 API,只是暴露给调试用的。)
如何对 SwiftUI 代码做性能调优? ⭐️
**原问题:**我要如何对 SwiftUI 代码做性能调优,比如知道如何优化我的视图。Instruments 显示的几乎都是 SwiftUI 库的代码,要看清哪部分渲染开销昂贵很困难...
**答复:**SwiftUI instrument 可以帮助唤出比较重的 body 方法。同时,限制每个视图 body 被重新计算的次数也很重要。强烈建议你去观看 解密 SwiftUI,深入了解这其中的工作方式。
提示: 在 body
里调用新的 Self._printChanges()
工具,可以打印导致视图重新计算的属性。
技术上它并不是一个 API —— 它有一个下划线,所以只能用于调试。
绘制
SwiftUI 中有没有可以设置视图中单个像素的高效方法?♦️
**原问题:**SwiftUI 中没有可以设置视图中单个像素的高效方法?抱歉我还没来得及去查看新的 Canvas
API,在 UIKit 里我也不知道该怎么做到这件事,包括在 metal 视图里编写一个自定义的 fragment shader。谢谢!
答复:Canvas
是这个问题的最佳解决方案。你可以填充任意的 1像素 x 1像素的矩形,而这是 SwiftUI 里最高效的表达方式。
要拿到一个像素的大小,你需要从 Canvas
的 GraphicsContent
环境中请求 pixelLength
。
SwiftUI 中有没有可以禁用像素取整的方法?
**原问题:**有没有办法能够禁用 SwiftUI 中的像素取整。我的 macOS Dock 的悬停效果昨天出现了抖动,是因为很多视图应用了留白,但都被取整到最近的像素。留白的误差累积之后,每当我移动鼠标就会导致整个视图抖动。
答复: SwiftUI 布局总是取整到最近的像素。但使用任意 GeometryEffect
则不会继承吸附行为。像 .offset
和 .scaleEffect
是现成的实现这个行为的 API,不过如果有需要你也可以实现你自己的 GeometryEffect
。
从性能的角度,新的 Canvas 视图能做到什么程度? ♦️ ⭐️
原问题: Canvas
看起来是个很赞的新增。我想知道用它来在一个 ScrollView
里实现一个视图,支持拖拽,放大等等。从性能的角度来说是一种合理的解决方案吗?优化性能是否有一些指引。我想要把很多图像以及矢量数据放进去。
**答复:**听起来是一个非常适用 Canvas
的应用。像任何其他东西一样,性能取决于你优化的程度和运行的硬件。我恐怕不能给出可以实操的答案,因为每个应用都不一样。
关于
Canvas
的更多信息,可以参考 Add rich graphics to your SwiftUI app
Canvas 在 TimelineView 里的行为♦️ ⭐️
**原问题:**我的问题和 Canvas
有关。这个视图很棒,它为艺术创作和生成打开许多可能性。我想知道如果在 Timeline
里封装一个 Canvas
,接收来自绑定的数据流。在渲染期间,它的调度时间信息会跟随 body 的变化而更新吗?,
**答复:**只要 timeline 的 identity 是一样的,那么调度的值就不会随着 body 更新而变化,它不会触发其中的 Canvas
的更新。如果画布本身的内容改变了,你会看到基于当前调度时间实体的又一次更新 TimelineView
。
焦点
现在实现程序化设置焦点吗?♦️
原问题: SwiftUI 今年支持程序化改变焦点吗?比如,键盘底部有一个“下一步”按钮,点击可以切换焦点到下一个文本框?
**答复 (工程师 #1):**可以看一看新的 focus API
答复 (工程师 #2): @FocusState
不只可以用于 Textfield
,你可以用 FocusState
来切换数字表冠,在 tvOS 上可以控制遥控器。
**答复 (工程师 #3):**也可以看看 What’s New in SwiftUI 和 Direct and reflect focus in SwiftUI
FocusState 为什么不支持初始值呢?♦️ ⭐️
**原问题:**我注意到 @FocusState
不支持初始值,你设置在 onAppear
里设置焦点,这是有原因的吗?
**答复:**一种看待焦点的方式是把它看作由框架管理的一个全局状态。多数时间里,通过选择文本框等动作,用户会掌控这个状态。新的 @FocusState
和 focused(_:)
API 允许我们干预这个状态。但最终这个状态的数据源是 SwiftUI 内部。这个答案能够解开你的疑惑吗?
我倾向于把 @FocusState
看成一个由框架管理的状态的客户端视图。
导入/导出
importsItemProviders 可以支持导入其他命令或者别的东西吗?♦️
它对所有分发数据的 macOS 系统服务都起作用。所以如果你有一个服务或者快捷方式不接收输入,但是会产生输出 —— 那么你的 app 的 importsItemProviders
可以在用户调起这个服务时消费这些数据。
importsFromDevices 可以作为 AsyncImage 的数据源吗?(比如连续相机)♦️
不行,连续相机会以一个输出完整图像数据而非 URL 的 item provider 回调你的 importsItemProviders
。不过假如你有可以很好的结合两者的用例,欢迎反馈。
布局
Canvas 的布局和尺寸行为是怎么样的? ♦️
Canvas
会消费掉提供给它的空间。你也可以根据需求用 .frame
来控制尺寸。
为了避免影响布局,把 GeometryReader 放进一个透明的 overlay 这种做法可取吗?⭐️ 💬
**原问题:**我看到不少在透明的 overlay 里使用 GeometryReader
的例子,这样做是为了避免影响布局... 这个做法可取吗?看起来并不是这个 API 的原本设计的用法。
**答复:**通常我们会把这个用法看作是对该 API 的误用。假如你有某些需要这么做的场景,欢迎给我们反馈!
我特别喜欢这个问题。许多人都说过尽管方案很丑,但那是唯一的解决方案,我也同意这一点。为了证明这是一个不好的模式,请往下阅读后面的问题,它们都跟这个主题有关。
我鼓励大家在遇到只有这种办法才能行得通的用例时报告反馈给苹果。只有这样问题才会得到解决。
怎么获取另一个视图的尺寸?⭐️ 💬
**原问题:**有没有办法从另外一个视图获取 GeometryReader 的尺寸。我想把下面的 “???” 文本的高度换成 “Hello world!” 文本的高度。
struct ContentView: View {
var body: some View {
VStack {
Text("Hello world!")
.background(
GeometryReader { proxy in
Color.clear /// placeholder
let _ = print(proxy.size.height) /// 20.333333333333332
}
)
Text("Height of first text is ???")
}
}
}
复制代码
答复: 你好! 把 GeometryReader
放在视图的背景里可以确保 GeometryReader
不会超出其所包含的视图尺寸,但是提取它的尺寸需要一点小技巧。你可以像这样做:
struct ContentView: View {
@State private var height = 100.0
var body: some View {
MyView().background {
GeometryReader { proxy in
Color.clear
.onAppear {
height = proxy.size.height
}
.onChange(of: proxy.size.height) {
height = $0
}
}
}
}
}
复制代码
然后你就能想往常一样使用 State
属性。
⚠️ 注意:你必须确保你不会因此导致一个连续的布局循环。如果因为你的布局响应了 height
变化而导致 GeometryReader
再次布局,你将陷入一个无限循环。
我认为只要你注意这个 ⚠️ ,你就可以使用这个技术。我想说的是,尽管这个模式已经常见,我们乐于收到反馈,以便提供 SwiftUI 的体验 —— 在反馈中解释你的场景,这能帮助开发团队理解你要做的事情!
关于这项技术,有几种选项(参考前面的一个问题),我重写了问题的例子,以适应 Apple 给出的答复:
struct ExampleView: View {
@State private var height = 100.0
var body: some View {
VStack {
Text("Hello world!")
.background(
GeometryReader { proxy in
Color.clear
.onAppear {
height = proxy.size.height
}
.onChange(of: proxy.size.height) {
height = $0
}
})
}
Text("Height of first text is \(height)")
}
}
复制代码
Dependency Graph 可不可以包含循环?
Graph 循环是不允许的。
把视图容器从 HStack 切换成 VStack 时,要怎么保持视图的等价性呢?⭐️ 💬
**原问题:**有没有办法在切换 HStack
和 VStack
的同时让 SwiftUI 知道两个 stack 里的内容是相同的?
**答复:**和这个问题类似的问题有很多,重复之前的答案:是的!你可以试试 matchedGeometryEffect()
API,去年引入的,文档在 这里.
frame() 和 Spacer() 要怎么选?⭐️ 💬
**原问题:**在大多数场景下, Spacer
的布局行为可以用 .frame(maxWidth:alignment:)
(或者 height) 无缝替换。因为 Spacer
是一个实际的视图,参与视图层级的布局,使用 Spacer
会消耗更多的内存和 CPU 资源 “解密 SwiftUI” 也提到 “modifier is cheap”。所以我是不是应该尽可能地用 .frame
代替 Spacer
?
答复 (工程师 #1):尽管 Spacer
是一个视图,但它最终并不显示任何东西,所以其本身非常轻量。 使用 .frame
会引入其他行为导致视图改变尺寸。两者都有使用场景,所以请在各自合适的场景下选用。
答复 (工程师 #2):稍微补充一点,尽管你可以用两种方式取得几乎一致的效果,但因为性能的差异微乎其微,我会强烈建议在决策时把代码可读性放在性能/内存占用之前。
假如 Spacer
使你的布局意图更清晰,那么就用它,反之亦然。
为了演示
frame
和Spacer
表现不同的场景,请看下面的代码。因为在HStack
容器的间距参数在未指定时, SwiftUI 会采用自动留白,这时Spacer
和.frame
的处理方式就是不一样的。虽然两个HStack
视图的输出看起非常相似,但并不是相等的。
struct ExampleView: View {
var body: some View {
VStack {
HStack {
Spacer()
Circle().frame(width: 50, height: 50)
Spacer()
Circle().frame(width: 50, height: 50)
}
.border(Color.blue)
HStack {
Color.clear.frame(maxWidth: .infinity, maxHeight: 0)
Circle().frame(width: 50, height: 50)
Color.clear.frame(maxWidth: .infinity, maxHeight: 0)
Circle().frame(width: 50, height: 50)
}
.border(Color.blue)
}
}
}
复制代码
不过通过指定 HStack
的间距可以让两个 HStack
生成相同的结果。
“Bound preference SizePreferenceKey tried to update multiple times per frame” 这是什么错误?
原问题: 如何避免出现 Bound preference SizePreferenceKey tried to update multiple times per frame
? 这个错误?
看起来你遇到循环更新的问题。举个例子,一个 GeometryReader
对一个属性写入,会导致包含它的视图重绘,这又会导致 GeometryReader
再次写入属性。
应当避免创建这类循环。通常我们可以通过把 GeometryReader
移到更外层的视图,以便其尺寸不发生变化来解决这个问题。
不过没有看到你的代码,我恐怕不能再给出更具体的建议,希望对你解决这个问题有帮助。
更多内容欢迎关注公众号「Swift花园」