距离 2023 年的 WWDC 还有约 20 天,每个苹果生态的开发者都在期待苹果会在当天带来哪些新东西。在本文中,我将列出个人对于 SwiftUI 的希望单,期待着看到哪些希望能够完成。

假如不限制数量,SwiftUI 开发者或许会列出一个长长的希望列表。在此仅列出几个我以为重要且近一两年内有望完成的希望,防止期望过高而带来的绝望。

原文发表在我的博客wwww.fatbobman.com

欢迎订阅我的大众号:【肘子的Swift记事本】

以特点为粒度的视图相关

急迫性:4 完成或许性:3.5( 总分 5 分 )

在上个月,Swift 社区出现了一个提案 SE-0395: Observability , 简略来说能够将其理解为 Swift 原生的 KVO 加强版完成。假如这个提案得以在近期通过,那么在 SwiftUI 中,视图就有或许完成以特点为粒度的依赖相关。如此一来,在运用根据 ObservableObject 协议的引用类型 Source of truth 时,不必要的计算将大大减少,开发者将能够用更自由的方法来安排 Data flow。

一致的 Gesture 逻辑、答应创建真实的自定义手势

急迫性:5 完成或许性:2.5

在 SwiftUI 中,开发者很难完成杂乱的手势逻辑。其间一个重要原因是 SwiftUI 现在存在两个手势系统,并且两者的兼容性很差,其间一种很简单被另一种打断。从 SwiftUI 的 interface 文件能够看到,ScrollView、List、TabView、Button 等控件都有其对应的内部手势完成,这些完成与常用的 DragGesture、TapGesture 等开放给开发者的手势在很大程度上不同。它们在优先级上更高,并且它们之间也不能很好地共融。这就导致无法用原生的 SwiftUI 方法应对有杂乱手势需求的场景(例如多重翻滚嵌套)。

此外,SwiftUI 并未供给真实的自定义手势才能,现在仅支撑根据当时已供给手势的组合功用。假如开发者运用根据 UIKit 的自定义手势,则将落入到上文说到的手势之间相互竞争的困境中。

只有尽早供给完善的自定义手势功用,并在 SwiftUI 内部完成手势逻辑的一致,才干解决这些问题。

更完善的文字输入和显现

急迫性:5 完成或许性:4

相较于最初版别,SwiftUI 4.0 的 Text 和 TextField 功用已经有了极大的增强和改进。然而,与老练的解决方案相比,它们仍有相当的距离。许多开发者为了解决某些问题不得不根据 UIKit( AppKit )重新包装所需的显现和录入控件,这不只增加了工作量,也放弃了许多原生控件所供给的优秀才能。

说实话,无论 Text 和 TextField 增强到何种程度都不为过。但对我而言,现在急需解决的问题有以下几点:

  • 供给更好的 AttributedString 支撑

除了在 AttributedString 诞生的那一年 Text 供给了部分支撑外,上一个版别中没有在这方面做出任何改进。Text 应该供给更多对 AttributedString 特点的支撑,特别是针对阶段的支撑。最好还能供给自定义 Attribute 显现的 API,给开发者供给自行扩大的才能。此外,TextField 也应该支撑 AttributedString,这样就能够用原生的方法应对一些简略的排版场景。

  • 为防止状况黑洞,需求更一致的状况响应逻辑。

尽管 TextField 的结构方法很好地遵从了 SwiftUI 由状况驱动的逻辑,但这仅仅表象。实际上,在许多情况下,它仅仅在表演状况与显现一一对应的联系。因为经过了二次包装,这些控件在内部完成时常常遗漏与外部状况的对应,然后出现无法处理的情况(无法从状况下手,也无法从内部找到 hack 的点)。

这种问题不只出现在 TextField 上,许多首要依赖对 UIkit 二次包装的控件现在都存在相似的问题。从某些 Bug 的分析中能够看出,SwiftUI 团队的部分开发人员也没有彻底转换至声明、状况、响应的思想逻辑上。在包装时,他们常常会遗漏与外部状况的同步。

稳定、高效的 ForEach 完成

急迫性:5 完成或许性:3.5

在 SwiftUI 中,ForEach 是一个常常运用的控件,尤其在 Lazy 容器中。 然而,直到 4.0 版别,它的稳定性和性能依然无法彻底令人满意。例如:

  • 在子视图运用的 id 润饰符的情况下,优化机制失效
  • 内存释放不及时,简单导致使用溃散
  • task 润饰器闭包任务无法 100% 调用( 已在 16.4 修正 )
  • 二级及以下子视图在 onDisappear 后无法保持状况( 在写本文前两天,收到苹果的回复,证实此为 by Design 的行为 )

这导致在数据量较大的情况下,根据 SwiftUI 的使用性能较差,用户体会不佳。随着根据 SwiftUI 的使用越来越杂乱,ForEach 的问题急需解决。

当然,假如在改进 ForEach 问题的一起能供给一个支撑 Lazy 的 Layout 协议那就更好了。

向前兼容性

急迫度:4 完成或许性:4.5

当看到 Swift 5.8 供给了 @backDeployed 特性时,信任许多开发者都迫切希望苹果能将其使用于 SwiftUI,以增强老版别的功用并修正 bug。每次 WWDC 推出新版别 SwiftUI 时,开发者在快乐的一起也会感到痛苦:莫非又要提高使用的最低版别要求?

假如苹果能充分利用该特性,将为开发者带来巨大好处。

最终

作为未来数年中苹果生态中最首要的开发结构,SwiftUI 应该供给更多原生、稳定的底层 API,让有经历的开发者能够自行添加特性。这样既能够减轻苹果的工作量,又能让开发者有更多的选择。何乐而不为呢?

写出你的希望单,赢取

假如你对 SwiftUI 5 有什么期望,请在此 推文 下回复。获得最多 ❤️的 7 个回复者,我将送出一箱大连 。

WWDC 2023, 我期待 SwiftUI 带来的新变化

向大众号的读者道歉,昨天我本打算在大众号上举办这个活动,结果宣布文章后才发现,我的大众号没有评论功用。只能把原来预备给大众号的两箱樱桃也放到 Twitter 上了。

原文发表在我的博客wwww.fatbobman.com

欢迎订阅我的大众号:【肘子的Swift记事本】