首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么即使发布者发出一个值,我的视图也不会以SwiftUI呈现

在SwiftUI中,视图的呈现是通过绑定数据来实现的。当数据发生变化时,视图会自动更新以反映最新的值。然而,有时候我们可能会遇到一个情况,即使发布者发出一个新的值,视图仍然不会更新。

这可能是由于以下几个原因导致的:

  1. 数据绑定错误:首先,我们需要确保将发布者与视图正确地绑定。在SwiftUI中,我们可以使用@State@ObservedObject@EnvironmentObject等属性包装器来创建绑定。如果绑定不正确,视图将无法接收到新的值。
  2. 发布者未正确发送新值:如果发布者没有正确地发送新值,视图将无法更新。我们需要确保在数据发生变化时,发布者使用正确的方法发送新值,例如使用objectWillChange.send()来发送通知。
  3. 视图层次结构问题:如果视图的层次结构不正确,可能会导致视图无法更新。在SwiftUI中,视图的层次结构应该正确地反映数据的层次结构。如果视图的层次结构不正确,可能会导致视图无法正确响应数据的变化。
  4. 数据更新频率问题:有时候,数据更新的频率可能非常高,导致视图无法及时更新。在这种情况下,我们可以考虑使用@Published属性包装器来限制数据更新的频率,或者使用debounce操作符来延迟数据更新。

综上所述,如果发布者发出一个新的值,但视图不会以SwiftUI呈现,我们应该检查数据绑定是否正确,确保发布者正确发送新值,检查视图层次结构是否正确,以及考虑数据更新频率是否过高。如果问题仍然存在,可能需要进一步调试和排查。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

SwiftUI-数据流

数据处理基本原则 Data Access as a Dependency:在 SwiftUI 中数据一旦被使用就会成为视图依赖,也就是说当数据发生变化了,视图展示会跟随变化,不会像 MVC 模式下那样要不停同步数据和视图之间状态变化...UI刷新,所以很适合类型,因为对类型里面属性更新,会触发整个类型重新设置。...不过类型在传递时会发生复制操作,所以给传递后类型即使属性更新了不会触发最初传过来类型重新赋值,所以界面并不会刷新,此时需要用@Binding,因为它可以将类型转为引用类型,这样在传递时...,其实是一个引用,任何一方修改属性都会触发类型重新设置,UI界面随之更新。...最终再次呈现给用户,等待下次界面操作 注意 在 SwiftUI 中,开发者只需要构建一个视图可依赖数据源,保持数据单向有序流转即可,其他数据和视图状态同步问题 SwiftUI 帮你管理,所以 ViewController

10K20

为什么SwiftUI视图使用结构体?

在UIKit中,每个视图都来自一个名为UIView类,该类具有许多属性和方法:背景色,确定其放置方式约束,用于将其内容呈现到其中图层等等。...在UIKit中,UIStackView是一种非渲染视图类型,旨在简化布局,但这意味着即使它因为继承原因具有背景色,​​从未真正使用过。...在SwiftUI中,我们所有的视图都是简单结构体,几乎可以自由创建。想想看:如果您制作一个仅包含一个整数结构体,则结构体整个大小就是:一个整数。没有其他。...得益于现代iPhone强大功能,不会慎重考虑后创建1000个整数甚至100,000个整数——眨眼之间就会发生。1000个SwiftUI视图甚至100,000个SwiftUI视图也是如此。...通过生成不会随时间变化视图SwiftUI鼓励我们转向更具功能性设计方法:在将数据转换为UI时,我们视图变成简单,惰性东西,而不是会失去控制智能化东西。

3.1K10

SwiftUI 视图生命周期研究

