我目前使用storyboard写项目，布局会很方便，如果代码控制布局我觉得挺麻烦的。毕竟Constraint这个手写挺烦的。 以前的项目代码的就用手写代码控制了。 现在出了iPhone6，手写代码来布局想想都有点怕。

1楼 @snoopy 您指的手写代码是写 autolayout 的控制代码还是 frame 的？

手写代码 AutoLayout用 Masonry 应该还好吧.

3楼 @f19009 谢谢, 不知道您对我提出的 1, 2 这两个问题有什么看法呢？请教

楼主提出的问题也是我最近顾虑的，如果仅在stroyboard里面布置UI，用autolayout还好应付。问题之前很多项目是用代码frame来定义UI的，不知该如何解决的好，未必代码里用到frame的地方，都得用代码加constraint吗

用VFL我觉得挺方便的，效率也挺高，而且适合一直手写布局的童鞋们。

嗯，我觉得这个东西过度是一个过程的，但是从 Apple 的 SDK 和 Xcode 本身的情况来看好像没有这条路可走, 要么你 frame 方式, 要么整个项目全盘推掉然后硬上 AutoLayout

下面我闲聊挺多的，先来总结下，有兴趣再详细往下读：

1，AutoLayout并没有要求一个项目的全部部分都用AL。只不过InterfaceBuilder要求，如果你再一个Xib或者StoryBroad上设定了AL，那IB只为你提供AL的设计方案，反之，设为非AL，就只为你提供非AL。你不能在一个Xib或者SB上既有AL又用非AL。但这不是AL的本质。AL是针对控件的，这个控件用AL，其他不用AL这是没有问题的。

2，我觉得AL想ARC一样是大势所趋，但AL远没有ARC完善。如上面第一点说的AL也没想统治世界。在使用AL的时候，你必须考虑那些地方该用，那些地方不该用。再次说明，它是针对单独控件的而不是全局，IB非此即彼的设计可能让部分人困惑。千万别傻着想从今以后统一使用AL，AL不是为此设计的。

3，上面说的AL的局限性是它主要的缺点，但有点在于它比以往Mask+Frame的方式更细化了界面布局的需求（这也许也是一个缺点，细化了其实也繁琐了）。为了在未来能够使用基于AL设计的控件，新项目大局上应该用AL（将SB、Xib设成AL），局部上按需求看是否真正需要AL。

4，AL不完美，现在已知道的，AL对3D的CoreAnimation的兼容不是特别好，所以在这些部件上要注意。如果你发现自己设计的动画有点跟原来的构想有出入，AL是你的一个debug方向，而解决方案是，在这样的界面上不要使用AL。

5，AL的代码布局是很蛋疼的，慎用。如果你发现你需要用较复杂AL代码，可能这意味着这部分的界面设计不适合用AL。

分割线-----------------

我以前的公司出于兼容性考虑一直做基于5.1/5.0的系统，所以一直没考虑使用AutoLayout。离开公司后，在一次面试中被面试官问道AL的知识。后来想想也确实应该面对一些历史遗留问题了。下面是LZ的问题的回答：

1，我认为有几点：

-由于多人开发的时候StoryBroad版本控制上表现的相当蛋疼，所以从一开始我们就放弃使用SB了，所以以前也没考虑这个问题。也在那次面试中被问到了，所以回家恶补去。

-旧项目如果工程量大的话就尽量别想着Upgrade成AL了。就算工程量少，也最好别动它。你就把它想象成ARC吧，你大概不想碰那些Non-ARC的代码，也没有那种需要。

-AL和以前那种Layout Mask的布局方式是不兼容的，你一个控件上只能用其中一种，但不同的控件可以选择不同的布局手段，整个SB上你也可以有不同的选择。但很不幸的告诉你，InterfaceBuilder只为你提供非此即彼的设计方案。如果你再IB上选了AL，那IB就指为你提供AL的设计方法，Frame和Mask的布局方式你只能在代码上做了。

