在iOS编程中使用Storyboard而不是xib文件有什么好处?

使用Storyboard和xib文件的主要区别是什么?

具体来说,使用Storyboard有哪些优缺点

不幸的是,尽pipe做了相当多的研究,但在Storyboard上能find的只是一个简单的教程,告诉你如何设置一个Storyboard,而不是具体的信息来解释它们是什么。

故事板是:

  • 所有场景的容器(视图控制器,导航控制器,TabBar控制器等)
  • 这些场景之间的连接和转换pipe理器(这些被称为Segues)
  • 一个很好的方法来pipe理不同的控制器如何互相交谈
  • 故事板让你全面了解你的应用程序的stream程,你永远不会从浮动的单独的笔尖文件中获得。
  • 当你有几个控制器,每个都有它自己的nib文件时,发生所有“混乱”的减速器。

我一直在使用Storyboards,唯一的缺点是你不能瞄准iOS 4或更低版本。 故事板仅适用于运行iOS 5或更高版本的设备。 除此之外,好处是很多,缺点是IMO不存在。

我见过的最好的教程是Ray Wenderlich的

另外,如果你是苹果开发者计划的成员,去看看去年的故事板(iTunesU)上的WWDC会议,这是真棒。

另一个伟大的(也在iTunesU上)是最新的斯坦福大学iOS应用程序编程课程。

故事板不仅有正面,也有缺点 – 只是因为你要求input:

  • 与团队中的SB一起工作并不容易,因为只有一个参与者可以同时在SB上工作(因为它是一个文件)。

– 以下是不正确的: – 如果你需要做SB没有提供的东西,那么把SB与编程创build的视图混合起来并不是一件容易的事(但是,尽pipe这是可能的)

经验法则似乎是:你期望你的项目越复杂,你最好不要去SB。

编辑:SB的另一个缺点:解决所有关于SB的XCode的烦人的错误。 比如不得不频繁刷新DerivedData文件夹,因为有一些不一致的地方。 有时故事板文件或链接到他们被损坏。 那么你可能会喜欢寻找这个问题。 看看这个线程得到的想法

编辑2(2013年3月):故事板和Xcode工作得更好,文档和最佳实践广泛传播。 我认为与故事板的合作可以被推荐用于大多数的项目,即使还有一些小故障。

编辑3(2013年9月):现在与新的Xcode 5格式与SB团队工作可能会变得更好,因为它似乎变得可以合并SB代码更容易了。

另一个编辑:好吧,如果你有一个小时的时间,坐下来,放松, 听听这些讨论这个话题的家伙(Ray Wenderlich&Co)

编辑2016.1:经过很长一段时间的故事板的倡导者之后,我在过去的几个月里有这么多的麻烦,我决定尽可能地放弃故事板。 原因是苹果增加了像愚蠢的function,但不关心错误和缺陷。 具有大量自动布局约束的性能非常糟糕(而devise时间),并且容易出错的性能变得非常大。 例如:更简单的故事板在Xcode中打开一个项目后,往往会进入“脏模式”(请参阅​​git状态)。 提示:作为一个初学者,你会喜欢故事板,因为你可以快速原型,让事情运行没有太多的代码。 当你进入一个中间状态,你会添加更多的GUI代码到你的项目。 现在你开始在代码和SB之间来回切换,事情开始变得更糟。 迟早你会倾向于在代码中执行大部分GUI工作,因为结果比有多个源更容易预测。

概要

Nibs / .xib文件和Storyboard都是Interface Builder文件,用于在Xcode中为iOS和Mac应用程序直观地创build用户界面(我将使用iOS术语作为此类问题标记为iOS的术语,但也适用于Mac编程) 。

差异

笔尖旨在与单个UIView一起使用。 通过设置File的Owner类到UIViewController任何子类并连接视图sockets(使用Xcode的最右侧窗格中的Connections Inspector进行连接),它们也可以连接到UIViewController子类。

故事板旨在包含一个或多个UIViewController的用户界面。 您可以在单个故事板中构build整个用户界面,也可以将其分成较小的部分。

优点

应始终使用故事板,以支持.xib文件/ Nib(视图控制器)。 故事板有更多的function,并由苹果积极开发。

每个支持Nibs的论点都依赖于他们单独使用的事实,而故事板包含许多场景。 您可以像使用Nib一样轻松地为每个UIViewController使用单个故事板(请参阅下面的代码示例)。 请继续阅读以获得详细的解释和代码示例。

详细

为什么Storboard优于Nibs?

答案基本上归结为苹果鼓励使用Storyboard并将更多的开发工作付诸于其中。

  1. 故事板具有Nibs缺乏的缩放function。 严重的是,你不能放大缩小在笔记本电脑大屏幕devise时吸吮。
  2. 笔尖缺less如下关键function:
    • UITableView原型和dynamic单元( 更多信息 )
    • 顶部布局指南属性(请参阅评论)
    • 有可能更多,请编辑或评论,如果你有什么要添加到这个列表
  3. 你不需要搞乱设置文件所有者的类。

反对故事板的基本观点是,将所有的视图控制器放在一个地方会导致合并冲突,缓慢的Xcode,缓慢的构build时间,并成为维护对象的普遍痛苦。 因此,一般的build议是为每个UIViewController使用一个Nib。

但是…您可以为每个UIViewController创build故事板。 一个普遍的习惯(至less对我来说)是将所有的UIViewController初始化隐藏在类方法中(因为没有其他类需要知道控制器的Nib / Storyboard所在文件的名称)。 让我们比较一下可能用来创build这种方法的相关代码片段。 一行代码是两者之间的全部区别。

