Question

iOS 开发，为什么不喜欢用拖控件

Answer 1

关于Xib与Storyboard和Code布局之间的争论从iOS5开始就没有停过 T_T

我原来也是一名忠实的Storyboard布局拥护者，并且认为所见即所得的界面对于开发者和设计师都非常友好，再配合上初学时XCode5支持了拖自动布局的约束，然后再加上Canvas库在属性检查器里设置K-V属性跑动画，我甚至一度以为这恐怕就是iOS在视图层的全部了。

但是随着经验增长，特别是抛开个人开发的玩具应用开始实习后，一个项目大部分视图以及一些自定义的复杂控件（包括一些容器控件）以及一些与视图相关的逻辑远远比我之前做的规模不大的应用复杂得多，而且存在如下问题：

Storyboard和Xib存在老生常谈的合并冲突难以解决，这个问题从我初学iOS开始和同学一起做一些小应用时就遇到过，在属性检查器里更改一个值或者误操作挪动一个控件的位置或者按照XCode的提示自动更新约束这样的动作，在不同机器上有时Git diff都是不一样的，合并时多是不可名状的XML让人头疼，虽然多个Storyboard或者分工Xib可能是种解决方案，但是还是或多或少存在协作的问题。

复杂的标签导航或者抽屉导航控制器反而在Xib和Storyboard中不直观，早期在学习一个叫RESlideMenu的开源抽屉导航控件时发现了这个问题，作者的Demo拖出了4个控制器和若干个导航控制器，但是有内容的只有两个，其他的被作为根视图控制器或者容器控制器是一张白板，而强调通过联线联系各个控制器的Storyboard中就会出现一些拖出来的视图控制器没有联线，且目前还无法像文件那样分组，一堆堆白板控制器拖出来反而不直观。
Xib和Storyboard的布局一般只决定视图的初始状态（静态），拖出来的控件或者视图或者约束是固定的，复杂应用中一个视图的控制器的状态变化很多（跳转、处理通知、刷新数据、事件驱动的动画等等）都有可能影响视图控制器乃至一些控件和视图的状态，往往这个时候我发现还是需要用代码来更新约束，跑动画[关闭菊花，隐藏对话框等]，这个时候初始状态的布局逻辑和后续状态变化的逻辑反而造成了分离，一是有不太协调，二是一定程度破坏了一整块视图控制器的逻辑的整体性。
一些视图或者视图控制器需要被继承复用，往往需要拖出不少形态相似的控件出来，派生的类需要在Storyboard里重新拖出相应的对象然后更改类型，如果是简单状态少变化少的视图还好重新拖，如果稍微比较复杂就直接复制现有的视图然后在慢慢鼠标小幅度改动，体验上还是蛮揪心的。
但是但是这并不代表在开发过程中绝不使用Xib，同时这也不代表代码布局就是Frame满天飞。我反而不是特别喜欢Frame满天飞这样的做法，特别是一些魔数相互依赖，也没有文档或者注释的时候那个维护简直酸爽的不行，于是怎么解决呢？炒鸡简单：

在一些已知状态极少改变甚至已知就是纯粹的静态视图使用Xib，如：静态表视图表单，自定义的对话框等。
界面布局尽可能使用自动布局的框架，如：Masonry（Obj-C），Snappy（Swift）等等，无论是make，update，remake约束都是一个非常友好的Block，十分方便，用了都说好（星星眼） 例子：（来自Masonry介绍与使用实践(快速上手Autolayout)）
[sv1 mas_makeConstraints:^(MASConstraintMaker *make) {
make.edges.equalTo(sv).with.insets(UIEdgeInsetsMake(10, 10, 10, 10));

/* 等价于
make.top.equalTo(sv).with.offset(10);
make.left.equalTo(sv).with.offset(10);
make.bottom.equalTo(sv).with.offset(-10);
make.right.equalTo(sv).with.offset(-10);
*/

/* 也等价于
make.top.left.bottom.and.right.equalTo(sv).with.insets(UIEdgeInsetsMake(10, 10, 10, 10));
*/
}];

目前这样的解决方案个人感觉还是相当不错的，就是一些特性可能不支持iOS5及一下的老版本。

Answer 2

个人习惯吧，我自己挺喜欢拖控件的（使用的是故事版），纯代码效率太低了，而且控件位置还比较难确定，适配的时候问题会更明显