前面讲过了AutoLayout的基本概念和遇到的一些问题，这篇讲的是AutoLayout下的动画。自动布局已经比传统的Frame复杂，动画也会稍微更复杂些。期望通过这篇文章，能够对AutoLayout下的动画有理解，并且能完成一般的动画。
在讲动画之前，先讲几个常见的可能会混淆的方法。
setNeedsLayout layoutIfNeeded layoutSubViews setNeedsUpdateConstraints updateConstraitsIfNeed updateConstraints
子视图在界面上的显示大概经过了：更新约束-通过约束依赖关系得到具体的frame-展示到界面。上面几个是和autolayout相关的方法，有必要大概了解一下这些方法具体是怎么用的以及在什么情况下触发。
1.[layoutView setNeedsUpdateConstraints]:告诉layoutView需要更新约束，在下次计算或者更新约束会更新约束 2.[layoutView updateConstraintsIfNeeded]:告诉layoutView立即更新约束， 3.updateConstraints:系统更新约束的实际方法总结上面的3点就是，setNeedsUpdateConstraints确保了在将来某一时刻调用updateConstraintsIfNeeded之后会接着调用updateConstraints，从而达到更新view的约束的目的。但是要注意的是，如果仅仅单独调用2，不一定能够保证会调用updateConstraints，因为如果view上的约束是没有变动的且没有标记需要update的，这时就不会调用updateConstraints。
4.[layoutView setNeedsLayout]:告诉layoutView页面需要更新，但不立即执行 5.[layoutView layoutIfNeeded]:告诉layoutView页面布局立即更新 6.layoutSubviews:系统重写布局的实际方法总结以上3点，setNeedsLayout确保了在将来某个时刻通过调用layoutIfNeeded之后会调用系统的layoutSubviews，从而重写对view重新布局。同样的如果单独调用5，不一定能够保证调用layoutSubviews。[注：笔者写了个demo发现，调用setNeedsLayout会直接调用layoutSubviews]。如果想要每次都能立即更新布局，那就要把两个方法一起用，同样也适用于1和2。
系统调用layoutSubViews时，就会调用updateConstraintsIfNeeded，通过更新约束，用superView到subView的层次顺序，来计算frame，反向确定布局。
stackoverflow上有关于上面几个方法的深入解答并分享了作者的实用经验：
如果仅想要立即改变约束，调用setNeedsLayout如果改变view的一些属性（如offsets）可能会导致布局的改变，那么调用setNeedsUpdateConstraints，更多的时候后面需要加setNeedsLayout。如果想要立即改变布局，如会形成新的frame，那么需要在调用layoutIfNeeded。###[UIView animateWithDuration]方法
传统的动画主要是通过计算frame来进行动画，在autolayout下，主要是利用约束，动画的本质实际上是从一种约束状态变成另一种约束状态，从而来达到动画的目的。
这个例子的Demo在这里。
ViewController.h文件中：
@property (weak, nonatomic) IBOutlet UIView *animateView; @property (weak, nonatomic) IBOutlet NSLayoutConstraint *leftConstraint;通过改变leftConstraint的值来实现具体的平移动画，具体代码如下：
self.leftConstraint.constant = 200; [UIView animateWithDuration:2 animations:^{ [self.view layoutIfNeeded]; }];对于这类简单动画，只需要在animation的block中调用layoutIfNeeded即可，从经验来看，只要调用这个方法即可。
如果你厌倦了苹果官方的NSLayoutConstraint的繁杂写法以及VFL的奇怪语法，那么Masonry是个不错的选择。
Masonry的官方介绍，它是一个轻量级的布局框架，拥有自己的描述语法，采用优雅的链式语法封装自动布局，更加简单的添加和更新约束，提供了友好的属性和Debug功能，支持iOS和Mac，最重要的是大大提高了可读性。
目前Masonry处于维护状态（bugfix），原因是它的开发人员考虑到越来越多的人会用swift，所以开发人员更专注开发其swift版本–SnpaKit。这篇文章仍然用Masonry。
用cocoaPods引用Masonry:
pod 'Masonry'Masonry提供了非常优雅的属性和方法：
Masonry提供的属性及其对应的NSLayoutAttribute关系如下：
MASViewAttribute NSLayoutAttribute view.mas_left NSLayoutAttributeLeft view.mas_right NSLayoutAttributeRight view.mas_top NSLayoutAttributeTop view.mas_bottom NSLayoutAttributeBottom view.mas_leading NSLayoutAttributeLeading view.mas_trailing NSLayoutAttributeTrailing view.mas_width NSLayoutAttributeWidth view.mas_height NSLayoutAttributeHeight view.mas_centerX NSLayoutAttributeCenterX view.mas_centerY NSLayoutAttributeCenterY view.mas_baseline NSLayoutAttributeBaseline我们可以很方便的获得到属性。
edges
//让当前view的top bottom left right和view2完全一样，表现为和view2大小一样 make.edges.equalTo(view2); // 让当前view进行这样的约束：top = superview.top + 5, left = superview.left + 10,bottom = superview.bottom - 15, right = superview.right - 20 make.edges.equalTo(superview).insets(UIEdgeInsetsMake(5, 10, 15, 20))size
//让当前view的size相对于titleLabel的size要greater than or equal to make.size.greaterThanOrEqualTo(titleLabel) // 让当前view进行约束：width = superview.width + 100, height = superview.height - 50 make.size.equalTo(superview).sizeOffset(CGSizeMake(100, -50))center
// 当前view的中心点和button1相等 make.center.equalTo(button1) // 当前view约束：centerX = superview.centerX - 5, centerY = superview.centerY + 10 make.center.equalTo(superview).centerOffset(CGPointMake(-5, 10))还可以将属性连起来写：
// 左右低对superview对齐，高和otherView对齐 make.left.right.and.bottom.equalTo(superview); //接近于自然语言了 make.top.equalTo(otherView);1.mas_makeConstraints
给view添加约束的方法，
[masView mas_makeConstraints:^(MASConstraintMaker *make) { make.leading.equalTo(self.view).offset(20); make.top.equalTo(self.view).offset(200); make.width.offset(80); make.height.offset(80); }];2.mas_updateConstraints 更新约束的方法，如果view已经使用了mas_makeConstraints这个方法后，在更新约束时需使用这个方法。
3.mas_remakeConstraints 重新添加约束，它是先将view上的约束全部uninstall掉，然后添加约束。
在添加约束的时候避免不了的会遇到约束错误，苹果原生的报错真的很不友好，让人看不懂，如下：
Unable to simultaneously satisfy constraints.....blah blah blah.... ( "<NSLayoutConstraint:0x7189ac0 V:[UILabel:0x7186980(>=5000)]>", "<NSAutoresizingMaskLayoutConstraint:0x839ea20 h=--& v=--& V:[MASExampleDebuggingView:0x7186560(416)]>", "<NSLayoutConstraint:0x7189c70 UILabel:0x7186980.bottom == MASExampleDebuggingView:0x7186560.bottom - 10>", "<NSLayoutConstraint:0x7189560 V:|-(1)-[UILabel:0x7186980] (Names: '|':MASExampleDebuggingView:0x7186560 )>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x7189ac0 V:[UILabel:0x7186980(>=5000)]>光UILabel:0x7186980可能也会非上一点时间找具体的Label是哪个。
Masonry重写了NSLayoutConstraint的(NSString *)description的方法，使得一起看起来较为友好了：
Unable to simultaneously satisfy constraints......blah blah blah.... ( "<NSAutoresizingMaskLayoutConstraint:0x8887740 MASExampleDebuggingView:superview.height == 416>", "<MASLayoutConstraint:ConstantConstraint UILabel:messageLabel.height >= 5000>", "<MASLayoutConstraint:BottomConstraint UILabel:messageLabel.bottom == MASExampleDebuggingView:superview.bottom - 10>", "<MASLayoutConstraint:ConflictingConstraint[0] UILabel:messageLabel.top == MASExampleDebuggingView:superview.top + 1>" ) Will attempt to recover by breaking constraint <MASLayoutConstraint:ConstantConstraint UILabel:messageLabel.height >= 5000>可以具体是UILabel:messageLabel.height出了问题。
在ViewController.m中，先对masView进行约束：
masView = [UIView new]; masView.backgroundColor = [UIColor redColor]; [self.view addSubview:masView]; [masView mas_makeConstraints:^(MASConstraintMaker *make) { make.leading.equalTo(self.view).offset(20);//距离self.view左侧20 make.top.equalTo(self.view).offset(200);//距离self.view顶部200 make.width.offset(80);//宽度80 make.height.offset(80);//高度80 }];动画的实现代码：
[masView mas_updateConstraints:^(MASConstraintMaker *make) { make.width.and.height.offset(100); make.leading.equalTo(self.view).offset(100); }]; [UIView animateWithDuration:3 animations:^{ [self.view layoutIfNeeded]; }];先用mas_updateConstraints更新masView的约束，然后调用animateWithDuration方法。
通过用masonry实现的动画可读性更高，利于维护，且能实现比较多的动画效果。
实践出真知，需要通过实际项目来进行实践验证。我也总结项目过程中的一些实际经验：
不能有任何一个约束的warning。对于约束的warning是要引起最够重视的，我们发现在iOS8下约束的warning没有引起crash，但是在iOS6上却crash。这个原因应该是苹果开发autolayout的历史变迁所致。所以当我们发现约束有warning的时候一定要改正确，项目中保证0warning。复杂页面的约束出现较多约束错误时，可以先清掉所有的约束，重新加约束。有时候发现约束越改越混乱，不如清掉所有的约束重新理清思路加约束。动画不一定非要是约束动画。我们知道autolayout到最终都是转化为对应的frame，所以frame是关键点。当一个视图（superView）布局好了之后，它的subView实际上仍然可以用传统的frame进行动画，不一定非要写约束。但是这个方法是不倡导的，既然用了约束就该将约束进行到底。牺牲了部分的效率。约束在转化为具体的frame过程中必然会产生性能上的问题，我们发现在iPhone4的iOS6上面表现的效果并不是很好，但是随着硬件的越来越强大，这个性能问题最终会被忽略掉的。对于一般应用类的app上的动画效果，使用上述方法已经足够。方法最够的简单，需要理解的是其中的约束思想。文中用到的demo已经上传到这里。
通过这三篇关于AutoLayout的介绍文章，相信足以解决AutoLayout这个问题了。
