当前位置：首页 > news >正文

网站建设套餐价格/搜索大全引擎入口

news 2025/8/5 7:36:33

网站建设套餐价格,搜索大全引擎入口,网站备案名称更改,在线爱情动做网站wwdc20 再次点燃大家学习SwiftUI的热情，那么我们到底该不该将项目重构成SwiftUI？我们该如何正确使用SwiftUI呢？让我们听听大牛怎么说。目录我们要把SwiftUI当成学习现代编程语言的好工具学习并不一定意味着部署将SwiftUI建立为内部工具和原…

wwdc20 再次点燃大家学习SwiftUI的热情，那么我们到底该不该将项目重构成SwiftUI？我们该如何正确使用SwiftUI呢？让我们听听大牛怎么说。

我们要把SwiftUI当成学习现代编程语言的好工具

一年前，在WWDC 2019开始之前，苹果开发者社区内部就苹果最终是否会开始发售仅Swift的框架进行了很多猜测和辩论。

当时，苹果公司将偏离其与Objective-C保持完全向后兼容性的既定策略的想法似乎是一个非常激进的想法，但是，最终结果是发生了-通过引入诸如Combine这样的框架， SwiftUI和CryptoKit。

快进到2020年6月，仅Swift框架的概念现在已不再是一种可能性了-可以说这是新常态，至少对于Apple各种SDK的新增功能而言。但是苹果并没有就此止步。今年，在WWDC20上，我们看到了苹果首个SwiftUI-only框架WidgetKit的引入。

现在，取决于您问的是谁，Apple在WWDC20主题演讲中宣布的新主屏幕小部件只能使用SwiftUI来构建，这听起来可能令人惊叹，可怕，彻头彻尾。可以肯定地说，SwiftUI在许多方面已经席卷了Apple开发人员社区，并使许多新开发人员可以开始构建他们的第一个应用程序，但至少可以说，SwiftUI上的当前观点存在分歧。

学习并不一定意味着部署

“我应该学习SwiftUI吗？”毫无疑问，这是我在过去一年中被问到的最常见问题之一。

现在，在回答这样的问题时，我总是会非常谨慎，因为在不熟悉他们的个人背景的情况下，很难给出关于任何给定开发人员应该做什么或不应该做什么的具体建议。例如，他们正在开发哪种应用程序，其用户群是什么样的，以及他们的团队或公司如何运作？

但是，今年苹果公司的公告已经大大改变了我的默认答案，即在苹果平台上工作的开发人员是否应该学习SwiftUI，而我的回答是“是”。

重要的是要记住，您不必在主要生产代码库中部署某些东西就可以学习它。实际上，我个人尝试在运输代码以外的地方进行尽可能多的学习，不仅涉及SwiftUI，而且通常。

虽然在学习内容时记住具体的用例通常很棒，但是有很多方法可以编写非常有价值的代码而无需实际将其交付给客户，这极大地降低了使用我们所拥有的技术来交付应用或功能所固有的风险尚未完全熟悉。

建立内部工具和原型

特别是谈到SwiftUI时，它的轻量级语法在很多方面使其非常适合诸如原型制作，构建内部工具和实用程序，用户测试以及爱好项目之类的任务。例如，假设我们要向应用的内部版本中添加一个视图，以使开发人员和设计人员都可以预览一组主题中的所有颜色，并且这些主题是使用如下结构定义的：

struct Theme {var name: Stringvar isDark: Boolvar brandColor: UIColorvar activeButtonColor: UIColorvar titleColor: UIColor...
}

为了进行这些预览，我们可以使用一些反射来从上述Theme类型的实例中提取所有颜色，然后通过编写少量的SwiftUI代码来呈现它们的列表，如下所示：

#if INTERNAL_BUILD
struct ColorList {var entries = [(color: UIColor, name: String)]()
}extension Theme {func makeColorList() -> ColorList {let mirror = Mirror(reflecting: self)var list = ColorList()for (label, value) in mirror.children {guard let color = value as? UIColor,let name = label else {continue}list.entries.append((color, name))}return list}
}struct ColorListView: View {var list: ColorListvar body: some View {List(list.entries, id: \.name) { entry inHStack {Circle().fill(Color(entry.color)).frame(width: 50, height: 50)Text(entry.name)}}}
}
#endif

