通过UIKit框架，有两种方法可用于创建iOS应用程序的用户界面：Storyboard和编程。这两种方法都有一些优点。
当我第一次开始学习为iOS创建用户界面时，我不知道如何在使用Storyboard和以编程方式编写用户界面之间做出决定。然而，经过大量的研究和实践开发经验，我已经准备好分享我所学到的东西，也提供一些见解和意见。
在这篇文章中，我们将比较用Storyboard和用编程方式为iOS创建用户界面的优缺点。我们将演示用这两种方法对同一个用户界面进行编码，并且我们还将讨论在某些情况下哪种方法更好。
让我们开始吧!
用Storyboard设计iOS的用户界面
Storyboard允许我们通过简单的拖放将UI元素添加到屏幕上。要用Storyboard在UIKit中创建一个项目，我们在Xcode项目界面的下拉菜单中选择Storyboard。
使用界面生成器，我们将UI元素添加到屏幕上，如下面的视频所示。我们点击**"+**"按钮，选择一个对象，然后将其拖放至屏幕上所需的位置。
用Storyboard创建一个UI样本
让我们创建一个名为Koala-Storyboard 的示例项目。如下面的视频所示，我们将在界面生成器中添加一个考拉图片和文字 "Koala"。
故事板使我们能够在短短几秒钟内将对象添加到用户界面中。我们只需将对象放在所需的位置就可以了。然而，重要的是要明白，这种方法不会自动产生一个响应式设计。
当我们在样本的iOS设备画布上创建一个用户界面，然后在不同的设备上构建应用程序时，最终的结果可能会有一点不同的外观。
这里有一个例子可以说明这个问题。
这个用户界面是在iPhone 11的画布上创建的（右图），但在第二代iPhone SE上运行时看起来却不一样（左图）。
为了创建一个在所有设备上看起来都一样的用户界面，我们必须为不同的用户界面元素添加关系约束并使用界面生成器的自动布局功能。自动布局会自动调整UI的布局，以考虑到设备的屏幕尺寸，以及用户旋转设备或调整窗口大小等外部变化。
首先，我们将添加一些约束条件，以便在不同的设备上有相同的用户界面。我们将调整图片的大小，并将其定位在屏幕的中心。
接下来，我们将把 "我爱考拉 "的文字放在图片下方64px的位置。
这个过程使我们能够为不同的设备建立相同的用户界面，如iPhone 11、iPhone 8和iPhone 13 Pro Max。每台设备都能将图像显示在屏幕中央，文字在图像下方64px处。
使用界面生成器的自动布局功能，在Storyboard中构建的应用程序UI。
虽然Storyboard不能自动生成响应式设计，但它可以是一种非常有用的原型设计方法。要创建一个演示或原型，我们只需选择适当的设备画布。
在Storyboard中合并冲突
合并冲突可能是Storyboard最显著的缺点。合并冲突很容易发生，而且由于Storyboard实际上是一个XML文件，所以调试和解决冲突会很困难。
让我们回顾一下Storyboard的合并冲突情况。
假设我们有两个开发人员。开发者A和开发者B都在做一个特定的屏幕。每个开发者都有自己的分支，这些分支是由主分支创建的。
在开发过程中，发生了以下一系列的事件。
- 开发者A将
imageView（在本例中，考拉图像）向上移动一定数量的像素 - 开发者B添加了一个按钮并将
imageView下移了一定数量的像素 - 开发者B的分支被合并到主分支上
在这些事件之后，开发者 A 的分支落后于主分支，他们分支的代码库已经过时了。开发者 A 试图将他们的分支与主分支合并，但出现了合并冲突。
VS代码中显示的合并冲突。
我们可以看到VS代码中的冲突。更新的流（绿色显示）代表开发者B的修改。隐藏的修改（蓝色显示）代表开发者A的修改。
有三个选项可以尝试解决冲突。
- 接受最新的修改（开发者A的修改）并失去更新的流（开发者B的修改）。
- 只接受更新的流（开发者B的修改）。
- 接受所有更改的行，不丢失任何一个更改
接受每一个变化（选项3）最初可能是最好的选择，但首先，让我们仔细看看代码。
一个开发者把imageView ，另一个开发者把它移到了下面。该文件现在由两个imageViews （在第26和48行）。由于这两个imageViews 有相同的ID，当我们打开Xcode时，我们看到一个错误。
Xcode中的合并冲突错误。
合并冲突在开发中并不少见，而且在Xcode中发生得相当频繁。Xcode在XML文件中添加了一些引用和ID。因此，当一个UI变得更加精细时，XML文件也变得更加复杂。即使只是两个在同一个UIKit Storyboard项目上工作的开发者也会面临合并冲突，这需要花费一些时间和注意力来解决。
使用Storyboard为iOS设计UI的优点和缺点
下面是对Storyboard的优点和缺点的总结。
| 优点 | 缺点 |
|---|---|
| 可以很容易地在屏幕上添加UI元素（拖放）。 | 需要对自动布局进行约束（响应性）。 |
| 易于创建原型（静态UI）的选项 | 困难的代码审查（XML文件） |
| 在Xcode上提供了一个所有屏幕的可视化表示 | 难以解决合并冲突(XML文件) |
| 难以让一个以上的开发者在同一个屏幕上工作 | |
| 代码是不可搜索的 | |
| 如果Storyboard组织得不好，性能（应用程序加载时间）会受到影响 | |
| 不支持动画（任何动画都必须以编程方式添加）。 | |
| 难以看到UI元素的属性 |
以编程方式设计iOS UI
以编程方式构建UI意味着用代码（确切地说，是Swift）创建用户界面，而不是使用界面生成器。
为了在UIKit中以编程方式创建一个项目，我们创建一个新的Xcode项目，并像之前那样最初选择故事板。Xcode默认创建一个故事板，并将其作为初始屏幕。我们进入Project Navigator并删除对Storyboard的任何引用。我们还对Info.plist 和AppDelegate.swift 进行了一些配置修改，以删除Storyboard的依赖性。关于这些配置修改的教程，请跟随这个视频。
为了以编程方式构建UI，我们首先创建一个UI元素的实例。然后，我们对该实例在屏幕上的位置进行编码。
以编程方式创建一个UI样本
让我们以编程方式创建一个用户界面样本，它将与Koala-Storyboard 。
我们将使用下面的Swift代码片断。
let koalaView = UIImageView()
koalaView.image = UIImage(named: "koala")
koalaView.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(koalaView)
NSLayoutConstraint.activate([
koalaView.centerYAnchor.constraint(equalTo: view.centerYAnchor),
koalaView.centerXAnchor.constraint(equalTo: view.centerXAnchor),
koalaView.widthAnchor.constraint(equalToConstant: 320),
koalaView.heightAnchor.constraint(equalToConstant: 320)
])
首先，我们创建一个名为koalaView 的UIImageView 。我们给它一个图像属性，UIImage ，和一个文件名，koala 。我们把这个子视图添加到父视图中。
然后，我们使用NSLayoutConstraint 类来定位这个UI元素。我们通过指定它的centerYAnchor 和centerXAnchor 的值应该等于父视图（在这里是指屏幕）的centerYAnchor 和centerXAnchor 的值，来使UI元素在屏幕中居中。就像我们在Storyboard的Interface Builder中所做的那样，我们指定图像的宽度和高度为320px。
let koalaText = UILabel()
koalaText.text = "I love koalas
我们为 "我爱考拉 "的文字创建一个UILabel() ，并指定一个UIFont ，以符合Storyboard例子中的尺寸。接下来，我们使用centerXAnchor.constraint ，将文本水平居中对齐（沿X轴）。我们使用topAnchor.constraint ，将测试定位在图片的bottomAnchor 下方64px。
下面是一个以编程方式创建的用户界面的例子。
以编程方式创建的应用程序用户界面的演示。
注意，苹果公司提供了NSLayoutConstraint 类来约束UI元素之间的关系；然而，一些第三方库也能更容易地提供同样的功能。其中一个最受欢迎的库是SnapKit。要了解更多关于SnapKit的信息，请查看它在GitHub上的存储库。
以编程方式为iOS创建UI的优点和缺点
以下是以编程方式创建UI的利弊总结。
| 优点 | 缺点 |
|---|---|
| 所有的UI和屏幕控制都在一个地方 | 大多数开发者发现编写代码比拖放更耗时。 |
| 代码可以被搜索和重复使用 | 在代码运行之前没有屏幕的视觉表现 |
| 对有经验的开发者来说，容易进行代码重构，因为开发者可以控制UI元素。 | 在旧代码或由其他开发者编写的代码的情况下，有可能进行复杂的重构 |
| 更容易解决合并冲突 | 需要对自动布局（响应性）进行约束 |
| 容易看到UI元素的属性 | |
| 支持添加动画 |
总结
在这篇文章中，我们评估了使用Storyboard来创建iOS应用的用户界面与以编程方式构建用户界面的利弊。我们表明，根据不同的情况，每一种方法都可以是有利的。以下是本文中使用的Storyboard例子和程序化例子的资料库。
我建议你在使用Storyboard和编程设计时都能得心应手，这样你就可以根据项目的具体情况来决定使用哪种方法。
如果你有创建静态用户界面的冲动，并且是一个单独的开发者，Storyboard可能是最好的选择。Storyboard很快，而且没有其他开发者在项目上工作，你不会面临合并冲突。
我希望你喜欢这篇文章。如果你有任何反馈，或者想分享关于这个话题的知识，欢迎在下面的评论中与我联系，或者直接在hi@iremkaraoglu.com。
The postStoryboard vs. programmatically for iOS app UI designappeared first onLogRocket Blog.
