因为SwiftUI View 采用的是结构体，当创建想要更改属性的结构体方法时，我们需要添加mutating关键字,例如：
SwiftUI中的界面是严格数据驱动的：运行时界面的修改，只能通过修改数据来间接完成，而不是直接对界面进行修改操作。
在 WWDC 2023 中，苹果介绍了 Swift 标准库中的新成员：Observation 框架。它的出现有望缓解开发者长期面临的 SwiftUI 视图无效更新问题。本文将采取问答的方式，全面而详尽地探讨 Observation 框架，内容涉及其产生原因、使用方法、工作原理以及注意事项等。
本文将对 @Published 与符合 ObservableObject 协议的类实例之间的沟通机制做以介绍，并通过三个示例：@MyPublished（ @Published 的仿制版本 ）、@PublishedObject（包装值为引用类型的 @Published 版本）、@CloudStorage（类似 @AppStorage ，但适用于 NSUbiquitousKeyValueStore ），来展示如何为其他的自定义属性包装类型添加可访问包裹其的类实例的属性或方法的能力。
在这篇文章中，我们将探讨几个在 SwiftUI 开发中经常使用且至关重要的属性包装器。本文旨在提供对这些属性包装器的主要功能和使用注意事项的概述，而非详尽的使用指南。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为下篇。
NSUbiquitousKeyValueStore 是苹果官方提供的用于在设备间共享键值数据的解决方案。本文将对其用法做以简单介绍，着重探讨如何便捷地在 SwiftUI 中使用 NSUbiquitousKeyValueStore。
微软虽然提出了 MVVM，但又没有提供一个官方的 MVVM 库（多年前有过 Prism，但已经离家出走了）。每次有人提起 MVVM 库，有些人会推荐 Prism（例如我），有些人会推荐 MVVMLight。可是现在 Prism 已经决定不再支持 UWP ， 而 MVVMLight 又不再更新，在这左右为难的时候 Windows Community Toolkit 挺身而出发布了 MVVM Toolkit。 MVVM Toolkit 延续了 MVVMLight 的风格，是一个轻量级的组件，而且它基于 .NET Standard 2.0，可用于UWP, WinForms, WPF, Xamarin, Uno 等多个平台。相比它的前身 MVVMLight，它有以下特点：
随着近年来有关 SwiftUI 的文章与书籍越来越多，开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态，当状态变化时，SwiftUI 都将重新计算与其对应视图的 body 值。
在上文中，我列举了一些在 SwiftUI 中使用 Core Data 所遇到的困惑及期许。在今后的文章中我们将尝试用新的思路来创建一个 SwiftUI + Core Data 的 app，看看能否避免并改善之前的一些问题。本文将首先探讨如何定义数据。
在UI界面中，树形视图是比较常用的表示层级结构的方式，WPF中提供了TreeView控件。对于TreeView控件的基本使用已经有很多文章。大都是介绍如何在XAML中使用硬编码的固定信息填充Treeview控件，或者是后台代码递归遍历数据源，动态创建TreeView。这里我想介绍一下如何只通过XAML标记，不用一行后台代码遍历数据实现TreeView。
要编写出色的应用程序，您不仅需要提出一个好主意，还需要考虑未来。快速有效地适应、改进和扩展应用程序功能的灵活性至关重要。无论您是在团队中工作还是独自工作，从长远来看，您编写和组织代码的方式将对维护您的代码产生巨大影响。这就是 SOLID 原则的用武之地。
SwiftUI的环境使我们可以使用来自外部的值，这对于读取Core Data上下文或视图的展示模式等很有用。但是我们也可以将自定义对象发送到环境中，并在以后将它们读出来，这使我们可以在复杂的应用程序中更轻松地共享数据。
Loxodon.Framework.XLua 是一个XLua的开源的MVVM框架，它做为Unity3D的MVVM框架Loxodon.Framework的插件来使用。使用这个框架，可以做到完全使用Lua来编写游戏逻辑，并且遵循MVVM的开发习惯，支持数据绑定，有感兴趣的朋友可以去github下载。
我最近开始重新开发我的“健康笔记”应用程序。由于新版本将只支持 iOS 17 及以上版本的设备，这让我在选择技术路线上享有更大的自由。
我是在去年阅读王巍写的《SwiftUI 与 Combine 编程》才第一次接触到单一数据源这一概念的。
编译 | 核子可乐、Tina SwiftUI 很好，但是苹果对它投资不足。 在 2019 年的 WWDC 大会上，苹果推出了一个全新的 SwiftUI 框架，这是一个现代化的 UI 界面编码结构，它是基于 Swift从头开始构建的。新框架使用声明性范例，让开发者用更少的代码编写相同的 UI。 SwiftUI 的愿景是降低开发 iOS 门槛，吸引更多开发者、丰富 iOS 的业态。并且 SwiftUI 可以“实现一次编码，可适应五端 Apple 产品平台”， 包括watchOS、tvOS、macOS 等，
我在去年底使用了SwiftUI写了第一个 iOS app 健康笔记，这是我第一次接触响应式编程概念。在有了些基本的认识和尝试后，深深的被这种编程的思路所打动。不过，我在使用中也发现了一些奇怪的问题。我发现在视图（View）数量达到一定程度，随着数据量的增加，整个app的响应有些开始迟钝，变得有粘滞感、不跟手。app响应出现了问题一方面肯定和我的代码效率、数据结构设计欠佳有关；不过随着继续分析，发现其中也有很大部分原因来自于SwiftUI中所使用的响应式的实现方式。不恰当的使用，可能导致响应速度会随着数据量及View量的增加而大幅下降。通过一段时间的研究和分析，我打算用两篇文章来阐述这方面的问题，并尝试提供一个现阶段的使用思路。
VIPER架构模式是MVC或MVVM的另一种选择。虽然SwiftUI和Combine框架创建了一个强大的组合，可以快速构建复杂的ui和在应用程序中移动数据，但它们也面临着各自的挑战和对架构的看法。
在苹果生态的应用中，开发者或多或少都会使用到UserDefaults。我个人习惯将可被用户自定义的配置信息（精度、单位、色彩等）保存在UserDefaults中。随着配置信息的增加，在SwiftUI视图中使用的@AppStorage越来越多。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为上篇。
SwiftUI与苹果之前的UI框架的区别不仅仅在于如何定义视图和其他UI组件，还在于如何在整个使用它的应用程序中管理视图层级的状态。
在 UIKit（AppKit）的世界中，通过框架提供的大量钩子（例如 viewDidLoad、viewWillLayoutSubviews 等），开发者可以将自己的意志注入视图控制器生命周期的各个节点之中，宛如神明。在 SwiftUI 中，系统收回了上述的权利，开发者基本丧失了对视图生命周期的掌控。不少 SwiftUI 开发者都碰到过视图生命周期的行为超出预期的状况（例如视图多次构造、onAppear 无从控制等）。
1、QT信号槽机制的优缺点 1）QT信号槽机制的引用精简了程序员的代码量 2）QT的信号可以对应多个槽（但他们的调用顺序随机），也可以多个槽映射一个信号 3）QT的信号槽的建立和解除绑定十分自由 4）信号槽同真正的回调函数比起来时间的耗损还是很大的，所有在嵌入式实时系统中应当慎用 5）信号槽的参数限定很多例如不能携带模板类参数，不能出现宏定义等等
长久以来，开发者对 SwiftUI 的导航系统颇有微词。受 NavigationView 的能力限制，开发者需要动用各种技巧乃至黑科技才能实现一些本应具备基本功能（例如：返回根视图、向堆栈添加任意视图、返回任意层级视图 、Deep Link 跳转等 ）。SwiftUI 4.0（ iOS 16+ 、macOS 13+ ）对导航系统作出了重大改变，提供了以视图堆栈为管理对象的新 API ，让开发者可以轻松实现编程式导航。本文将对新的导航系统作以介绍。
随着苹果对 iPadOS 的不断投入，越来越多的开发者都希望自己的应用能够在 iPad 中有更好的表现。尤其当用户开启了台前调度（ Stage Manager ）功能后，应用对不同视觉大小模式的兼容能力就越发显得重要。本文将就如何创建可自适应不同尺寸模式的程序化导航方案这一内容进行探讨。
Android系统的视图结构的设计也采用了组合模式，即View作为所有图形的基类，Viewgroup对View继承扩展为视图容器类，由此就得到了视图部分的基本结构--树形结构 View定义了绘图的基本
众所周知，SwiftUI 是一个响应式框架，这意味着，当数据源发生变化时，框架会自动更新视图。同样，当我们想调整视图显示时，应直接对状态进行修改。但是，SwiftUI 中的一些系统控件并没有完全遵循响应式的设计原则，由此在某些情况下会出现严重的错误，影响用户体验，并使开发者无所适从。
概念 Combine 中包括Publisher在内的一系列角色都使用协议来进行定义，这是 Swift 面向协议编程思想的具体体现。 Publisher 随着时间推移向一个或多个Subscriber发布数据。 Publisher 最主要的工作其实有两个 被 Subscriber 订阅 发布数据和数据 Publisher定义 public protocol Publisher { /// 发送的数据的类型 associatedtype Output /// Publisher可能产生
本文墨香投稿，推荐大家用一款Mac下强大的静态代码分析工具，以后妈妈再也不用担心我不会分析代码啦。 之前用Windows系统，一直用source insight查看代码非常方便，但是年前换到mac下面，虽说很多东西都方便了，但是却没有了静态代码分析工具，很幸运，前段时间找到一款比source insight软件还强大的代码静态分析工具，堪称神器—Understand。这款软件具有强大的代码静态分析功能，并且可以绘制各种流程图，不幸的是没有发现Windows版本，只看到mac版和Linux版本因此用Windo
判断一个可滚动控件（ ScrollView、List ）是否处于滚动状态在某些场景下具有重要的作用。比如在 SwipeCell[3] 中，需要在可滚动组件开始滚动时，自动关闭已经打开的侧滑菜单。遗憾的是，SwiftUI 并没有提供这方面的 API 。本文将介绍几种在 SwiftUI 中获取当前滚动状态的方法，每种方法都有各自的优势和局限性。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器，它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同，原理以及注意事项。
Swift 5.5中引入的 async/await 语法，允许用更可读的方式来编写异步代码。异步编程可以提高应用程序的性能，但必须取消不需要的任务，以确保不需要的后台任务不会干扰到应用程序。本文演示了如何明确地取消一个任务，并展示了子任务是如何自动取消的。
Async/await语法是在Swift 5.5 引入的，在 WWDC 2021中的 Meet async/await in Swift 对齐进行了介绍。它是编写异步代码的一种更可读的方式，比调度队列和回调函数更容易理解。Async/await 语法与其他编程语言（如C#或JavaScript）中使用的语法类似。使用 "async let "是为了并行的运行多个后台任务，并等待它们的综合结果。
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式，并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量 前文[1] 中介绍的技巧和方法，因此最好一并阅读。
本篇介绍了深度神经网络表示学习+聚类的方法（深度聚类）综述，有帮助的话，文末点个赞吧~
Swift提供了一个Combine的功能，它可以使我们组合不同的框架使用包括UIKit跟SwiftUI
mysql 5 之后的版本新增的功能。其实就是一种虚拟存在的表，注意视图里存的其实就是 sql 逻辑，表象视图是一个表，通过查询视图动态运行里头 sql 逻辑而已
最近看了斯坦福大学 2020 春季的 SwiftUI 课程，总结一下 SwiftUI 是如何支持 MVVM 设计模式的。
前些日子，我发布一个苹果官方文档的翻译，之后就有不少同学朋友问我：翻译苹果官方文档能做什么，开发过程用到的时候很少,浪费时间，还又没什么用。今天，刚好有时间，就在此申明一下翻译苹果官方文档的实质作用：
Async let 是Swift并发框架的一部分，允许异步实例化一个常量。并发框架引入了async-await的概念，这使得异步方法的并发性结构化，代码更易读
继上文分析Channel实例化流程后，本文通过分析Channel的初始化流程。旨在从整体上厘清DefaultChannelPipeline、ChannelHandlerContext、ChannelHandler的逻辑关系。
视图：视图（view）是一种虚拟存在的表，是一个逻辑表，本身并不包括数据 作为一个select语句保存在数据字典中的 通过视图，可以展现基表的部分数据，属兔数据来自定义视图的查询中使用的表 使用视图动态生成 基表：用来创建视图的表叫做基表base table 因为试图的诸多优点 如下： 1）简单：使用视图的用户完全不需要关心后面对应的表的结构、关联条件和筛选条件，对用户来说已经是过滤好的复合条件的结果集。 2）安全：使用视图的用户只能访问他们被允许查询的结果集，对表的权限管理并不能限制到某个行某个列，但是通过视图就可以简单的实现。 3）数据独立：一旦视图的结构确定了，可以屏蔽表结构变化对用户的影响，源表增加列对视图没有影响；源表修改列名，则可以通过修改视图来解决，不会造成对访问者的影响。
@State是一个属性包装器（property wrapper），被设计用来针对值类型进行状态管理；用于在Struct中mutable值类型
经过两年多的时间，SwiftUI发展到当前的3.0版本，无论SwiftUI的功能还是Swift语言本身在这段时间里都有了巨大的提升。是时候使用Async/Await来重构我的的状态容器代码了。
保证应用不因 Core Data 的原因导致意外崩溃是对开发者的起码要求。本文将介绍可能在视图中产生严重错误的原因，如何避免，以及在保证视图对数据变化实时响应的前提下如何为使用者提供更好、更准确的信息。由于本文会涉及大量前文中介绍的技巧和方法，因此最好一并阅读。
尽管 SwiftUI 的惰性容器以及 Core Data 都有各自的内存占用优化机制，但随着应用视图内容的复杂（ 图文混排 ），越来越多的开发者遇到了内存占用巨大甚至由此导致 App 崩溃的情况。本文将通过对一个演示 App 进行逐步内存优化的方式（ 由原先显示 100 条数据要占用 1.6 GB 内存，优化至显示数百条数据仅需 200 多 MB 内存 ），让读者对 SwiftUI 视图的存续期、惰性视图中子视图的生命周期、托管对象的惰值特性以及持久化存储协调器的行缓存等内容有更多的了解。
苹果于 WWDC 2023 上推出新框架 SwiftData，提供声明性的、以 Swift 为先的 API，可在 iOS 应用中进行数据持久化工作。SwiftData 可轻松将一个 Swift 类转换为一个持久化模型，非常适合同 SwiftUI 一并使用。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