-当然还有一种解决方案，你再IB上选AL，到了一个你不想用AL的页面，你生成一个这个页面的xib并把它设成非AL，做好后在镶嵌回SB上，问题是你在SB上就看不到这个界面的设计细节而要转到xib里才能看到。这其实不是一个好的方案。

-其实要再SB上用非AL可能是个心态问题。因为我试着让自己做了一轮设计，很少发现有真正的需求非要非AL才能做。可能是接触新技术的时候的一种懒惰吧。确实，学AL学起来比Mask费劲挺多的。

2，在AL里用非AL控件是没问题的，你可以想象，水果公司那么多控件，引入AL后其实也没有做成基于AL的实现（要不然非AL项目要哭的啊~）。但是在非AL中用AL控件肯定是不行的，这也是为什么我说AL长远来说是大势所趋的原因之一。解决方案无非有3：将整个项目改写成基于AL；将控件改写成非AL；不用AL控件。这也引出一个话题，做控件设计的朋友如果想要控件的适用性好，必须做成非AL。不过另一方面是故意做成AL，迫使你在新项目中推动你用AL。

3，在那次面试中我还被问到，我是代码派还是IB派。其实我在非AL时代也很少用代码控制布局，尽量使用IB的Mask工具来完成，因为布局代码实在太难看了。布局代码唯一的好处是追踪起来比较直观，因为对于那些刚做iOS的人来说，要从IB上追踪你的设计是挺困难的，这方面布局代码确实比较直观点。这也让我当初很纠结，到底我是应该尽量通过代码布局还是通过IB的设计来布局。然而当看到同事的那些布局代码后，我发现虽然代码布局比较好追踪，但也不过是打引号的“好追踪”而已。那密密麻麻，没有意义的坐标代码其实一点都不会让你省心多少。反而如果真正熟悉IB的布局工具，效率上确实会好很多。言归正传，AL的布局代码是相当蛋疼的，比非AL还要蛋疼。尽量不要做AL的代码布局。事实上，如果你要用代码布局，这个控件可能就不是太适合用AL了。

4，跟3是一个回答，如果你的控件要用到很复杂的布局方式，那请不要在这个控件上使用AL。AL不限制非AL的使用，IB限制AL和非AL的使用。

最后讲讲我的一个用AL的细节。一般来说，我是尽量避免写AL代码，但有时候很难完全避免。这时候就要判断到底这部分的界面设计使用AL是否会让AL的代码复杂度大幅增加。如果不是，那我仍然会使用AL。举个例子：类似于top bar和bottom bar的弹出和收起，我可能还是会用AL。譬如说按一个按钮弹出top bar，那就是将topbar的top constraint的constant属性从负数设成0，收起是相反。我会在IB中将该constraint做成Controller的outlet，

@property (nonatomic, weak) IBOutlet NSLayoutConstraint *topConstraint;
@synthesize topConstraint=_topConstraint;

然后在button的action里写：

if (_topConstraint.constant < 0) {
    _topConstraint.constant = topBarHeight;
}else{
    _topConstraint.constant = 0;
}

这种程度的代码，还算比较优雅，我会继续使用AL。不过每个人对这种代码的接受程度都不同，根据具体情况自己把握就是了=w=

手写AL 推荐用Masonry :)

http://adad184.com/2014/09/28/use-masonry-to-quick-solve-autolayout/

8楼 @bluedimple 非常感觉您的这一番评论, 使得我对当前 AutoLayout 有了一个基本的判断和认识, 就是 AutoLayout 不是一蹴而就的, 是一个循序渐进的过程..... 而你最重要的是给出了这个转换时期的一种解决方法! 谢谢

同时谢谢提出 Masonry 的朋友, 初步了解了一下 Masonry 还真是不错的，不过还没用到实战中去

另外感谢所有解答的朋友