ios纯代码开发界面_ios查看代码与界面生成器的比较

ios纯代码开发界面

[Thanks to my cowriter Rodrigo Maximo]

[感谢我的合著者 Rodrigo Maximo ]

介绍 (Introduction)

This is the first of a series of two articles in which we are going to discuss two different ways for designing iOS views and screens: Interface Builder’s Storyboards and Xibs, and plain old view coding.

这是两篇系列文章中的第一篇，我们将讨论设计iOS视图和屏幕的两种不同方法：Interface Builder的Storyboard和Xibs，以及普通的旧视图编码。

By no means we are forgetting about SwiftUI, the new Swift-only Apple framework, which gives us the experience of view coding and interface builder both at the same time, and has advantages and disadvantages of it’s own. But getting into those is not this article’s purpose.

我们决不会忘记SwiftUI，这是一个新的仅限Swift的Apple框架，它为我们提供了视图编码和界面生成器的体验，同时具有其自身的优点和缺点。 但是进入这些不是本文的目的。

Pros and Cons of both approaches will be presented along with some considerations over the subject. On the next article of this series, we are going to present some examples and personal experiences to make our points clearer and help those who are new to View Code.

将介绍这两种方法的优缺点，以及对该主题的一些考虑。 在本系列的下一篇文章中，我们将提供一些示例和个人经验，以使我们的观点更加清楚，并帮助那些不熟悉View Code的人。

Finally, we are going to overview the main points discussed, and why, nowadays, we tend to choose view coding for designing iOS apps over Xibs and Storyboards.

最后，我们将概述所讨论的要点，以及为什么现在我们倾向于选择视图编码来通过Xibs和Storyboard设计iOS应用。

一些定义 (Some definitions)

First, let’s put everyone on the same page about the key words we are going to mention in this article.

首先，让每个人都在同一页上谈论我们将在本文中提及的关键词。

• Interface Builder is an editor within Xcode which makes it simple to design a full user interface without writing any code.

  Interface Builder是Xcode内的一个编辑器，可轻松设计完整的用户界面而无需编写任何代码。

• Storyboard is a visual representation of the user interface of an iOS application, showing screens of content (view controllers and its views) and the connections/transitions between those screens.

  故事板是iOS应用程序用户界面的直观表示，显示内容的屏幕(视图控制器及其视图)以及这些屏幕之间的连接/过渡。

• A xib file correspond to a view element and can also be laid out in the Interface Builder, allowing developers to create and manipulate user interfaces graphically instead of programmatically.

  xib文件与view元素相对应，并且也可以在Interface Builder中进行布局，从而使开发人员可以图形方式(而不是编程方式)创建和操作用户界面。

• View Coding as the name might suggest refers to designing view elements without the visual tools of Interface Builder, doing so programmatically, so writing code.

  顾名思义，“ 视图编码”是指在没有Interface Builder可视工具的情况下设计视图元素，以编程方式进行，因此编写代码。

首选情节提要 (Preferring Storyboard)

更容易学习 (Easier to learn)

We believe most iOS developers might have worked on at least one project with Storyboards and Xibs, since it is probably one of the first things learned about iOS.

我们认为大多数iOS开发人员可能至少已经使用Storyboards和Xibs进行过一个项目，因为这可能是从iOS中学到的第一件事。

This is probably how most of us learned how to build our first screens and oh, wasn’t that a thrill? Being able to just drag some elements around and have a working screen flow.

这可能就是我们大多数人学会了如何制作第一个屏幕的方法，哦，那不是很激动吗？ 能够在周围拖动一些元素并具有有效的屏幕流程。

That’s is definitely one of the main features when anyone thinks of Storyboards: how easy it is to learn and make something functional. This is mainly due to the its visual aspect.

绝对是任何人想到Storyboard的主要功能之一： 学习和使某些功能变得容易 。 这主要是由于其视觉方面。