SwiftUI 内部它会至少创建两种类型树——类型树、视图树 类型树 开发者通过创建符合 View 协议结构体定义想要呈现用户界面,结构体 body 属性是一个带有众多泛型参数庞大类型,...•在生成新视图树时,即使已经有可以对应实例(该实例并未销毁),SwiftUI 仍可能会创建一个实例。...这种情况可能是 SwiftUI 将第一个实例销毁后创建了一个实例,可能是没有销毁第一个实例而直接创建了一个实例。...除了必要参数设置外,不要做任何多余操作。这样即使 SwiftUI 创建了多余实例,不会加大系统负担。 注册数据依赖 在 SwiftUI 中,状态(或者说是数据)是驱动 UI 动力。...比如,在下面的几个场景中,onAppear 和 onDisappear 都将违背大多数认知: •在 ZStack 中,即使视图不显示,同样会触发 onAppear,即使消失(不显示),不会触发 onDisappear

4.3K30

为什么 SwiftUI 视图使用结构体

在 UIKit 中,每个视图都来自一个名为UIView类,该类具有许多属性和方法:背景色,确定其放置方式约束,用于将其内容呈现到其中图层等等。...在 UIKit 中,UIStackView 是一种非渲染视图类型,旨在简化布局,但这意味着即使它因为继承原因具有背景色,从未真正使用过。...在 SwiftUI 中,我们所有的视图都是简单结构体,几乎可以自由创建。想想看:如果您制作一个仅包含一个整数结构体,则结构体整个大小就是:一个整数。没有其他。...得益于现代 iPhone 强大功能,不会慎重考虑后创建 1000 个整数甚至 100,000 个整数——眨眼之间就会发生。...通过生成不会随时间变化视图SwiftUI 鼓励我们转向更具功能性设计方法:在将数据转换为 UI 时,我们视图变成简单,惰性东西,而不是会失去控制智能化东西。

2.4K50

一段因 @State 注入机制所产生“灵异代码”

