Autolayout入门教程

iOS 发展到现在,iOS5的占有率已经很低了(估计多数还在使用iOS5系统的用户活跃度也不高吧),因此兼容最低版本iOS6.0也不会损失太多用户。同 时,下一代大屏iPhone已经发售了,Autolayout绝对是其中一个重要的界面兼容手段。为了能尽快做好适配好新设备的工作,我相信学习 Autolayout这门技术也是必不可少。我作为一个使用了Autolayout大约一周左右的初学者,就在这里记录一下一些要点吧。

一、Autolayout的简要背景

Autolayout这个东西是从iOS6开始才出现的,在没有Autolayout的远古年代,大家是用Autoresizing做一些简单的界面拉伸的。
这里先说一下Autoresizing,这个东西支持width和height的四方向拉伸,也可以对x和y做一些简单的四方向对齐。当然,Autoresizing还是基于绝对坐标的,所以界面上的元素还是需要设置好对应的坐标。支持ib和代码设置,如下图
182306452535416

self.view.autoresizingMask = UIViewAutoresizingFlexibleWidth|UIViewAutoresizingFlexibleHeight;

可以看到代码其实就是设置UIViewAutoresizing枚举变量,代码也是比较简单的。利用Autoresizing就已经能很好适配了搭载 iOS6的iPhone5(有部分界面还是需要多个containerview或者写代码手动调节的,不过并不复杂),那为何Apple还要多此一举推出 Autolayout呢?

从实用性来看,应对iPhone5之流,Autoresizing足矣,且有兼容性的优势。但是现在时代变了,Android满地开花的大屏手机(5吋以上 才能称作大屏),Apple为了保持自有优势,我认为大屏设备和界面的大一统将会是未来战略(iPhone可以使用原来iPad的专用控件)。这必然导致 界面的适配问题,最起码Autoresizing已经显得无力了,同时对于部分需要有横向界面的应用会有更复杂的调整工作。如果不使用 Autolayout,改用代码手工适配的话,工作量也不算少,同时会需要大量的魔术数来定位坐标。这完全不是现代界面该有的开发方式,实在太原始了。随 着iOS8的到来,Autoresizing的兼容性优势会逐渐消失,事实上要同时兼容4个大版本的iOS,这难度的确不小。

因此,现在开始学习并使用Autolayout是一个不错的时机。除了上述因素,从开发工具来看,对于Autolayout的支持已经比Xcode5之前好 了不少。其次,针对Autolayout的开源工具库也已经相对成熟,前人踩过的坑大多都可以找到对应解决方法。所以,我实在想不出一个拒绝 Autolayout的理由。

 

二、Autolayout的基础知识

如果大家对Android有所了解,应该知道他们是通过dp的相对坐标和一些布局来定位控件的(好吧,可能我用词不太正确)。但iOS的 Autolayout思路和Android的布局思路,还是有很大的差异。Autolayout的本质是约束,通过设定足够多的约束条件,来得出每一个控 件的最终坐标。约束条件之间不能相互矛盾,否则会出错抛出异常。条件之间的矛盾还是比较难描述的,这个我在下面的内容再举例说明。

约束的条件有几种类别:

  1. 大小(Width、Height、WidthEqually等)
  2. 间隔(HorizontalSpacing等)
  3. 对齐(TopEdges、HorizontalCenters等)

在使用Autolayout的界面里,如果控件不添加任何约束的话,还是可以使用绝对坐标定位的。但是,Autoresizing和Autolayout在 同一个界面层级是不能共存的,只能选择其一。不过实际操作上,Autolayout要实现某些Autoresizing的功能是完全可以的,但是步骤不一 定比以前简单。

对于一个控件来说,从前的定位是通过设置frame的4个变量来控制的。但在Autolayout的世界里,这些绝对的数值已经不那么重要了。Autolayout在运行时计算出这些数值也是需要最少2个约束,大多数情况还需要4个以上。

2个约束的例子:
系统的UIActivityView是固定大小的,所以只需要添加x和y的约束。

3个约束的例子:
UILabel类控件,其长度可以由系统计算文字数量和大小得出,所以width或者height的约束可以省去一个。其余两个约束就是x和y的约束,具体表现为HorizontalSpacing等。

4个约束的例子实际上就是多了上述例子一个width或者height约束。

从这些例子,可以得出一个结论,对于一个控件而言,x和y是不可能避免的约束,所以使用Autolayout的控件最少需要2个约束。当然,大多数情况是4个约束起步,同时还需要控件间的各种约束来构建一个完整的界面。
同 时在Autolayout的光环下,基本不再需要手动设置frame。使用Autolayout的控件,frame只是表示这个控件当前的坐标。只有相关 的约束有变化或约束的控件发生变化,随之这frame也会变化。这些在InterfaceBuilder中可以很容易体现出来,你可以立即看到控件在任意 情况下的变化。

 

三、Autolayout实践应用