Hearing about constraint setup programmatically may cause shivers on some developers. Yes, it can be verbose and even a bit boring, what definitely would demand more time to be implemented, and of course the learning curve is also slower, specially for beginner developers.

以编程方式听到约束设置的声音可能会使某些开发人员感到不安。 是的， 它可能很冗长，甚至有些无聊，这肯定会需要更多的时间来实施， 当然， 学习曲线也较慢 ，特别适合初学者。

更好地进行原型制作 (Better for Prototyping)

Storyboard are meant to be what the name suggests: a board that tells a story. That means their purpose is to allow us to design our views and view controllers and connect them in a meaningful way that tells the story of our iOS app. When we create these connections, storyboard takes care of the transitions between screens. That’s one of the reasons why they are so great for prototyping: with barely any code it’s possible to have screens designed and navigating through each other.

故事板的名称应为：讲述故事的板。 这意味着它们的目的是允许我们设计视图和视图控制器，并以有意义的方式将它们连接起来，以讲述我们iOS应用程序的故事。 创建这些连接时，情节提要会处理屏幕之间的过渡。 这就是为什么它们如此出色的原型的原因之一：几乎没有任何代码，就可以设计屏幕并在彼此之间导航。

Interface Builder上的实时视觉反馈 (Real time visual feedback on Interface Builder)

This is precisely where view coding falls behind Interface Builder approaches. View Coding configures it self by designing views and layouts using solely code. Therefore, one has to programmatically create and position views and components, using Auto Layout APIs to do so, without any visual feedback whatsoever on how the layout will look once the app is running. This may seem like a huge downside of building views programmatically. One may think each iteration shall take an eternity, once you need to run the app every time a visual alteration is made, what may be another negative point about View Code.

这正是视图编码落后于Interface Builder方法的地方。 View Coding通过仅使用代码设计视图和布局来自行配置。 因此，必须使用Auto Layout API来以编程方式创建视图和组件，并对其进行定位， 而无需任何视觉反馈，即关于应用程序运行后布局的外观 。 这似乎是以编程方式构建视图的巨大缺点。 可能有人认为每次迭代都将花费一个永恒的时间，一旦您需要在每次进行视觉更改时都运行该应用程序 ，那么关于View Code的另一个负面点可能就是 。

处理尺寸等级时更容易 (Easier when dealing with size classes)

Also, storyboards are super handy when it comes to designing apps for multiple screen sizes and orientations. For layout adaptability we use Auto Layout, through which rules (constraints) are defined to govern the content of the layout. It automatically readjusts layouts according to the specified constraints when certain environmental variations (known as traits) are detected. Auto Layout can be used regardless the means chosen to design app views, however, storyboards make it fairly easy to configure layouts for different screen sizes, via Size Classes, traits that are automatically assigned to content areas based on their size.

此外， 在为多种屏幕尺寸和方向设计应用程序时 ， 情节提要板非常方便 。 为了使布局适应性，我们使用“自动布局”，通过该规则定义规则(约束)来控制布局的内容。 当检测到某些环境变化(称为特征 )时，它将根据指定的约束条件自动重新调整布局。 无论选择哪种方式来设计应用程序视图，都可以使用“自动布局”，但是， 情节提要通过“大小类” (根据其大小自动分配给内容区域的特征)使配置不同屏幕大小的布局变得相当容易 。

Nevertheless, besides all the goodies storyboards can bring in some circumstances, they can also be become an utter pain in many situations.

尽管如此，除了所有的好东西故事板可以在某些情况下使用之外，它们在许多情况下也可能会变得非常痛苦。

首选查看代码 (Preferring View Code)

易于将不同文件中的视图分开 (Easier to separate views in different files)

A fairly common mistake developers make on their projects is to have a single Storyboard to tell the story of their whole application. That might work for small projects, but as projects get bigger and more complex, this single storyboard becomes a nightmare because of the quantity of screens.