这意味着,即使我们在定义视图结构体中声明了使用 @State 标注变量,但只要 body 中没有使用该属性( 通过 ViewBuilder 支持语法 ),即使该属性发生变化,视图不会刷新。...,在 Text 中不包含 n 情况下,即使 n 改变,StateTest 视图 body 不会重新计算。...dump(_n) }}Sheet 视图上下文当 SwiftUI 创建并显示一个 Sheet 视图时,并非在现有的视图树上创建分支,而是新建一棵独立视图树。...这意味着,相较于在原有视图树上创建分支,在新上下文中重建视图开销更大,需要进行工作更多。而 SwiftUI 为了优化效率,通常会对若干操作进行合并。...即使为新上下文中视图进行关联操作是在视图求值操作之前完成,但由于 n 变化与关联操作被集中在一个 Render Loop 中,这样会导致在关联之后并不会强制新关联视图刷新( 关联后,并没有发生变化

1.9K20

掌握 ViewThatFits

它只在检查阶段使用子视图理想尺寸进行判断,在最终呈现阶段,它将向子视图提交有建议尺寸,并使用子视图需求尺寸作为自身需求尺寸。...在 SwiftUI 中,我们可以通过 fixedSize 来强制一个视图理想尺寸进行呈现: struct IdealSizeDemo: View { var body: some View {...Rectangle().fill(.yellow) } .fixedSize() 对于这种视图,其“理想呈现”是一个复合状态: 宽度:VStack 将逐个询问子视图理想尺寸,使用其中宽度最大作为它需求尺寸...在这个示例中,尽管 ScrollView 在理想状态下,呈现宽度超过了 ViewThatFits 允许宽度,但由于它是最后一个视图,因此最终选择了它。这也是一个典型判断和呈现不一致情况。...,在判断子视图和最终呈现时采用不同建议尺寸模式,确保最终呈现视图始终能够充满 ViewThatFits 视图

15710

Ask Apple 2022 与 SwiftUI 有关问答(下)

快速检索数组元素Q:为什么没有简单方法将 TABLE 选择行映射到提供表内容数组元素上?似乎唯一方法是在数组中搜索匹配 id ,这对于大表来说似乎效率很低。...开发者即使无法实现这样布局容器,应对各种尺寸需求定义有清晰理解。在 SwiftUI 布局 —— 尺寸( 上 )[8] 一文中,对建议尺寸几种模式都进行了介绍。...创建从底部开始滚动视图Q:如何实现一个在底部对齐滚动视图,在 macOS 上会不会有糟糕性能?...这种 “软弃用” API 不会在代码自动补全中提供,而且通常处在文档中单独一个部分。但编译器不会对现有的使用发出警告。...但这个滚动有两大问题,1、是一个未公开半成品,有可能会被从 SwiftUI 框架中移除;2、不支持懒加载,即使和 Lazy 视图一起使用会一次性加载全部视图

14.7K30

为什么SwiftUI修饰符顺序很重要?

每当我们将修饰符应用于SwiftUI视图时,我们实际上都会创建一个应用了更改视图——我们不仅会修改现有的视图。...我们将在下一章中查看为什么会发生这种情况,但是首先,想看看这种行为实际含义。...如果思考一下修饰符工作原理,您就可以了解为什么会如此:每个修饰符都会创建一个应用了该修饰符新结构体,而不是在视图上设置属性。 您可以通过查询视图主体类型来窥视SwiftUI底层。...(width: 200, height: 200) .background(Color.red) 现在最好思考方法是,想象一下SwiftUI在每个修饰符之后都会呈现视图。...例如,SwiftUI为我们提供了padding()修饰符,该修饰符在视图周围添加了一些空间,从而不会将其推到其他视图或屏幕边缘。

2.3K10

SwiftUI 中布局工作原理

在幕后,SwiftUI 执行第四步:尽管它将位置和大小存储为浮点数,但在渲染时,SwiftUI 会将所有像素舍入到最接近,这样我们图形仍然清晰。...在 Project3 为什么 SwiftUI 修饰符顺序很重要?...“(父视图询问大小) ContentView:“不在乎;是布局中立。让问我孩子:嘿,背景,你可以使用整个屏幕——你需要多少?“(父父视图询问大小) 背景:“不在乎;布局也是中性。...ContentView:需要X * Y加上每边20个点。 SwiftUI:好把你放在中间。 如果你还记得为什么 SwiftUI 修饰符顺序很重要?。...希望现在您可以理解为什么:background() 是布局无关,所以它通过询问子对象需要多少空间并使用相同来确定需要多少空间。

3.7K20

GeometryReader :好东西还是坏东西?

一个容器视图,根据其自身大小和坐标空间定义其内容。 严格来讲,并不完全赞同上述描述。这并非因为存在事实上错误,而是这种表述可能会引起用户误解。...当前,GeometryReader 一个布局容器形式存在,其布局规则如下: 它是一个视图容器,其默认堆叠规则类似于 ZStack 将父视图建议尺寸( Proposed size )作为自身需求尺寸...这既保证了信息获取准确性(尺寸、位置与要获取视图完全一致),不会在视觉上造成额外影响。...请阅读 用 SwiftUI 方式进行布局[9] 和 在 SwiftUI 中实现视图居中若干种方法[10] 两篇文章,了解面对同一个需求,SwiftUI 有多种布局手段。...100 x 100,但在渲染阶段,经过scaleEffect处理,最终将呈现一个 220 x 220 矩形。

46270

SwiftUI geometryGroup() 指南:从原理到实践

然而在某些情况下,这种聚合行为可能会导致不希望结果;插入一个几何组可以纠正这种情况。几何组充当父视图与其子视图之间屏障,迫使位置和大小由父视图解析和动画化,然后再传递给每个子视图。...In Some Cases 为了更好地理解 geometryGroup() 实际作用,我们需要创建一个因父视图几何属性发生变化而导致非预期视图呈现,以便弄清楚文档中“在某些情况下”到底指的是什么情况...geometryGroup() 确保子视图在统一几何信息环境中,实现预期布局效果。它为子视图提供了一个连续几何信息更新过程。 总结上述条件后,我们就很容易创建出其它会导致意外行为代码。...,结果出现了非预期呈现。...这是 SwiftUI 开发团队在完成了基本布局功能后,腾出精力,进一步改善细节一个表现。同时,我们希望苹果能够在官方文档中能够提供更加清晰示例,提高开发者学习新 API 效率。

25210

解析 SwiftUI 中两处由状态更新滞后引发严重 Bug

而通过调用环境或直接修改绑定状态,SwiftUI 则遵循了响应式编程原则,进行了先调整状态,后更新视图操作。...运行下面的代码,点击左上方返回按钮,与 NavigationStack 绑定 path,直到视图返回上一层后,才会发生改变。通过环境返回上层视图同样需要等待视图返回后,才会修改状态。...当视图正在滚动时返回上一层视图会导致应用崩溃这是一个由 xiaogd 在 Discord 论坛中提出 问题。...因此,当我们首先更新状态,然后 SwiftUI 再响应该状态变化(返回上层视图),即使此时对 AG 进行清理,仍将可以保证 AttributeGraph 完整性,应用自然不会出现问题。...随着版本提高,SwiftUI 功能确实得到了相当程度增加。不过,即使在最新版本中,在一些对 UIKit(AppKit)进行二次包装控件中,仍有不少细节处理不到位问题。

589110

为什么 SwiftUI 修饰符顺序很重要

每当我们将修饰符应用于 SwiftUI 视图时,我们实际上都会创建一个,应用了更改视图 —— 我们不仅仅是修改现有的视图。...我们将在下一章中查看为什么会发生这种情况,但是首先,想看看这种行为实际含义。...如果思考一下修饰符工作原理,您就可以了解为什么会如此:每个修饰符都会创建一个,应用了该修饰符新结构体,而不是在视图上设置属性。 您可以通过查询视图主体类型来窥视 SwiftUI 底层。...(width: 200, height: 200) .background(Color.red) 现在最好思考方法是,想象一下 SwiftUI 在每个修饰符之后都会呈现视图。...例如,SwiftUI 为我们提供了 padding() 修饰符,该修饰符在视图周围添加了一些空间,从而不会将其推到其他视图或屏幕边缘。

2.3K20

onAppear 调用时机

创建实例、求值、布局、渲染在 SwiftUI 中,一个视图在它生命周期中通常会经历四个阶段:创建实例视图树中,处于可显示分支视图基本上都会经历一个阶段。...在一个视图生存期中,SwiftUI 可能会多次创建视图实例。由于惰性视图优化机制,对于尚未处于可见区域视图SwiftUI 不会创建其实例求值一个被显示视图至少会经历一次过程。...当视图依赖( Source of truth )发生变化后,SwiftUI 会重新计算视图结果,并与旧进行比较。如发生变化,则用新替换旧。...布局在计算好当前需要显示视图所有的视图后,SwiftUI 将进入到布局阶段。通过父视图向子视图提供建议尺寸,子视图返回需求尺寸这一过程,最终计算出完整布局结果。...有关布局流程请阅读 SwiftUI 布局 —— 尺寸 渲染SwiftUI 通过调用更加底层 API,将视图在屏幕上呈现过程。此过程严格意义上已经不属于 SwiftUI 管理范畴了。

2K20

SwiftUI数据流之State&Binding

SwiftUI中,单一数据源(single source of truth)为核心,构建了数据驱动状态更新机制。...@State检测类型 类型仅有独立拥有者,而class类型可以多个指向一个;对于两个SwiftUI View而言,即使发送给他们两个相同struct对象,事实上他们每个View都得到了一份独立...@State能够发现这个变化,并自动重新加载我们视图。现在如果改为class,我们有了一个类,这种行为就不再发生,Swift可以直接修改。...类不需要mutating关键字,因为即使类实例被标记为常量,Swift仍然可以修改变量属性。 如果User是一个类,属性本身就不会改变,所以@State不会注意到任何东西,也无法重新加载视图。...即使类内某个属性发生变化,但@State不监听这些,所以视图不会被重新加载。

4K30

SwiftUI 动画机制

开发者经常需要面对:如何动、怎么动、什么能动、为什么不动、为什么这么动、如何不让它动等等困扰。对 SwiftUI 动画处理逻辑了解不够深入是造成上述困扰主要原因。...本文将尝试对 SwiftUI 动画机制做介绍,帮助大家更好地学习、掌握 SwiftUI 动画,制作出满意交互效果。...SwiftUI 采用了声明式语法来描述不同状态下 UI 呈现,动画亦是如此。官方文档将 SwiftUI 动画(Animations)定义为:创建从一个状态到另一个状态平滑过渡。...细心朋友可能会发现,在上文中,当对时序曲线函数进行关联时,使用词语是“依赖项”而不是“状态”,这是因为视图状态是它拥有的全部依赖项总体呈现。...{ // 即使闭包中出现多个不同依赖项,不会影响 animation 仅与指定依赖相关联特性 switch status{ case .one:

14.6K40

onAppear 调用时机

创建实例、求值、布局、渲染 在 SwiftUI 中,一个视图在它生命周期中通常会经历四个阶段: 创建实例 视图树中,处于可显示分支视图基本上都会经历一个阶段。...在一个视图生存期中,SwiftUI 可能会多次创建视图实例。 由于惰性视图优化机制,对于尚未处于可见区域视图SwiftUI 不会创建其实例 求值 一个被显示视图至少会经历一次过程。...当视图依赖( Source of truth )发生变化后,SwiftUI 会重新计算视图结果,并与旧进行比较。如发生变化,则用新替换旧。...布局 在计算好当前需要显示视图所有的视图后,SwiftUI 将进入到布局阶段。通过父视图向子视图提供建议尺寸,子视图返回需求尺寸这一过程,最终计算出完整布局结果。...有关布局流程请阅读 SwiftUI 布局 —— 尺寸[5] 渲染 SwiftUI 通过调用更加底层 API,将视图在屏幕上呈现过程。此过程严格意义上已经不属于 SwiftUI 管理范畴了。

1.1K10

深度解读 Observation —— SwiftUI 性能提升新途径

为什么同样出现在 apply 闭包中可观察属性,修改后并不会触发回调( 测试二 )? withObservationTracking 创建观察行为是一次性还是持久性?...在视图中 @Obervable 与 ObservableObject 可以共存吗 可以。在一个视图中,可以同时存在不同方式声明可观察对象。...SwiftUI 将根据可观察对象在视图注入方式选择对应观察手段。 例如,上文中同时满足两种观察途径可观察对象,根据其注入方式不同,SwiftUI 采用更新策略将不同。...曾经编写过一个 @PublishedObject 属性包装器来解决这个问题。...经过修改后,当 store.b 发生变化时,只有 B 视图会重新评估。 由于 Observation 框架仍然是一个新事物,其 API 还在不断演化中。

49820

解析 SwiftUI 中两处由状态更新滞后引发严重 Bug

而通过调用环境或直接修改绑定状态,SwiftUI 则遵循了响应式编程原则,进行了先调整状态,后更新视图操作。...运行下面的代码,点击左上方返回按钮,与 NavigationStack 绑定 path,直到视图返回上一层后,才会发生改变。通过环境返回上层视图同样需要等待视图返回后,才会修改状态。...当视图正在滚动时返回上一层视图会导致应用崩溃 这是一个由 xiaogd 在 Discord 论坛中提出 问题[3]。...因此,当我们首先更新状态,然后 SwiftUI 再响应该状态变化(返回上层视图),即使此时对 AG 进行清理,仍将可以保证 AttributeGraph 完整性,应用自然不会出现问题。...随着版本提高,SwiftUI 功能确实得到了相当程度增加。不过,即使在最新版本中,在一些对 UIKit(AppKit)进行二次包装控件中,仍有不少细节处理不到位问题。

26720
领券