以前在入门的时候，找的入门书籍上编写的 demo 都是基于 Storyboards 拖界面的。后来接触公司项目，发现界面都是用纯代码去写复杂的 autoLayout 的。再然后，领导给我发了个 Masonry 库去看，依然是手写代码布局界面，但效率高了不少。工作一段时间，看了很多博客，也看了一些书，发现用纯代码写界面的很少，于是就在 Google 上搜 Storyboards 有什么好处，最后发现了一篇非常好的文章。在此提炼文章的一些观点，同时表达一下自己的观点。
文章链接：iOS User Interfaces: Storyboards vs. NIBs vs. Custom Code 文章介绍了三种构建界面的方法，并对不同方法分别讨论了优缺点。
其实对于这几种方法，没有最好，只有最适合。
总结下来就是 Storyboards 是一个容易观察并且使用简单的 iOS UI 设计工具。它也消除了固定的创建控件的模板代码，但导致了很严重的灵活性的缺失。NIBs 对于 single view 来说提供了很大灵活性，但没有视觉流（个人猜测是 view controller 的切换）。灵活性最大的方案就是纯代码布局，但纯代码并不是那么直观，也没有那么容易。
同样的话题，在唐巧的博客里，也讨论过这个问题：iOS 开发中的争议（二）
其中比较有说服力的一段是他分析了100多个 App 包含 xib 文件的个数，大概推测出很多著名的 App 里大部分界面都是手写来完成的。
同时他也提出了自己的建议：
- 对于复杂的、动态生成的界面，建议使用手工编写界面。
- 对于需要统一风格的按钮或UI控件，建议使用手工用代码来构造。方便之后的修改和复用。
- 对于需要有继承或组合关系的 UIView 类或 UIViewController 类，建议用代码手工编写界面。
- 对于那些简单的、静态的、非核心功能界面，可以考虑使用 xib 或 storyboard 来完成。
呐最后我个人也是偏好使用纯代码布局的，并不是因为我一直是这么做的，而是有以下原因：
- 纯代码布局最让人诟病的就是代码量太大，的确，我之前用 autoLayout 的时候每写一个 constrains 就要好几行代码，一个控件有几个约束关系的话就要写几个 constrains，这个代码量一下就上去了。但现在有开源的 Masonry 库，对于 Swift 也有相应的库，所以对于代码量以及学习难度来讲，纯代码布局这部分的缺陷完全能够被弥补。
- 纯代码写的界面容易控制，这个容易控制是说，你每增加一个控件，一个约束在代码上就可以很直观的显示出来，因为每写一行代码你自己就会很清楚。而对于 Storyboards 来讲，控件的属性界面密密麻麻一大片，不管你改不改，那些数据都显示在那里，有时候你忘记改了哪些东西你都会在属性栏里一个一个去找。比如我把 view 的背景色从
grayColor改成了lightGrayColor，那我从代码上就可以很直观的看到这一句 view.backgroundColor = [UIColor lightGrayColor]，但如果在 Storyboards 里，我就要去找背景色这一栏，还要分辨出灰色和浅灰色。 - 最后，就是代码的复用。比如写一个复杂的 tableViewCell ，用 Storyboards 去拖界面的话，就会看到视图上面有一堆控件和布局，如果我想在哪天复用这个 cell 并做一些布局修改的话，便又要重新拖放，如果有响应事件的话，还要重新给新建的类连线，想想这个工作量，不出错都难。而对于手写界面来说，写一个控件就封装在一个类里面，需要复用了，继承一下或者复制粘贴到别的工程即可使用，就算有响应事件，写几个 protocol 做反馈就解决了。
- 最最后，我想起来以前上学搞 MFC 的时候，那时候也有关于手写界面还是拖界面的讨论，当时一个很有说服力的评论是，手写界面可以锻炼你对 MFC 程序的理解，可能你还是无法知道 MFC 的实现原理，但你会很熟悉 MFC 的实现过程（大概是这意思）。这一点我觉得在 iOS 上也适用。比如说按钮事件，用 Storyboards 就是鼠标一拖，连一条线出来，系统就生成了一段事件代码，而你只要填代码就可以。我觉得这对于学习 iOS 不是一件好事情，虽然说我现在也不是非常了解 iOS 底层的一些实现原理，但通过手写界面，手动添加事件，我知道这些东西是怎么添加的，添加的东西和其他类之间的关系是什么。所以手写界面对学习 iOS 还是有一些帮助的。
