使用故事板和xib文件的主要区别是什么?
具体来说,使用故事板的优缺点是什么?
不幸的是,尽管进行了相当多的研究,但我所能找到的有关故事板的信息都只是简单的教程,仅仅告诉你如何设置一个故事板,而没有具体解释它们是什么。
使用故事板和xib文件的主要区别是什么?
具体来说,使用故事板的优缺点是什么?
不幸的是,尽管进行了相当多的研究,但我所能找到的有关故事板的信息都只是简单的教程,仅仅告诉你如何设置一个故事板,而没有具体解释它们是什么。
故事板(Storyboard)是:
我现在已经使用故事板一段时间了,唯一的缺点是无法针对iOS 4或更低版本进行。 故事板仅适用于运行iOS 5或更高版本的设备。 除此之外,优点很多,缺点在我看来不存在。
我看过的最好的教程是Ray Wenderlich's
此外,如果你是苹果开发者计划的成员,请查看去年WWDC关于故事板的会议(iTunesU),非常棒。
另一个很棒的教程(也在iTunesU上)是最新的Stanford iOS应用程序编程课程。
使用Storyboard有利也有弊,以下是一些缺点:
-以下陈述不正确: -如果您需要使用SB无法提供的功能,则很难将SB与编程创建的视图结合使用(尽管可能是可行的)
经验准则是:您预计项目变得越复杂,则最好不要选择SB。
编辑: -SB的另一个缺点:解决XCode中所有讨厌的SB错误。例如,由于多个不一致性,经常需要清空DerivedData文件夹。有时Storyboard文件或链接会损坏。然后,您可能需要寻找问题所在。请查看此线程以了解详情。
编辑2(2013年3月):与此同时,Storyboards和Xcode运行效果更好,并且文档和最佳实践已经广泛传播。我认为对于大多数项目来说,可以推荐使用故事板,即使仍然存在一些小问题。
编辑3(2013年9月):现在随着新的Xcode 5格式,使用SB在团队中的效果可能会更好,因为似乎现在可以更容易地合并SB代码了。
另一个编辑:如果你有一小时的时间,请坐下来,放松,听听这些人讨论这个话题(Ray Wenderlich & Co)。
编辑于2016年1月:长期以来,我一直是Storyboard的支持者,但是在过去几个月里,我与之遇到了很多麻烦,因此我决定尽可能地放弃使用Storyboard。原因是苹果公司添加了许多愚蠢的功能,但并不关心错误和缺陷。具有许多自动布局约束的性能真的很差(在设计时),而出错的可能性变得非常大。 例如:即使是更简单的Storyboard,在在Xcode中打开项目后也会进入“脏模式”(见git状态)。 提示:作为初学者,你会喜欢Storyboard,因为你可以快速进行原型设计并运行,而不需要很多代码。当你进入中级阶段时,你将向你的项目中添加更多GUI代码。现在你开始在代码和SB之间来回切换 - 事情开始变得更糟。迟早你会倾向于在代码中完成大部分的GUI工作,因为结果比有几个来源更可预测。
Nibs/.xib文件和Storyboards都是Interface Builder文件,用于在Xcode中为iOS和Mac应用程序创建用户界面(由于此问题标记为iOS,因此我将使用iOS术语来表示类,但它也适用于Mac编程)。
Nibs旨在与单个UIView
一起使用。它们还可以通过将File's Owner的类设置为任何UIViewController
子类并连接视图出口(使用Xcode右侧窗格中的Connections Inspector进行拖动连接)与UIViewController
子类相连。
Storyboards旨在包含1个或多个UIViewController
的用户界面。您可以在单个storyboard中构建整个用户界面,也可以将其分成更小的部分。
应始终使用Storyboards而不是.xib文件/Nibs(对于视图控制器)。Storyboards具有更多功能,并由Apple积极开发。
每个支持Nibs的论点都依赖于它们被单独使用,而故事板包含许多场景。您可以像使用Nibs一样轻松地为每个UIViewController
使用单个Storyboard(请参见下面的代码示例)。继续阅读以获取详细说明和代码示例。
为什么Storboards优于Nibs?
基本上答案归结为Apple鼓励使用Storyboards并将更多开发工作投入其中。
反对故事板的基本论点是将所有视图控制器放在一个地方会导致合并冲突、Xcode 缓慢、构建时间长,并且维护起来非常麻烦。因此,一般建议为每个 UIViewController
使用一个 Nib。
但是... 您可以为每个 UIViewController
创建故事板。一个常见的做法(至少对我来说)是将所有 UIViewController 的初始化隐藏在一个类方法中(因为没有其他类需要知道控制器的 Nib/Storyboard 存储位置的名称)。
让我们比较一下可能用于创建此类方法的相关代码片段。一行代码是两者之间的全部区别。
Storyboard
+ (ViewController *)create
{
UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil];
return [storyboard instantiateInitialViewController];
}
齿轮
+ (ViewController *)create
{
return [super initWithNibName:@"ViewController" bundle:nil];
}
使用方法
- (void)showMyViewController
{
ViewController *vc = [ViewController create];
[self presentViewController:vc animated:YES completion:nil];
}
故事板
static func create() -> ViewController {
let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle())
return storyboard.instantiateInitialViewController() as! ViewController
}
Nib
static func create() -> ViewController {
return ViewController(nibName: "ViewController", bundle: nil)
}
使用方法
func showMyViewController() {
let vc = ViewController.create()
self.presentViewController(vc, animated: true, completion: nil)
}
我将讨论所有关于Nibs的常见参数;正如我之前提到的,这些大多数是支持单个文件的,而不是支持Nibs而不是Storyboards的参数。
参数:如果您与多个人一起工作,则具有许多视图控制器的Storyboard会导致合并冲突。
回应:单个Storyboard与单个Nib一样不会引起更多合并冲突。
参数:非常复杂的应用程序在Storyboard中有很多场景,这导致一个巨大的Storyboard需要很长时间才能加载,并且由于其大小几乎无法理解。
回应:这是一个很好的观点,但您可以轻松地将Storyboard分成较小的部分。Storyboard References看起来是一个很棒的功能,可以用于链接Storyboard,但它们仅在Xcode 7 / iOS 9+中可用。此外,这仍然不是选择单独的Nib而不是Storyboard的原因。
论点:为每个UIViewController
子类创建一个Nib文件,可以使您重用代码,这样您就不必为故事板中的每个场景设置所有约束和插座。
回应:同样,这并不是选择单独的Nib文件而不是单独的故事板的理由。
故事板的其他好处:
缺点是:
当故事板包含大量视图控制器时,在XCode中渲染速度较慢。
无法在故事板中为一个视图控制器启用自动布局。
几个月前在LiDG会议上有一场关于Storyboard的精彩演讲,这里可以看到。
个人认为对于新应用程序来说,Storyboard是可行的方式。虽然对于非常复杂的应用程序存在一些缺陷,但优点大多数情况下胜过缺点。
请注意,如果您使用故事板(Storyboards),您的应用程序将不兼容旧版操作系统安装。
故事板基本上是一种使开发者工作更轻松的工具。它被编译成一系列的nib文件,因此性能几乎相同,但对于开发者来说,能够快速查看整个应用程序流程的概述非常棒。
我开始转向在新项目中使用故事板,只要我能说服客户接受iOS 5作为最低版本。这纯粹是因为我更喜欢这样做,并且完成相同任务所需的时间更少。
故事板的问题比好处多得多。以下是它们的问题列表,从iraycd复制:
故事板在运行时失败,而不是在编译时失败:您的故事板中有拼写错误的segue名称或连接不正确?它会在运行时崩溃。您在故事板中使用了一个自定义的UIViewController子类,但在故事板中不存在?它会在运行时崩溃。如果您在代码中执行此类操作,您将在编译时及早捕获它们。 更新:我的新工具StoryboardLint大多解决了这个问题。
故事板很快变得令人困惑:随着项目的增长,您的故事板变得越来越难以导航。此外,如果多个视图控制器具有多个segue到多个其他视图控制器,则您的故事板很快就会看起来像一碗意大利面条,您将发现自己在缩放和滚动中寻找您正在寻找的视图控制器和查找segue指向何处。 更新:通过将您的故事板拆分为多个故事板,可以解决此问题,如Pilky的本文和Robert Brown的本文所述。
故事板使团队合作更加困难:因为您通常只有一个用于整个项目的巨大故事板文件,让多个开发人员定期对该文件进行更改可能会令人头痛:更改需要合并和解决冲突。当发生冲突时,很难确定如何解决它:Xcode生成故事板XML文件,它实际上并不是以人类将要阅读,更不用说编辑它的目标而设计的。
故事板使代码审查变得困难或几乎不可能:同行代码审查是团队中要做的好事情。但是,当您对故事板进行更改时,几乎不可能使用不同的开发人员审查这些更改。您可以拉出的只是巨大XML文件的差异。弄清楚到底发生了什么变化,这些变化是否正确或是否破坏了某些内容,真的很难。
故事板阻碍了代码重用:在我的iOS项目中,我通常创建一个包含我在整个应用程序中使用的所有颜色、字体、边距和插图的类,以使其具有一致的外观和感觉:如果我必须为整个应用程序调整这些值,只需更改一行即可。如果您在故事板中设置此类值,则会重复它们,并且需要找到每个单独的实例以进行更改。有很大的机会你会错过其中一个,因为在故事板中没有搜索和替换。
故事板让您做两次工作:您是否正在构建可以在iPad和iPhone上运行的通用应用程序?当您使用故事板时,通常会有一个用于iPad版本的故事板和一个用于iPhone版本的故事板。保持两者同步需要您在两个位置上进行每个UI或应用程序工作流更改。耶。更新:在iOS 8和Xcode 6