Objective-C的

故事板

 + (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 } 

笔尖

 static func create() -> ViewController { return ViewController(nibName: "ViewController", bundle: nil) } 

用法

 func showMyViewController() { let vc = ViewController.create() self.presentViewController(vc, animated: true, completion: nil) } 

参数

我会解决所有关于尼布斯的常见论点。 正如我前面提到的,主要是支持单个文件,而不是作为故事板上的Nibs的参数

  1. 团队和合并

参数:如果您正在与多人进行更改的团队一起工作,则拥有大量视图控制器的故事板会导致合并冲突

回应:单个故事板不会导致比单个Nib更多的合并冲突

  1. 复杂

参数:非常复杂的应用程序在故事板中有很多场景,导致一个巨大的故事板需要永久加载,并且由于其尺寸而难以理解。

回应:这是一个很好的观点,但是您可以轻松地将Storyboard分解成更小的部分。 故事板参考看起来像一个很棒的function,可以用来将故事板链接在一起,但它们只能在Xcode 7 / iOS 9+中使用。 此外,仍然不是select故事板上的单个Nibs的原因。

  1. 可重用性

参数:为每个UIViewController子类创build一个Nib让您重用代码,所以您不必为故事板中的每个场景设置所有约束和出口。

回应:同样,不是select个别故事板上的个别Nibs的理由。

在几个月前的LiDG会议上,有关Storyboard的一个很好的演示 。

就个人而言,我会说这是一个新的应用程序的方式。 有一些差距,尤其是对于非常复杂的应用程序,但亲们主要是大于缺点。

故事板的更多优点:

  • 故事板对桌面视图有更好的支持。 那就是你可以使用“dynamic”和“原型”单元。
  • 使用故事板实例化视图控制器更容易。 你可以做这样的事情:[se lf.storyboard instantiateViewControllerWithIdentifer:]
  • 故事板支持视图控制器容器,所以你可以让子视图控制器以graphics方式布局。

缺点是:

  • 当XCode包含大量视图控制器时,故事板渲染缓慢

  • 故事板中的一个视图控制器不能启用Autolayout。

要小心,如果您使用Storyboard,则您的应用程序不能与旧版OS安装向后兼容。

故事板基本上是一个使您的开发工作更容易的设备。 它被编译成一系列的nib文件,所以性能几乎相当,但作为开发人员能够快速查看整个应用程序stream程,这非常棒。

我开始转向在新项目中使用情节提要,只要我能说服客户接受iOS 5作为最低版本。 这纯粹是因为我喜欢这样做,而且要花更less的时间完成相同的任务。

您对自动布局的态度也可能会影响您是否要使用情节串连图板。 使用xibs,你可以启用或禁用自动布局,每个.xib的基础上,允许你的应用程序混合,而故事板适用于你所select的所有视图,其中包含。

你一秒钟就能看到大局。 有很多的NIB文件,好吧,你看不到大的图片。 更容易维护您的程序。 更容易理解别人的节目…等等。

优点:

1)devise界面非常好

2)您可以使用StoryBoard Segues以冷静的方式识别导航/模式关系。

3)如果你的应用程序支持多种设备,这是组织不同视图的好方法。

4)原型是另一个附加优势。

5)原型UITableViewCell可以节省时间,也可以减less代码量。

6)通过使用StoryBoard,你可以在一个地方看到应用程序的所有屏幕。

7)您可以轻松查看它们之间的关系

8)如果您正在处理某人的代码,您可以更好地了解应用程序的stream程。

9)你可以设置iPhone 4和iPhone 5的用户界面,通过应用故事板的视网膜形状因子,而无需反复运行应用程序。

10)在开始开发之前,客户可以看到应用程序的原型,这里storyboard可以帮助你很多。

缺点:

1)它只适用于iOS 5+

2)StoryBoardSegues是僵硬的,你可以多次使用prepareForSegue。

4)像IB一样,与其他显示引擎和工具包不太友好。

4)很难分享devise的一个单一的观点或意见 – 你必须发送全部或没有。

5)对于故事板,您将需要一个专门用于iPad的大屏幕。

6)从其他应用程序复制到故事板的难度。

7)当多个开发人员使用git仓库在同一个项目上工作时,故事板中的问题

8)故事板没有提到的另一个缺点是

从一些资源复制

在iOS 7之前,故事板是一种整洁,但不是必须的。 他们解决了许多问题。 iOS 7向故事板倾斜平衡。

使用iOS 8和9,这不再是一个问题:使用故事板!

故事板的主要缺点是,你完全依赖于XCode,而最终你可能花费数小时在XCode上运行。 但是,XCode已经变得更好了,故事板的优势现在已经不胜枚举了。 表格视图单元格原型,大小类,自动布局支持等等。

一些技巧:

  • 将每个Storyboard视为属于一个视图控制器的容器。 不要把它看作是整个应用程序的macros伟布局。
  • 您可能需要多个Storyboard
  • Segmentation对于最微不足道的用例实际上是有用的 – 对于这些用例来说非常有用。 但是在现实世界的应用程序中,许多转换将从代码中发生。 这没关系。
  • 编写一个类别以编程方式从storyboard(s)实例化视图控制器,所以你所要做的就是让vc = SomeViewController.create(),其中方法处理所有的细节(拉故事板,把视图控制器拉出故事板等)。