妙不可言
在正文开始之前，先简单聊一下点关于storyboard的一些争议，毕竟正确认识也是使用的前提之一。
说到使用storyboard，就不得不提到使用xib的构建方式。从表面上讲xib 和 storyboard 其实是非常类似的，但是为什么更抵触引入storyboard呢？
原因可能是以下几个：
第一，对storyboard不熟悉，很少使用到这个。更擅长于纯代码/xib的方式进行布局等操作。担心学习成本太高，无法在短时间内使用精通。
第二，对storyboard 在工程上，特别是大工程上的团队合作持有怀疑态度或者听到的坑太多从而直接放弃。
第三，考虑到后期维护时页面变动或bug修改不易进行、可读性、可拓展性差，如果后期出现问题不能使用的时候，就要推倒重来，是更大的成本代价，不符合团队利益。
下面，先对以上疑问一一作出解答。
对于第一点和第二点可以说是同样类型的问题，属于自我放弃型，在没有实际深入了解的情况下作出的惯性判断。其实大家都低估了苹果对开发者的友好程度，甚至花看完这篇文章同样的时间你就能学会基础的使用，要是老鸟再指点一下，很快便可以达到熟练运用其进行页面布局的水平了。“傻瓜式”开发是苹果一直以来的追求，从苹果的角度来说就是对开发者屏蔽细节，大家“傻瓜式”开发，尽量少去了解具体实现的繁琐细节，而把更多的注意力放到业务中。所以。从2011年推出以来，经过10年的发展，storyboard早已经改进到能解决99%的GUI开发问题了（剩下的1%我们后面会提到）。从团队开发这一点来说，早在Xcode5版本时简化xib了结构，再加上Xcode7中引入了storyboard reference 已经彻底的解决了这一问题，只要合理的划分功能模块即可。即使出现了storyboard 文件冲突，影响也是极为可控的（通过看storyboard 实际的xml可以看出，每个ViewController 都有各自的范围域）。
对于第三点，其实是比较难以回答的，因为怎么定义难修改、怎么定义容易拓展、什么时候才需要推到重来都是很难界定的问题。比如说，拓展同样一个组件，纯代码需要5分钟，storyboard需要10分钟就算是难拓展吗？ 还是说纯代码需要5分钟，storyboard需要30分钟才叫做难拓展？中间相差的20分钟在实际开发中又有多大的影响？ 根据实际经验，两种方案所需时间差别并不大，因为都需要去理解上下文中相关的约束的含义。或许纯代码更好理解一些？ 但是修改以后需要不断的运行去看效果，而storyboard直接就可以直观的看到约束之间的关系，改动立即可见，省去了重新运行调试的时间。总体时间上两者是区别就很有限了。
再者，可读性、可拓展性很大程度上取决于代码设计水平，也就是说同样一个功能，实现方案用storyboard和纯代码在本质上没有区别的，什么时候需要添加辅助的控件，什么时候需要添加父组件去组合页面元素等等都是编码水平的体现，并不存在storyboard用的好，纯代码写的就差这样的情况，反之亦然。
基于以上问题的解答，相信你对storyboard也有了一些信心。那么现在开始想象你已经会了这个神奇的GUI构建方式（即使你从没使用过），我们探究一下这个技术在实际应用中的情况。
原理篇：
先从本质上认识storyboard 。
storyboard 编译后会生成一个以storyboardc为拓展名的文件，这个文件其实和.bundle类似，实际上是一个文件夹，里面存储着storyboard描述信息的一个Info.plist文件和一系列.nib文件。看到.nib我们就很熟悉了，这正是xib编译后生成的文件，里面包含了编码后View的层级信息。加载的时候和原来一样，通过将nib二进制还原成实际的对象去解码配置在xib的属性信息，最后显示出来。很明显，使用storyboard 和使用xib在存储信息和加载信息的本质上是一样的，由此可见storyboard 其实是升级版的xib组。所以，如果你平时使用xib，不妨试试storyboard，也许会有很大的惊喜。
使用篇：
如果你还仅仅以为storyboard 只是xib的集合，那就大错特错了，storyboard 给使用者提供了更加全面的使用方式，他的聚合特性，还有一些只能在storyboard 上使用的独特特性，都让开发变得高效无比。
比如：直接将cell嵌入到tableView中，直接使用静态cell 构建页面，scrollView甚至可以直接滚动，显示出超过屏幕的内容等等。
或者将配置都写到storyboard 文件中，通过IBInspectable / IBDesignable在属性面板添加新的可配置属性，亦或动态绑定同一个xib描述的组件并实时更新显示，异形屏适配（safeArea），多屏幕适配（Size Class）等等。
开发中可能用到的所有属性都可通过简单的配置加入到storyboard中 。这几乎聚合了UI开发中所有的可能性，并且托管于storyboard自身（配置好后只用设置数据源，包括cell的注册等等都不再需要代码设置），几乎能让你的控制器变的空旷。
除了直接使用之外，storyboard 还提供了一些配套的辅助工具，比如对齐辅助线等，这也让你的UI构建如虎添翼。
storyboard /xib 其实远比你想象中强大，在Mac系统中，小至计算器取色器这类小工具，大至iWork三件套，Aperture或Final Cut这样的专业级应用，无一不是使用storyboard /xib 来完成UI制作的。作为一个开发者，我想你不会拒绝这强大又易用的工具吧。
问题篇：
即使一个工具再简单，放到具体的使用中也会出现各种各样的问题。绝大多数问题都有现成的解决方法，只要你Google一下就能迎刃而解。
这里我们只讨论一个最最重要的问题，即上文提到的那1% ，在最坏的情况下，某个页面由于种种原因不能使用storyboard 去构建，那么应该怎么处理？ 只能纯代码重写了么？
错！ storyboard 还有一个绝活就是可以很容易“退化”到xib的形式，如果一个页面不适用storyboard ，那么就退化到使用xib去构建（你只需要简单的复制和少量约束的重新添加即可）。如果还不行就使用多个xib去组织，把一个xib分解为多个去解耦去简化复杂度。如果再不行，那你仍然不应该立即去使用纯代码构建，因为很可能是你的构建思想出了问题，应当首先去思考这一点，看看这样构建是不是最佳的做法。直到你无计可施了，这时你才应该考虑使用纯代码，然而也是部分使用，毕竟不能构建的一定只是一个部分，而不是整体。
就算如此，为了这可能出现的1%而放弃确定的99%也是极不划算的。
总结：
这里就直接使用喵神（王巍@onevcat）文章中的话作为结尾吧。
本文并不是说什么「你应该这样使用」或者「最佳实践就应当如此这般」。你可以选择使用纯代码构建 UI，但同时 Apple 也为我们提供了更快捷的 IB 和 Storyboard 的方式。在我这么几年的使用经验来看，storyboard 的设计并没有这么不堪，而相比于以前使用代码或者 xib 的方式，现在的开发方式确实让效率得到了提高。开发者根据自己的需求和理解对工具进行选择，每个人的选择和使用的方式都是值得尊重。只要愿意拥抱变化，勇于尝试新的事物，并从中找到合适自己的东西，那么使用什么样的方式本身其实便没有那么重要了。
最后，愿你的技术历久弥新，愿你的生活光芒万丈。
参考文章：
https://onevcat.com/2013/12/code-vs-xib-vs-storyboard/
https://onevcat.com/2017/04/storyboard-argue/
网友评论