这里的实践以ib为主,我在这里解释一下,设置Autolayout实际上有3种方法,分别是:ib、可视语言和传统代码。我分别说说这些方法的特点:

  1. ib

    直观简单,所见即所得,实时控制界面变化。系统还会提醒冲突和缺少约束,并给出修改建议(建议通常不是最好)。对于约束相对静态的界面,开发效率高。但在复 杂页面中,常常是100+的约束,不是很友好。同时,对界面内的控件复用比较麻烦,造成大量相类似约束。某些控件不能直接往其添加子控件,如 UILabel添加一个UIImageView到其中。

  2. 可视语言

    需要编写代码,同时要求对Autolayout的体系比较熟悉。由于其语言样式可以比较容易看出控件间的约束关系,所以还是比传统代码直观,但还是无法预想 运行时的变化。一次可以添加多个约束,并在运行时改变约束,但是不能完整实现所有约束功能。同时可视语言也有一些学习成本,没有对应的代码建议,所以需要 额外的检查来保证语法正确。

  3. 传统代码

    其实就是调用普通的API,参数比较多,但是可以实现Autolayout的所有功能。从代码量来看,要比可视语言多。这种方法更偏向于类似传统code界 面,对于一个100+约束的界面,我想还是挺吃力的。不过,在复用性方面有一定的优势,和可视语言一样,可以在运行时改变约束。此外,使用 PureLayout开源库可以在一定程度上简化代码。

作为新手而言,通过ib来学习Autolayout是最友好的,可以很直观地观察界面的变化。刚开始时,最容易出现的问题就是遗漏了添加一些必要约束,造成期望与实际不符。ib能检查出约束是否完整,并给予建议,让新手迅速适应Autolayout的开发。

210031400185598ib会提示警告和错误,警告一般不会在运行时产生异常,但错误是务必要解决的,因为运行时是一定会有异常的。

210010560659765出现警告的原因一般是frame没有更新,这个可以直接update一下。

210032274409676而出现错误的原因则是缺少必要约束或者是约束冲突。前者的解决方法是补全约束,后者的情况有点复杂。所谓的约束冲突就是没有办法同时满足所有约束,从而产生 冲突。一般是通过删除一些约束,使所有约束都可以满足,个人不建议通过修改约束的优先级来解决。如非特殊情况,一般都是添加越少约束越好,这样思路越清 晰,同时对于运行效率都有一定帮助。从目前经验来看,一般的界面开发,的确是用不到优先级的(楼主目前的经验)。
可以看到这些建议不是唯一的,是选择其中一个来补全约束的。新手可以选择系统的建议,看看补充了什么约束,但长远来说,不建议直接使用系统建议补充的约束。 个人认为ib的这些警告和错误对于开发界面来说,是极其高效的,但建议却不是非常智能。特别是补充约束的建议,通常和你心中期望的界面是差距很大的。
对于单个控件,可以直接通过菜单或者右下角来添加约束,

210038163938602右下角的按钮还能一下添加多个约束

210041354098569对于控件间的约束则需要按住Command+点击,选中多个控件再添加约束。

约束其实也是对象,因此会出现在坐标的列表

210044100651455同时,约束也支持outlet

index约束为什么也需要outlet?显然是为了调用某些方法,而降低了遍历约束难度。

在ib上拉几个控件,就可以完成了上面的简单实践了。但是,光这些是不足以完成适配不同屏幕的开发。

 

四、Autolayout的复杂约束

Autolayout 中的UILabel类控件大小是自适应的,因此一般不需要指定width和height。而且,固定width和height的这类约束要尽量少用 (UIImageView这类还是不反对使用),这类约束一般会限制你的思维。如何多个UILabel并排在同一行,但是行宽有限,同时每个 UILabel都有较多的字数。那么应该如何控制某个UILabel可以优先完整显示?这时就要利用抗拉伸和抗压缩的优先级了

211820478933361还有一个相对特别的属性是比例,支持输入类似“16:9”这类有无穷小数的值。具体应用如下,

211832010342447这个约束可以使控件跟随父视图的大小按比例变化,有类似于之前Autoresizing的效果。
既 然约束也是对象,运行动态改变约束的值,则可以达到更多复杂的控制。为了操作方便,我们可以为一些约束创建outlet。同时在运行时,根据需要动态改变 约束的数值或者移除添加约束等,这时,为了操作方便,我使用了一个开源库PureLayout。利用PureLayout就可以很方便地,对约束进行操 作,其API要比系统的友好不少。github地址:https://github.com/smileyborg/PureLayout

暂时发现的坑:

  1. 在tableView的tableHeaderView使用Autolayout时务必要注意,不要使用严格的约束来限制了整个view的大小,否则运行 时十有八九会出错。还有,改变tableView大小时,也有一些错位的情况,暂时无解。tableFooterView的情况未测试,估计应该一样。
  2. 在iOS6上约束的容错性更差,更容易报异常,例如有两个相同约束,iOS6上会有异常断点,但不会崩溃;iOS7上无任何异常出错。当然存在多个相同约束是不规范的行为,编写约束时应尽量做到用最少的约束去达到最佳的效果。
  3. Autolayout也是有性能问题的,目前我在iOS6的iPod Touch4上测试100个左右约束的界面。在刷新tableView和添加视图等操作时,能明显感觉到延迟。经过一系列操作,甚至会出现1分钟以上的延 迟,这时无法接受的。可以得出一个结论,Autolayout在约束较多的时候,在低端机器上也是会造成性能瓶颈的。不过,幸运的是,我在iOS7上的 4s运行同样的界面,就几乎没有延迟。随着低端设备被淘汰,这个问题会得到缓解的。

最后的一个建议是,不要过早地使用Autolayout优化,因为实际上有些界面使用Autoresizing也是能很好地完成适配工作的。同时,对于tableView这类控件使用Autolayout,需要多加留心。

发表评论