开发人员在项目中犯的一个相当普遍的错误是只有一个Storyboard来讲述整个应用程序的故事。 这可能适用于小型项目，但是随着项目变得越来越大和越来越复杂， 由于屏幕数量众多 ，这个故事板成为噩梦 。

文件渲染和打开速度更快 (Files render and open much faster)

Also, depending on the size of this little monster, the file can take plenty of time to be opened on Xcode, if it doesn’t cause it to crash. The right way to handle this would be to use Storyboard References, and breaking the app into multiple storyboard files. But even though, depending on how long the flow is, its storyboard file may still be a heavy one. However, using View Code allows us to create multiple files and classes and separate them as much as possible. So, Xcode will not complain about opening each one of those files. Besides, despite the fact we have to run the app every time we’d like to see visual changes of view code implementations, if we take into consideration that the app will be lighter and faster to build without all the overhead of storyboards and xibs, in the end you may even find it is faster than Interface Builder real time rendering.

另外，根据这个小怪物的大小，如果它不会导致崩溃，则可能需要花费大量时间在Xcode上打开文件 。 解决此问题的正确方法是使用情节提要引用，然后将应用拆分为多个情节提要文件。 但是，即使根据流的时间长短，其情节提要文件仍可能是沉重的文件。 但是，使用View Code可以创建多个文件和类，并尽可能地将它们分开。 因此， Xcode不会抱怨打开其中的每个文件。 此外，尽管事实上我们每次都想查看视图代码实现的视觉变化时都必须运行该应用程序，但是如果我们考虑到该应用程序的构建将变得更轻，更快，并且没有情节提要和xib的所有开销， 最后，您甚至可能会发现它比Interface Builder实时渲染更快。

组件化 (Componentization)

This possibility of separation of concerns allows us to have great capacity of reusability and componentization. We can create view component and build more complex views by composition or even inheritance. As we are working with plain code, every technique we have for system componentization and reusability can be used with our views. This allows us to better organize, separate concerns and have purpose clarity for each file and view.

关注点分离的这种可能性使我们具有很大的可重用性和组件化能力 。 我们可以创建视图组件，并通过组合甚至继承来构建更复杂的视图。 当我们使用普通代码时，我们用于系统组件化和可重用性的每种技术都可以与我们的视图一起使用。 这使我们可以更好地组织，分开关注点，并为每个文件和视图明确目的。

While storyboards don’t offer anything regarding view reusability (if you have a round button that is used throughout the whole app and you are using only storyboard, be prepared to redesign that button on every single screen), a certain level of componentization can also be achieved by using xibs. Since each xib file is supposed to represent a single view, component views can be created on their own xib files and afterwards used to compose other xib views or even storyboard views. That way, instead of having to go over every label on every storyboard if the app’s color palette changes, we could go straight to our custom label component and change that color and, voillá, may all the labels be changed. But, despite the possibility of composing with xibs, we can’t say the same about inheritance.

虽然情节提要板不提供有关视图可重用性的任何内容(如果您在整个应用程序中使用了一个圆形按钮，而您仅使用情节提要，请准备在每个屏幕上重新设计该按钮)，但一定程度的组件化也可以通过使用xibs可以实现。 由于每个xib文件都应表示一个视图，因此可以在自己的xib文件上创建组件视图，然后再用于组成其他xib视图甚至情节提要视图。 这样，如果应用程序的调色板发生更改，则不必遍历每个情节提要上的每个标签，我们可以直接转到自定义标签组件并更改该颜色，并且可以更改所有标签。 但是，尽管有可能使用xib进行合成，但关于继承我们不能说相同的话。

Yes, inheritance can be done with xibs, but it can get quite messy. Suppose you have a view A inheriting from view B. Problems start once you can only inherit from this xibs File owner — a.k.a. its code implementation. That means all the layout has to be re-built on two different xibs files and IBOutlets need to be re-linked (you would have too labels linked to the same outlet). The mess continues once changes need to be made to B view, for example. Imagine you add an extra label to it and create its outlet on view B file and so on. Xcode won’t give any warning that you also need to add that new label to view A xib file and link it to the new outlet. For your surprise, when running the app, all instances of view B will work just fine, but when trying to instantiate view A, your app will crash. And, specially if you are new to the project, these crashes can be pretty darn hard to identify.

