找到masonry结合view animation要这样处理的原因了，参考文章在此：
https://www.jianshu.com/p/eb2c4bb4e3f1
学习的深度还是需要自己去坚持！
（1）情景：
自定义一个类似如下的组件：
效果要类似原生action sheet的动效，支持数据源构建对应ui，同时要有交互的输出。
（2）问题
构建途中，仍然习惯使用masonry布局，思路是先根据数据源构建对应ui，待用户触发出现交互时弹出ui。
我这里首先将构建的ui置于屏幕外底部，alpha = 0，触发交互后，利用基础动画形成弹出效果。但是这种直接构建UI，然后在使用基础动画弹出的效果是错乱的，排除约束等位置信息可能的错误之后，决定用frame实现，frame果然没有问题。
（3）解决
参考网上资料，各种方法中，有的说要使用
[view.superView layoutIfNeeded];
重新设置layout属性时，应该调这个方法。但是我是调用基础动画，block中进行masonry的remake，按理说是可以进行约束更新的，不需要layoutIfNeeded，这是疑问1.
按照网上说法重新设置之后还是有错乱现象，然后又找资料，说是需要延迟处理，最后在调用动画出现的方法前加了一段小时间的延迟，masonry 的remake在延迟方法中， layoutIfNeeded在基础动画的block中达到了预期效果。
//更新约束
[self.cancelButton mas_remakeConstraints:^(MASConstraintMaker *make) {
make.left.equalTo(self).offset(15 * WidthScale);
make.right.equalTo(self).offset(- 15 * WidthScale);
make.height.mas_equalTo(44 * HEIGHT_SCALE);
make.bottom.equalTo(self).offset(- 15 * HEIGHT_SCALE);
}];
//使约束动画效果出现
[UIView animateWithDuration:0.25 animations:^{
[self.cancelButton.superview layoutIfNeeded];
}];
（4）思考
考虑到masonry的约束添加和更改与基础动画的动画实现都是在block中完成的，所以不会立即执行的。当第一次进行约束后，直接不延迟掉更改的约束动画，就很容易造成约束未定动画开始的现象。所以需要延迟执行；约束更改的语句是放在基础动画block之外的，block中只有layoutIfNeeded进行控件约束更新，这一点也是由于masonry的更新约束在block中而采用的方法，layoutIfNeeded相当于直接顺序执行改变约束了（我的思考）。