请注意，上述所有代码是如何包装在自定义INTERNAL_BUILD编译器标志中的，这使我们避免将该代码包含在应用程序的App Store版本中。

假设我们的应用当前附带两个主题-一个主题为浅色模式，另一个主题为暗色模式-因此，我们还要添加一个列表视图，让我们选择要预览的两个主题。我们还将修改每个主题的ColorListView实例以匹配其相应的系统配色方案，以使预览更加准确：

#if INTERNAL_BUILD
struct ThemeListView: View {var themes: [Theme] = [.light, .dark]var body: some View {NavigationView {List(themes, id: \.name) { theme inNavigationLink(theme.name,destination: ColorListView(list: theme.makeColorList()).colorScheme(theme.isDark ? .dark : .light).navigationBarTitle(Text(theme.name),displayMode: .inline))}.navigationBarTitle("Select a theme")}}
}
#endif

请注意，如果上面的代码是打算投入生产或用于渲染大量主题的，那么我们可能不希望在视图主体中内联执行makeColorList转换。但这就是构建内部工具和原型的美丽-我们可以采取捷径！

上面的内容当然只是一个例子，但是如果我们考虑一下，只需编写少量的SwiftUI代码，我们就已经了解了它的一些基本概念，例如视图组成，布局，修饰符，导航和以此类推。另外，除了学习方面，我们还为团队中的开发人员和设计师提供了一个超级有用的工具-太棒了！

SwiftUI也非常适合原型制作。就像构建内部工具一样，我们通常希望在任何给定的原型上花费尽可能少的时间，因为从一开始进行原型设计的目的就是快速了解给定的想法或功能是否可行。

在这种情况下，SwiftUI之所以如此出色，是因为它依赖于强大的默认设置和平台约定，它使我们能够立即构建原型，几乎不需要进行任何设置。只需看下面的代码示例-这就是开始使用功能齐全的基于SwiftUI的应用所需的一切（从Xcode 12开始）：

@main struct MyPrototype: App {var body: some Scene {WindowGroup {Text("Let's start prototyping!")}}
}

简化我们的生产方式

当然，SwiftUI不仅是原型制作工具，它还是一个功能强大的UI框架，越来越多地用于运送从小型独立应用程序到大规模生产软件的项目。那么何时以及如何在我们实际交付给客户的代码中使用它是一个好主意？

除了它是一个年轻的框架之外，SwiftUI的采用方面最主要的限制因素可能是它无法在低于iOS 13或macOS Catalina的操作系统上运行，这可能无法为许多项目所接受，即使在今年晚些时候发布苹果即将发布的OS版本时，这种情况很有可能会改变。

但是，正如去年WWDC后的文章“在Swift中转变范式”所述，SwiftUI远非“一无所有”的主张。它与UIKit和AppKit的互操作性非常强，这意味着我们也许可以仅使用SwiftUI来构建一个小的功能，仅向运行iOS 13及更高版本的用户提供此功能（这在大多数应用中应该是绝大多数）。或者，我们可以使用它来实现依赖于较新的系统API的功能，例如小部件或应用程序剪辑。

就像构建工具，原型和爱好项目如何使我们在“更安全的环境”中学习新框架一样，如果我们仅在现有应用的一小部分开始采用SwiftUI，我们也很可能会发现它是否是对于我们的特定用例，可以更快地投入生产。因为即使Apple和许多第三方开发人员已经在生产环境中部署SwiftUI并不意味着它将成为每个应用程序的理想工具，至少直到它有更多的时间作为框架成熟时才如此。

网站建设套餐价格/搜索大全引擎入口

目录

我们要把SwiftUI当成学习现代编程语言的好工具

学习并不一定意味着部署

建立内部工具和原型

简化我们的生产方式

推荐

基础文章推荐

经典教程推荐

上新

技术源码推荐

推荐文章

CoreData篇

Combine篇

TextField篇

JSON文件篇

一篇文章系列

技术交流

相关文章：