是的，可以使用xibs进行继承， 但是它会变得非常混乱 。 假设您有一个视图A从视图B继承。一旦您只能从该xibs文件所有者(即其代码实现)继承，问题就会开始。 这意味着必须在两个不同的xibs文件上重新构建所有布局，并且需要重新链接IBOutlets (您也将标签链接到同一出口)。 例如，一旦需要对B视图进行更改，混乱就会继续。 想象一下，您为其添加了一个额外的标签，并在视图B文件上创建了它的出口，依此类推。 Xcode不会发出任何警告，提示您还需要添加新标签来查看xib文件并将其链接到新插座。 令您惊讶的是，在运行该应用程序时，视图B的所有实例都可以正常工作，但是在尝试实例化视图A时， 您的应用程序将崩溃。 而且，特别是如果您是该项目的新手，这些崩溃可能很难识别。

可重用性和集中通用功能 (Reusability and Centralize common features)

Related to what was said above, and also another advantage of View Code in terms of reusability is the possibility to have a property to centralize a common characteristic for a view. For example, if we have a three labels that should have the same color, in the xib or storyboard we have to set the color for each one. Then, if this color should be changed, we have to change for the three labels, while with View Code we could have a property for this color, and attribute it for each label. Of course this could be done using xibs, just by adding this same property to its file owner swift class. But that brings us to another very important point when thinking of using Interface Builder: code always wins, in a sense that, in the end, despite of what you do on storyboards or xibs, if there is code overriding this behavior, what was defined on code will prevail. When you don’t have everything centralized on code, finding out why something set on Interface Builder is not reflecting how expected in the app can be a great source of headaches.

与上面所说的有关，View Code在可重用性方面的另一个优点是可以具有集中视图共同特征的特性 。 例如，如果我们有三个应该具有相同颜色的标签，则在xib或情节提要中，我们必须为每个标签设置颜色。 然后，如果应该更改此颜色，则必须更改三个标签，而使用查看代码，我们可以为该颜色设置属性，并为每个标签赋予属性。 当然，这可以通过使用xibs来完成，只需将相同的属性添加到其文件所有者swift类中即可。 但这使我们想到了使用Interface Builder时的另一个非常重要的观点： 代码总会获胜 ，从某种意义上说，最终，尽管您在情节提要或xib上做了什么，但如果有代码覆盖了此行为，则定义了什么以代码为准 。 当您没有将所有事情都集中在代码上时，请找出为什么在Interface Builder上设置的某些内容不能反映应用程序中的期望可能会令人头疼。

动画和基于内容的布局 (Animations and Content Based Layouts)

There are also some things that can only be done through code. One such example are animations. Sure, IBDesignable and IBInspectable (attributes used by Interface Builder used to render elements directly in Interface Builder) can be used, but still we would have to implement the animation on code. Complex layouts that greatly depend on the content being presented (dynamic content fetch from server for example) are much easily implemented using view code. That’s because you will only have the info needed for display on run time, therefore, only on the swift class of the view. Based on that content, constraints will need to be changed, views added or hidden, colors set and etc. Even if you had a xib file defining basic layout for that view, its behavior would mostly be overwritten when running the app by the code underneath handling the content.

还有一些事情只能通过代码来完成。 这样的例子就是动画。 当然，可以使用IBDesignable和IBInspectable ( Interface Builder用于直接在Interface Builder中渲染元素的属性)，但是仍然需要在代码上实现动画。 很大程度上取决于呈现内容的复杂布局(例如，从服务器获取动态内容)很容易使用视图代码实现。 这是因为您将仅具有在运行时显示所需的信息，因此仅在视图的swift类上具有。 根据该内容，将需要更改约束，添加或隐藏视图，设置颜色等。即使您有一个xib文件定义了该视图的基本布局，在运行应用程序时，其行为也会被其下的代码覆盖处理内容。

