代码手写UI，xib和StoryBoard间的博弈，以及Interface Builder的一些小技巧
最近接触了几个刚入门的iOS学习者，他们之中存在一个普遍和困惑和疑问，就是应该如何制作UI界面。iOS应用是非常重视用户体验的，可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮
最近接触了几个刚入门的iOS学习者，他们之中存在一个普遍和困惑和疑问，就是应该如何制作UI界面。iOS应用是非常重视用户体验的，可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关系。而随着iOS开发发展至今，可以说在UI制作上大家逐渐分化为了三种主要流派：使用代码手写UI及布局；使用单个xib文件组织viewController或者view；使用StoryBoard来通过单个或很少的几个（关于这点稍后会进行展开）文件构建全部UI。应该使用哪种方式来制作UI已经是iOS开发中亘古不变的争论话题了，或许永远不会有一个统一的结论。但是首先需要知道的是三种方式各有优劣，所以也各有自己最适用的场合，而不会有完全的孰优孰劣。对于初学iOS开发来说，一时间其实是很难判定最适合自己的UI架构方式的。在这篇文章里我希望能够通过自己的经验给出一些意见，以期能帮助入门者来挑选最适合自己应用场景的方案。对于老鸟的话，也不妨对照自己平日的使用习惯和运用场景，看看有没有可以改进或变化的地方。最后，因为我本人现在最习惯和喜欢的是用Interface Builder(之后简称IB)及xib来做UI，所以文末附上了一些IB使用时候的小技巧，算是做个总结。
代码手写UI
这种方法经常被学院派的极客或者依赖多人合作的大型项目大规模使用。Geek们喜欢用代码构建UI，是因为代码是键盘敲出来的，这样可以做到不开IB，手不离开键盘就完成工作，可以专注于编码环境，看起来很cool很高效，而且不到运行时大家都不知道会是什么样子，也显出了程序员这一职业的高大上及神秘气息（这个真的不是在黑..想想大家一起在设计师背后指点江山的场景吧）。大型多人合作项目使用代码构建UI，主要是看中纯代码在版本管理时的优势，检查追踪改动以及进行代码合并相对容易一些。
另外，代码UI可以说具有最好的代码重用性。如果你的目的是写一些可以高度重用的控件提供给其他开发者使用，那毫无疑问最好的选择应该是使用代码来完成UIView的子类。这样进一步的修改和其他开发者在使用时，都会方便不少。使用代码也是最为强大的，会有xib或者StoryBoard做不了的事情，但是使用代码最终一定能够完成所要的需求。
但是代码手写UI的劣势同时也是最明显的，主要就是一个字：慢。首先相比可视化的IB来说，完成一个并不太复杂的界面，你可能需要写上数百行的UI代码。不论是初始化一个Label，还是设定一个frame或者添加一个target-action，都需要写代码，这不仅在前期极为浪费时间，在之后维护时代码定位和寻找也会很痛苦。其次，因为你无法直观地看到你能得到的结果，所以你很可能需要不断地Cmd+R/Cmd+.来修改各个视图的位置大小。即使你用上了Reveal或者RestartLessOften之类的工具，也还是无法特别方便地完成需要的布局。另外加上如果需要利用AutoLayout来进行尺寸适配的话，使用代码进行约束就更加头疼了。很多时候一个无法满足的约束的问题就够来回运行修改调试很长时间了。
相对于代码，使用IB和xib文件来组织UI，可以省下大量代码和时间，从而得到更快的开发速度。如果你曾经受到过微软家Visual Basic或者其他Visual系的可视化界面的荼毒与残害，因此怀疑Interface Builder的纯正血统和工作能力，建议可以看看这些资料以纠正三观：，（需要翻墙）。另外，不妨打开你的Mac上的Application文件夹中或者iPhone上Apple家的各种应用。你会惊奇地发现，IB远比你看到的要强大：小至计算器取色器这类小工具，大至iWork三件套，Aperture或Final Cut这样的专业级应用，无一不是使用IB来完成UI制作的。
其实IB和xib是从iOS SDK初次面世开始就是捆绑在开发者工具套装内的内容了，而到了Xcode 4之后更被直接集成到了Xcode中成为了IDE的一部分。xib设计的一大目的其实是为了良好的MVC：一般来说，单个的xib文件对应一个ViewController，而对于一些自定义的view，往往也会使用单个xib并从main bundle进行加载的方式来载入。IB帮助完成view的创建，布局和与file owner的关系映射等一些列工作。对于初学者来说，牢记xib的文件都是view的内容，有助于建立起较好的MVC的概念，从而在开发中避免或少走弯路。
xib文件之前一大被诟病的问题是文件内容过于复杂，可读性很差，即使只是简单打开没有编辑也有可能造成变化而导致合并和提交的苦难。在Xcode 5中Apple大幅简化了xib文件的格式，使其变得易读易维护。可以说现在对于xib文件在版本管理上其实和纯代码已经没有太大差异，只要仔细看过一遍xib的文件内容，自然能理解绝大部分，并很好地追踪并查找过往的修改记录了。
当然xib也不是完美的。最大的问题在于xib中的设置往往并非最终设置，在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对同一个属性进行设置，这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的，它没有逻辑判断，也很难在运行时进行配置，而反之使用代码确是无所不能的。在使用xib时，辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视，如果选择xib，那么要尽量将xib的工作和代码的工作隔离开来：能够使用xib完成的内容就统一使用xib来做，而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。
StoryBoard
iOS5之后Apple提供了一种全新的方式来制作UI，那就是StoryBoard。简单理解来说，可以把StoryBoard看做是一组viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布局样式，也可以明确地知道各个ViewController之间的转换关系。相对于单个的xib，其代码需求更少，也由于集合了各个xib，使得对于界面的理解和修改的速度也得到了更大提升。减少代码量就是减少bug量，这也是程序开发中的真理之一。
在Xcode5之后，StoryBoard已经成为新建项目的默认配置，这也代表了Apple对开发者的建议和未来的方向。WWDC2013的各个Sample Code中也基本都使用了StoryBoard来进行演示。可以预见到，之后Apple必定会在这方面进行继续强化，而反之纯代码或者单个xib的方式很可能不会再得到增强。
如果不考虑iOS版本的支持（其实说实话现在已经很少还见到要从iOS4开始支持的app了吧），现在StoryBoard面临的最大问题就是多人协作。因为所有的UI都定义在一个文件中，因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的，其实这更多的是一种对StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及，但是没有人规定整个项目只能有一个StoryBoard文件。一种可行的做法是将项目的不同部分分解成若干个StoryBoard，并安排开发人员对自己的部分进行负责。简单举例比如一个有4个tab功能相互独立的基于UITabBarViewController的应用，完全可以使用4个StoryBoard来分别代表4个tab，并在相互无干扰的情况下完成开发。这样一来就不会存在所谓的冲突问题了。StoryBoard的API是如此简单，现在的SDK中一共方法数量一只手就能数过来，所以具体方法在这里就不再罗嗦了。
StoryBoard的另外的挑战来源于ViewController的重用和自定义的view的处理。对于前者，在正确封装接口以及良好设计的基础上，其实StoryBoard的VC重用与代码的VC重用是没有本质区别的，在StoryBoard中添加封装良好需要重用的Scene即可解决。而对于后者，因为StoryBoard中已经不允许有单个view的存在，因此很多时候我们还是需要借助于单个的xib来自定义UI。这一点可以说是由于StoryBoard的设计思路所造成的，StoryBoard更强调的是一种层次结构，是在全局的视角上来组织UI设计和迁移。而对于单个的view，更多的会注重于重用和定制，而与整个项目的流程没有太大关系。相信抓住这一要点，就能很好地了解什么时候使用xib，什么时候使用StoryBoard。
关于StoryBoard最后要说的是，现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说，StoryBoard文件往往更大，加载速度也相应变慢。但是其实随着现在设备的更新换代，在iPhone4都难觅的今天，这点性能上的差距几乎可以忽略了。而再之后的设备，不论读取还是解析，只会越来越快。所以性能上的问题完全是没有担心的必要的。
我的观点和选择
我入门的时候是使用xib的，因为那时候还没有StoryBoard，而我也不是喜欢代码的学院派Geek。到现在，三种方式我都有尝试过，并分别得到了一些可能还并不是特别深刻体会。对于现在的我来说，xib是我的奶酪，也是我在自己的一些项目里一直使用的方式，我可以在极短短时间内用xib架起一套包括自定义要素和良好部件重用性复杂UI。但是在我尝试了几次使用StoryBoard制作demo之后，我已经决定在之后的项目转向使用StoryBoard。一方面因为确实是未来方向（每次新工程删StoryBoard很讨厌..），现在的StoryBoard专有的preview功能，以及之后AutoLayout的进一步改进等都很值得期待；另一方面也觉得奶酪放一个地方太久了会不好，趁着iOS7的大变革，也更新一下自己的观念和方式，把奶酪换个地方摆摆，也许会对以后大有裨益。
对于初心者来说，我并不建议上手就直接使用代码来进行UI制作和布局，因为冗长的UI代码确实非常乏味无趣。尽快看到成品，至少尽快看到原型，是保持兴趣，继续深入和从事职业的有效动力。所以如果有可能有条件，在老鸟的指导下选择StoryBoard来进行快速构建（或者如果是单个人开发的话，可以不用考虑多个StoryBoard协作，就更容易），会是入门的好选择。而最新的教程和文档已经开始逐渐偏向StoryBoard，关于StoryBoard的问题在SO上关注度也会更高，这样在入门时会有更多的资料可以进行参考。
这并不是说不需要关心代码UI或者xib，因为使用StoryBoard的时候在只能使用代码以及自定义单个view时，还是不可避免地需要接触它们的。这里想给的一点建议就是，虽然你不依赖代码来进行UI制作，但是了解并掌握如何使用纯代码来从头构建UI还是非常必要的：包括从新建Window开始，到初始化ViewController，添加必要的view，设定它们的property，以及添加和处理它们的各种响应及responser链等内容。现在iOS开发入门非常容易，Xcode和xib/StoryBoard帮助开发者隐藏了太多的细节，但是很多时候如果你不明白underhood到底是些什么，为什么这些xib/StoryBoard会这样运作的话，经常会出现卡在一些很可笑的和初级的bug上找不着北，这其实会是对时间的巨大浪费，很不值得。
一些IB小技巧
最后分享一些IB使用上的小技巧作为结束吧。其中很多方法也可以用在StoryBoard上，所以在向我自己之前xib使用者生涯致敬的同时，也算是一点小的备忘总结吧。
同时添加多个outlet
在IB中，选中一个view并右键点击，将会出现灰色的HUD，可以在其上方便地拖拉或设定事件和outlet。你可以同时打开多个这样的面板来一次性添加所有outlet。右键点击面板，随便拖动一下面板，然后再打开另一个。你会发现前一个面板也留下来了，这样你就可以方便地进行拖拽设定了。
多个Outlet HUD
当然，对于成组和行为类似的IBOutlet，应该直接使用IBOutletCollection来进行处理会更方便。
可视化坐标距离
IB最烦人的问题就是对其。用代码的时候我们可以明确地指定x,y坐标，但是换到IB的时候我们更多的时候是靠拖拽UIView来布局。比如需要三个间隔相同的label，除了用强大的肉眼来估测距离是否相等以外，难道只能乖乖分别选中三个label，记下它们的坐标然后打开计算器来做加减法么？
显然不要那么笨，试试看选中一个label，然后按住option键并将鼠标移动到其他label上试试？你可以发现view之间的距离都以很容易理解的方式显示出来了。不仅是同层次的view，被选中view与其他层次的view之间的距离关系也可以同样显示。
显示View之间的距离
在一组view层次中进行选择
对于一些复杂的view层级关系，我们往往直接在IB中选择会比较困难。比如view相互覆盖时，我们很难甚至不能在编辑视图中选中底层的view。这时候一般的做法是打开左侧的view层级面板，一层层展开然后选择自己需要的view。其实我们也有更简单的方法：按住Cmd和Shift，然后在需要选择的view上方按右键，就可以列出在点击位置上所有的view的列表。藉此就可以方便快速地选中想要的view了。
在编辑视图中选则底层view
添加辅助线
这么高大上的技巧必须放在最后啊&在左边的层级列表中双击某个view，然后Cmd+_或者Cmd+|即可在选中的view上添加一条水平或者垂直中心的辅助线。当然这个辅助线是可以随意移动的。如果干过设计的同学肯定明白这个的意义了，在之后的对其和设计变更的时候都有重要的参考价值。
为IB添加辅助线
CocoaChina是全球最大的苹果开发中文社区，官方微信每日定时推送各种精彩的研发教程资源和工具，介绍app推广营销经验，最新企业招聘和外包信息，以及Cocos2d引擎、Cocos Studio开发工具包的最新动态及培训信息。关注微信可以第一时间了解最新产品和服务动态，微信在手，天下我有！
请搜索微信号“CocoaChina”关注我们！
关注微信 每日推荐
扫一扫 浏览移动版iOS开发之使用Storyboard预览UI在不同屏幕上的运行效果
字体：[ ] 类型：转载 时间：
使用Storyboard做开发效率非常高，为了防止在团队中发生冲突，采取的解决办法是负责UI开发的同事最好每人维护一个Storyboard, 公用的组件使用轻量级的xib或者纯代码来实现，下面小编就给大家介绍如何使用Storyboard预览UI在不同屏幕上的运行效果，需要的朋友可以参考下
&&&&&&& 在公司做项目一直使用Storyboard，虽然有时会遇到团队合作的Storyboard冲突问题，但是对于Storyboard开发效率之高还是比较划算的。在之前的博客中也提到过，团队合作使用Storyboard时，避免冲突有效的解决方法是负责UI开发的同事最好每人维护一个Storyboard, 公用的组件使用轻量级的xib或者纯代码来实现。这样不但提高了开发效率，而且可以有效的避免Storyboard的冲突。如果每个人维护一个Storyboard, 遇到冲突了就以你自己的为准就OK了。
　　言归正传，接下来就介绍一下如何使用Storyboard来预览UI在不同那个分辨率屏幕上的运行效果，这就很好的避免了每次调整约束都要Run一下才能看到不同平面上运行的效果，今天的博客就来详述一下如何使用Storyboard来进行Preview运行效果。接下来就一步一步的来看一下如何进行效果的预览。
　　一、创建工程添加测试使用的UIImageView
　　　　创建一个测试工程，在ViewController上添加4个不同尺寸的UIImageView, 并且添加上不同的约束，最后添加上不同的文艺小清新的图片，最终Storyboard上的控件和约束如下所示。
　　二、打开预览界面
　　　　1.点击Storyboard上左上角的按钮 -& 点击Preview -& 按着potion + shift键 点击相应的Storyboard, 具体操作如下图所示：
　　　　2.经过上面的操作后， 你会看到如下操作界面，在这个界面中你可以点击右边的加号按钮来添加预览窗口，如下图所示：
　　三、添加预览设备
　　　　1.双击上面加号的按钮回出现预览窗口，在预览窗口左下方有一个加号按钮，通过加号按钮你可以添加不同尺寸的屏幕进行预览，从3.5到iPad应有尽有，添加是的截图如下所示。
　　　　2.把上述所有设备添加上以后的预览效果如下图所示，这种预览效果仅限于使用Storyboard实现的控件，然而用纯代码写的UI就没有这么幸运了。预览效果如下：
　　Storyboard的还是蛮强大的，类似这种小的技巧，Storyboard还有许多，在这就不做一一赘述了，以后有机会回慢慢的介绍的，在博客的最后呢给大家分享一下我萌萌的桌面吧~然而这个桌面对于你的技术的提高并没有什么卵用~，愿大家天天快乐，工作开心呢！
以上介绍就是本文的全部内容，希望对大家有所帮助。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具iOS开发过程中，是用Storyboard/xib做界面，还是用代码来写界面，还是混合使用 - 简书
iOS开发过程中，是用Storyboard/xib做界面，还是用代码来写界面，还是混合使用
以下是纯属个人观点关于iOS 开发过程中，是用Sb/xib 做界面 还是代码写界面，一直是讨论不断各自成帮结派， 拖拉派、代码派、中间派1. 拖拉派 ，Storyboard/xib 使用者， 像是海贼王里的能力者，开发快、Auto Layout 、结构清晰，直观，一目了然 （个人觉得，小项目如此，超过10个界面以上，界面关系在复杂的话，看起来真是一团糟），能力者是有缺点的不会游泳，同样Storyboard/xib 同样有它的缺点：（）a). 所有的ViewController都在同一个Storyboard里编辑，随着场景的增加，i). XCode打开Storyboard的速度会越来越慢。ii). 所有的ViewController会并列在编辑器左侧，不方便编辑。b). 无法单独调整每个整场景的生命周期，所有的场景生命周期由storyboard控制，一旦加载了一个场景，除非storyboard卸载，否则无法。（一个超级大bug）Storyboard适用于快速开发小型项目2.代码派，使用纯代码，不是能力者，像是海贼王的 红发、索隆， 像是不断的去学习，去多写代码，才能体会其他的奥义，写代码效率并不是别人说的那样效率低，写多了，效率其实挺高的3. 中间派， Storyboard 和代码都会，就静静看着你们撕B，不说话，反正我都会，都在用，这也是一个不错的选择BB了那么多，发表一下个人的观点和看法我个人是 代码派，目前所做的企业项目大概有10几款以上吧，AppStore百万下载应用也是有的，不方便透露（和那个公司签署保密协议），10多款项目全是用纯代码编写，没有一个Storyboard/xib喜欢使用Storyboard/xib估计是没有接手别人写的代码，各种约束不敢动，各种界面不敢动，简单的修改些位置还好，如果需求改动什么的，那真是个灾难， 我相信没有一个项目 从开始到最后，需求完全不改动的，我之前做的项目，需求多少都会改动，老板说改就要改，可不考虑你现在的代码结构，因为那不是老板考虑的。之前开发过Symbian 和Blackberry 2年,现在开发iOS快到3年，在公司接手的项目里，傲娇的说一下，不接受用Storyboard 写的项目，如果接手，代码重构，之前开发的项目都是团队间开发，至少有2人以上，所以开发都是用纯代码写，用代码写适配也是很容易的，有人说用xib拖个Button 只需1，2分钟，代码写要10分钟，我想说的是Xcode里不是有快捷生成代码的方法吗？
10秒钟就可以把代码写好， 还说纯代码效率低？ 而且纯代码写的项目，别人接手的时候 修改和需求改动时，修改起来非常方便，我交接过的项目，别人接手后，大概一个星期 发信息给我，说代码写的真心好，真心佩服，这个是真事。无论你是开发者，还是项目负责人，特别是公司项目负责人，要考虑后续的开发和升级以及他人接手所以我的建议：纯代码用纯代码写，下面有唐巧的blog,很多项目以前使用xib的都在重构，既然简单界面和静态的界面使用xib, 那还不如全都使用纯代码。
NSLog(@&%@&,@&iOS Developer&);Log.d(TAG,&Android Developer”)关于纯代码开发和使用storyboard以及xib的优劣分析 - CSDN博客
关于纯代码开发和使用storyboard以及xib的优劣分析
昨天被问到纯代码开发和使用storyboard以及xib的优劣，说了句习惯问题，被强烈的鄙视了。反过来想想，确实，一直以来认为这三者的区别是在于习惯问题，晚上没有好好的入睡，翻阅了资料，回顾了一些积累，觉得不是这么简单的一句习惯。
1.各自优势
code：可以很好的进行代码版本控制，追踪相关的代码比较容易，多人开发时时一把利器，在编写代码阶段会快捷很多。
代码复用性强，比如可以定义一个view在多个位置复用（当然xib或者sb也可以实现），相对来说很便捷
storyboard:对MVC架构来说可以很好的分离Controller的一些功能，更好的分离view层。使用故事板会使得App的逻辑结构很清晰明了。
xib:早期的页面绘制文件，使用Interface Builder工具进行实现，能够分离view,使用简单便捷
2.各自劣势
code：做UI时需要写很多的代码，势必会产生冗余代码。整个工程的结构不清晰，不会像sb、xib那样直观。另外要写很多代码来实现一些简单的页面
storyboard:多人开发时会有冲突，如果采用多storyboard方式则有会显得low 还需要寻找更好的解决方案
xib:单个页面对应，劣势和storyboard一样
3一些资料分析
参考唐巧的blog
xib 使用调研情况
除了我本人的经历外，我也调研了一下我手机中装的所有的 App 的开发情况，我写了一个脚本，分析了我手机中一共 100 多个 App 包含的 xib 文件的个数。通常情况下一个 App 如果完全通过 xib/storyboard 来完成的话，那么编写包含的 xib 个数不应该少于 10 个（注：storyboard 在打包时会被拆解成多个它包含的 xib 文件）。
这个调研的最终结果，以及我分析用的脚本源码在&。我挑了一些比较有名的应用列在下面。（我另外也列出了它们包含的 js 的文件数量，这个可以反应出该应用对基于 UIWebView 的 Hybrid 编程的使用情况，不过与本次讨论主题无关。）
nib 文件数
Mailbox 2.3.3.ipa
Twitter 6.0.1.ipa
objcio 1.0.3.ipa
播客 2.0.ipa
知乎日报 2.5.ipa
百度视频 6.2.2.ipa
高德导航 9.2.ipa
优酷 4.3.ipa
网易云音乐 2.3.1.ipa
滴滴打车 3.6.2.ipa
网易新闻 416.ipa
QQ 5.4.ipa
猿题库 4.1.0.ipa
搜狐视频 4.6.3.ipa
快的打车 3.7.ipa
小猿搜题 1.4.0.ipa
WeChat 6.1.1.ipa
Evernote 7.6.5.ipa
有道云笔记 4.3.1.ipa
来往 4.3.2.ipa
百度地图 7.6.1.ipa
易到用车 6.2.2.ipa
网易有道词典 5.2.2.ipa
美图秀秀 3.5.0.ipa
支付宝钱包 8.5.3.ipa
手机淘宝 5.2.4.ipa
易信 1.4.8.ipa
大众点评 7.0.2.ipa
iMovie 211.ipa
以上这个表格说明了即使是比较著名的 App，在使用 xib/storyboard 上，也有很大的差异。举几个例子：
QQ、WeChat（微信）和易信同属于社交类应用，而且按理说，由于用户量和开发时间更长，QQ 和微信应该比易信更加复杂，但是从 xib 数量上，前者 xib 的数量都非常少。这说明，在 QQ 和微信中，很多界面肯定是通过手写代码来完成的。
滴滴打车、快的打车和易到用车同属于叫车软件，按理说滴滴打车、快的打车同时包含叫出租车和叫专车功能，应该比易到用车功能更多，更复杂。但是前者 xib 的数量都非常少。这也说明，滴滴打车、快的打车的界面很多是通过手写代码来完成的。
另外，像 Mailbox、播客 (Podcast)、Twitter、objcio 这些 App 中 xib 的数量为 0，说明其完全是用手写代码来完成 UI 界面编写的。
当然，也有一些能看出来几乎是由 xib 构成的应用，例如大众点评、美图秀秀、网易有道词典。而苹果的 iMovie 使用了 4000 多个 xib，真让人不敢相信。我后来仔细看了一下，原来是因为 iMovie 做了国际化，每种语言大概有 120 个 xib，因为支持了将近 40 个语言，所以 xib 数量变成了 4000 多个。大众点评的每个 xib 也被切分成了 4 个，具体用处我还没研究，如下是一个示例：
./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib
./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib/objects-8.0+.nib
./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib/objects.nib
./Payload/DPScope.app/WEDHotelShopInfoMainModule.nib/runtime.nib
使用 xib 和 storyboard 的优点
开发界面所见即所得，可以快速通过拖拽构造界面。你可以从 storyboard 中很方便地梳理出所有View Controller的界面间的调用关系。这一点对于新加入项目组的开发同事来说，比较友好。使用 Storyboard 可以使用Table View Controller的 Static Cell 功能。对于开发一些 Cell 不多，但每个 Cell 都不一样的列表类设置界面会比较方便。通过实现&– (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender&方法，每个 View Controller 的跳转逻辑都聚集在一处，这方便我们统一管理界面跳转和传递数据。Storyboard 可以方便将一些常用功能模块化和复用。例如 WWDC2011 年介绍 Storyboard 的视频就将微博分享功能模块化成一个单独的 Storyboard。
xib 和 storyboard 的缺点
xib 对版本管理是灾难。storyboard 实际上的多个 xib 的集合，所以更容易让多人编辑产生冲突。而虽然它们是 xml 格式，但是冲突解决起来还是不如代码那么容易。苹果对 xib, storyboard 的设计中带有当前电脑的操作系统版本和 Xcode 版本。所以如果两个协作的开发者电脑操作系统或 Xcode 有不一样的话，每次打开必定会修改这个文件。另外即使操作系统版本和 Xcode 版本一样，有些时候打开看也会造成一些自动的修改。storyboard 带来的 segue 的概念对于开发来说并不省事，特别是在需要传递参数的时候。如果是用程序内部 trigger 一个 segue，那么需要在另一个回调的地方设置 dest view controller 的参数信息。我们发现 xib 中设置的颜色值并不精确，RGB 在真机 / 模拟器上常常会有 10 多像素的偏差。xib 和 storyboard 对继承的支持并不友好。无法做界面的继承。xib 和 storyboard 对搜索支持并不友好，无法方便地在 Xcode 中查找关键词（但是可以通过写 bash 命令来查找）。storyboard 对组合支持得不太好，不允许在一个 xib 中附带多个子 view。xib 和 storyboard 不太方便做界面的模块化管理，比如我们想统一修改界面中所有按钮的字体样式，那么在 xib 和 storyboard 只能一个一个手工修改，而如果是代码编写的，则只需要改一个工厂方法的实现即可。对于复杂的 App，storyboard 的性能会比较差。
其实，你完全不需要做一个 “艰难的决定”，你可以像 QQ 和微信那样，根据具体情况来选择性的使用 xib 和 storyboard。一些建议：
对于复杂的、动态生成的界面，建议使用手工编写界面，但一定要注意view和业务层的分离对于需要统一风格的按钮或UI控件，建议使用手工用代码来构造。增加复用性和通用性。对于需要有继承或组合关系的 UIView 类或 UIViewController 类（例如baseview），建议用代码手工编写界面。对于那些简单的、静态的、非核心功能界面，可以考虑使用 xib 或 storyboard 来完成。
本文已收录于以下专栏：
相关文章推荐
文章来源：/blog//ios-dev-controversy-2/
打算分享一些有争议的话题，并且表达一下我的看法。这是该系列的第二...
代码手写UI：
优势：便于多人协作共同构建UI；
   代码重用性好，可以方便移植到其他项目工程。
   可以实现强大的功能，能完成xib或者storyboard做不了的功能。比如：Mac开发中鼠标移...
最近接触了几个刚入门的iOS学习者，他们之中存在一个普遍和困惑和疑问，就是应该如何制作UI界面。iOS应用是非常重视用户体验的，可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关...
在XCode中我们可以用类似这样的注释来方便我们标记需要修改的部分:
XCode 4.1由于BUG不能使用这...
本文转载至：https://www.cyberciti.biz/faq/mac-osx-find-tell-operating-system-version-from-bash-prompt/
1、oc中使用的注释
//单行注释、
       #pragma marks        Comments containing: &#16...
我们经常可以听到nib开发或xib开发之类的术语，但两者有什么区别呢？其实两者说的意思差不多。
nib是3.0版本以前的产物，在终端下我们可以看到，NIB其实是一个文件夹，里面有可执行的二进制文件...
本文参考Demo:/ios/JKAlertDialog/bf8
如果在导航中使用自定义警告框，如果警告框添加在view...
最近接触了几个刚入门的iOS学习者，他们之中存在一个普遍和困惑和疑问，就是应该如何制作UI界面。iOS应用是非常重视用户体验的，可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关...
前言我们在开发项目的时候，有些人选择纯代码，有些人选择storyboard，也有些人选择xib，当然各有各的好处。在此就不做讨论。
以前做的一个项目用的storyboard结合autoLayout，...
他的最新文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)