由于出来了 iPhone 6, iPhone 6p, 使得自动布局变得很重要, 但是观察发现没多少人真正过度到自动布局, 现在对自动布局有很多疑问:
由于对 autolayout 不理解,也从来没用过可能有些问题很傻很天真请大家见谅....
我目前使用storyboard写项目,布局会很方便,如果代码控制布局我觉得挺麻烦的。毕竟Constraint这个手写挺烦的。 以前的项目代码的就用手写代码控制了。 现在出了iPhone6,手写代码来布局想想都有点怕。
楼主提出的问题也是我最近顾虑的,如果仅在stroyboard里面布置UI,用autolayout还好应付。问题之前很多项目是用代码frame来定义UI的,不知该如何解决的好,未必代码里用到frame的地方,都得用代码加constraint吗
嗯,我觉得这个东西过度是一个过程的,但是从 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 不是一蹴而就的, 是一个循序渐进的过程..... 而你最重要的是给出了这个转换时期的一种解决方法! 谢谢