合并与审查 (Merge and Review)

Another point that can be really annoying with storyboards and xibs, specially if the project contains all the screens in a single Storyboard file, is working with other developers and having to deal with merge conflicts and pull request reviews. Since a storyboard or a xib file are basically autogenerated XML files, it’s really hard to accomplish these two things. Imagine you’re going to review a Pull Request that has some storyboard changes. How do you know what was changed and if these changes achieve their goals? (specially taking into consideration that Xcode generates changes on these files simply by opening them) You probably don’t. Meanwhile, when using View Code those problems don’t happen. Code is semantic, code has meaning. Every line of code changed has a clear purpose that anyone working on the project should understand, making reviews more meaningful and accurate.

情节提要和xib可能会令人烦恼的另一点是，特别是如果项目将所有屏幕都包含在一个情节提要中，则是与其他开发人员一起工作，并且必须处理合并冲突和请求合并 。 由于情节提要或xib文件基本上是自动生成的XML文件，因此很难完成这两件事。 想象一下，您将要查看具有情节提要板更改的“拉取请求”。 您如何知道更改了哪些内容，以及这些更改是否实现了目标？ (特别考虑到Xcode只需打开它们即可在这些文件上生成更改)，您可能没有。 同时，使用View Code时不会发生这些问题。 代码是语义，代码具有含义。 更改的每一行代码都有一个明确的目的，任何从事该项目的人都应该理解，从而使审核更加有意义和准确。

Even though constraints API may not be the best (although iOS 11 and forth APIs are pretty decent), it is still code and therefore it has meaning and semantics to developers. When setting constraints on code the depth of knowledge acquired on how Auto Layout works is remarkable. It can get us really knowing our views, their hierarchy, how they are related trough constraints. And it’s guaranteed that you’ll finally learn what the hell compression resistance and content hugging priorities are for!

尽管约束API可能不是最好的(尽管iOS 11和第四API相当不错)，但它仍然是代码，因此对开发人员来说具有意义和语义。 当在代码上设置约束时，关于自动版式如何工作的知识深度是非凡的。 它可以使我们真正了解我们的观点，它们的层次结构以及它们与低谷约束的关系。 并且可以确保您最终了解地狱抗压缩性和内容拥抱优先级的用途！

Regarding verbosity, there are many 3rd party libraries out there to help with auto layout API’s readability. Cartography, SnapKit and PureLayout are just some examples. Using any of these 3rd parties or even newly Auto Layout APIs will sure make your constraints pretty understandable and maintainable.

关于详细程度，有许多第三方库可以帮助自动布局API的可读性。 制图 ， SnapKit和PureLayout只是一些示例。 使用这些第三方中的任何一个，甚至使用新的Auto Layout API都会确保使您的约束相当容易理解和维护。

单元测试 (Unit Tests)

Besides, a really terrible problem that storyboards generates is the impossibility of testing UIView and also UIViewController properties without opening the view properties access levels. This happens simply because when using storyboard, we don’t have the control during the view initialization. So, all its properties can be only referenced by outlets, and so they can’t be injected by dependency injection. This means the unique way to test them is making those properties not private. This is awful because leaves the code open to undesirable modifications, which can cause lots of side effects. However, using View Code, we can inject all the view properties by creating a custom init for the UI element (UIViewController, UIView, UITableViewCell, etc), what really makes unit tests easier and guarantees the right access levels..

此外，情节提要生成的一个真正可怕的问题是无法在不打开视图属性访问级别的情况下测试UIView和UIViewController属性 。 这是因为使用情节提要时，我们在视图初始化期间没有控件。 因此，其所有属性只能由出口引用，因此不能通过依赖项注入来注入。 这意味着测试它们的独特方法是使这些属性不私有。 这很糟糕，因为使代码易于进行不必要的修改，这可能会导致很多副作用。 但是，使用View Code， 我们可以通过为UI元素创建自定义init来注入所有视图属性 (UIViewController，UIView，UITableViewCell等)，这真正使单元测试更加容易并保证了正确的访问级别。

数据流 (Data Flow)

Still talking about the lack of initialization control Storyboards and xibs bring, it’s possible to perceive another disadvantages compared to View Code, since it’s harder to pass data between two UIViewController’s because of that. This happens because when we don’t create the UIViewControllers by code, and we allow Storyboards do this job for us, we can’t inject the properties we’d like in it. Doing this, a possible way to pass the data is through a segue, and this will bring us another problem, because we’re going to have an optional property in the final UIViewController, that is also not private. So, unnecessary safe guards and other optional unwrapping code will be needed for a property that in practice will never be nil.

仍然谈论故事板和xib带来的初始化控制的缺乏，与查看代码相比，可能会感觉到另一个弊端，因为因此很难在两个UIViewController之间传递数据 。 发生这种情况的原因是，当我们不通过代码创建UIViewControllers并允许情节提要为我们完成这项工作时，我们无法在其中注入所需的属性。 这样做，一种可能的方式是通过segue传递数据，这将给我们带来另一个问题，因为我们将在最终的UIViewController中具有一个可选属性，该属性也不是私有的。 因此，对于实际上永远不会为零的属性，将需要不必要的安全防护措施和其他可选的解包代码。

安全 (Safety)

View Code is also safer than Storyboards . By safer we mean that it is less prone to crashes. This is true because there are lots of identifiers we set in Storyboard, that will make our code to compile, but can cause some crash. Also, for example if we delete some outlet or action code, and we forget to delete the storyboard reference for this outlet, the code will compile successfully, but the app is going to crash when accessing that scene.

查看代码也比情节提要更安全 。 更加安全，是指它不太容易崩溃 。 这是正确的，因为我们在Storyboard中设置了很多标识符，这些标识符将使我们的代码得以编译，但可能会导致崩溃。 另外，例如，如果我们删除一些出口或动作代码，而忘记删除此出口的情节提要参考，代码将成功编译，但访问该场景时应用程序将崩溃。

本土化 (Localization)

In addition, something that is really easier when talking about View Code is localization. Implementing this in storyboards and xibs implies in having one different file for each new wanted localization, which may be terrible, since changes in the UI would have to be done in each file. However, there is a better way to localize a storyboard/xib, that is through the localization pane in File Inspector. This will create a new strings file for each localization, what solves this previous problem. Nevertheless, we still have a problem here, since the created strings file has each localized string defined by an id, which is automatically generated by Xcode, and it’s not something really readable. This is going to difficult our lives in a file with a lot of localized strings when some changes are needed.

另外，在谈论View Code时，真正真正容易的是localization 。 在情节提要和xib中实现此功能意味着对于每个新的所需本地化都有一个不同的文件，这可能很糟糕，因为UI的更改必须在每个文件中完成。 但是，有一种更好的方法可以通过文件检查器中的本地化窗格来本地化情节提要/ xib。 这将为每个本地化创建一个新的字符串文件，从而解决了先前的问题。 但是，这里仍然存在问题，因为创建的字符串文件具有由ID定义的每个本地化字符串，该ID由Xcode自动生成，并且不是真正可读的东西。 当需要进行一些更改时，这将使我们的生活陷入一个包含大量本地化字符串的文件中，这将很困难。

Obviously, we can overcome this problem by replacing them by View Code files, but we could also just attribute the NSLocalizedString’s in .swift files related to the storyboard/xib we want to localize, instead of using the File Inspector “trick” mentioned above.

显然，我们可以通过用View Code文件代替它们来解决此问题，但是我们也可以仅将.NS.Swift文件中的NSLocalizedString属性与要本地化的Storyboard / xib相关，而不必使用上述的File Inspector“技巧”。

加起来 (Summing Up)

In order to overview everything we discussed in this article, a list with every single advantage of each approach will be shown below.

为了概述我们在本文中讨论的所有内容，下面将列出具有每种方法的每个优点的列表。

Storyboard

故事板

• Easy to learn and create things that work
  易于学习和创建有用的东西
• Better for prototyping
  更好地进行原型制作
• Easier when dealing with size classes
  处理尺寸等级时更容易
• Real time visual feedback on Interface Builder
  Interface Builder上的实时视觉反馈

View Code

查看代码

• Easier to separate views in different files
  易于将不同文件中的视图分开
• Files render and open much faster than storyboard and xib files
  文件的渲染和打开速度比情节提要和Xib文件快得多
• It is possible to Inherit and Compound Views
  可以继承和复合视图
• We can take advantage from reusability and also centralize common features
  我们可以利用可重用性，也可以集中通用功能

• Much easier merge and review since files are code and not a unreadable XML’s

  由于文件是代码而不是不可读的XML， 因此合并和审阅更加容易

• Unit tests are easy to implement and they aren’t necessary to be built in a poor way, breaking the access level of properties
  单元测试易于实现，并且不需要以较差的方式构建，从而打破了属性的访问级别
• Easier data flow between screens
  屏幕之间的数据流更轻松
• Safer — no more unsafe functionalities in storyboards and xibs (crashes instead of build time errors)
  更安全-情节提要和xib中不再存在不安全的功能(崩溃而不是构建时间错误)
• Localization is easier
  本地化更容易
• Animations are only possible to be implemented by code
  动画只能通过代码实现

结论 (Conclusion)

Our intention is to share some knowledge and experience we both have using these two approaches for developing interfaces in iOS, and the main purpose here is not to convince the reader which one is better, but just to shed some light into each approach advantages and disadvantages. This does not mean there is always a better solution, but maybe a more suitable solution for your context and situation.

我们的目的是分享我们都使用这两种方法来开发iOS界面的知识和经验，这里的主要目的不是要说服读者相信哪种方法更好，而只是要了解每种方法的优缺点。 。 这并不意味着总会有更好的解决方案，而是可能会针对您的环境和情况提供更合适的解决方案。

Briefly, if we had to create a new project, with the purpose to be a large and scalable application, with a lot of users and with a lot of developers working on this, we would probably opt for View Code, due to merge and review facilities, compilation and rendering files time, unit tests, reusability and the possibility to centralize behaviors, composition and inheritance, and finally the safer environment (avoiding unexpected crashes).

简而言之，如果我们必须创建一个新项目，以成为一个大型且可扩展的应用程序，并且拥有大量用户和许多开发人员来进行此工作，由于合并和审查，我们可能会选择查看代码设备，编译和渲染文件的时间，单元测试，可重用性以及集中行为，组合和继承的可能性，最后是更安全的环境(避免意外崩溃)。

However, if for example we had to teach students or iOS beginners about auto layout and how to create some views, we might prefer storyboards.

但是，例如，如果我们必须向学生或iOS初学者讲授自动布局以及如何创建一些视图，则我们可能更喜欢情节提要。

To make all the arguments presented here more clear and relatable, the next article of this series will bring real life examples of how to build views using view code, how to better organize it and some tips and tricks to make the project even more readable and maintainable, and, hopefully, faster to build.

为了使此处提出的所有论点更加清楚和相关，本系列的下一篇文章将提供真实示例，说明如何使用视图代码构建视图，如何更好地组织视图以及一些技巧和窍门，以使项目更具可读性和可操作性。可维护的，并且希望更快地构建。

We hope you have enjoyed and feel free to leave feedbacks, suggest improvements or even send us some messages. 😄

我们希望您喜欢并随时留下反馈，提出建议或什至给我们发送消息。 😄

翻译自: https://medium.com/movile-tech/ios-view-code-a-comparison-with-interface-builder-189b1ff1935d

ios纯代码开发界面