Masonry 宏定义的尴尬（Masonry和UIView+position等分类冲突的问题）

Masonry在 iOS 开发界的名气相信不用多做介绍了, 大部分开发者在使用Masonry的过程中都会导入2个全局的宏来提高开发效率.

#define MAS_SHORTHAND
#define MAS_SHORTHAND_GLOBALS

这2个宏有什么作用呢?
#define MAS_SHORTHAND可以让你在调用约束方法和设置约束参数时省掉mas_前缀.

[aView mas_makeConstraints:^(MASConstraintMaker *make) {    

        make.left.equalTo(bView.mas_right);
        make.top.equalTo(bView.mas_bottom).offset(50);
        make.width.height.equalTo(@100);
}];

// 加宏后
[aView makeConstraints:^(MASConstraintMaker *make) {    

        make.left.equalTo(bView.right);
        make.top.equalTo(bView.bottom).offset(50);
        make.width.height.equalTo(@100);
}];

而#define MAS_SHORTHAND_GLOBALS也是用来省掉mas_前缀的, 在介绍这个宏之前我们先来了解一下不加此宏时最早期的约束写法.

        make.left.equalTo(bView.mas_right);
        make.top.equalTo(bView.mas_bottom).offset(50);
        make.width.height.equalTo(@100);

可以看出, 在约束数值时我们需要包装成 NSNumber 对象再传入. 为了节省这一包装操作, 后来加入了mas_前缀的宏, 使得我们可以不用再对数值进行包装.

        make.left.mas_equalTo(bView.mas_right);
        make.top.mas_equalTo(bView.mas_bottom).mas_offset(50);
        make.width.height.mas_equalTo(100);

至于offset和mas_offset的区别没弄懂...希望有知道的大大可以告诉我一下, 万分感激. 加入这个宏虽然节省了对数值进行包装的操作, 不过每次都要敲mas_前缀的宏也是挺麻烦的, 所以最后便有了#define MAS_SHORTHAND_GLOBALS的出现, 只要写上这个宏, 上面的mas_前缀宏就可以省掉了.

        make.left.equalTo(bView.mas_right);
        make.top.equalTo(bView.mas_bottom).offset(50);
        make.width.height.equalTo(100);

如果2个宏都写上的话, 最后代码就可以写成这样了.

[aView makeConstraints:^(MASConstraintMaker *make) {
>
        make.left.equalTo(bView.right);
        make.top.equalTo(bView.bottom).offset(50);
        make.width.height.equalTo(100);
}];

确实是清爽了许多, 难怪很多人都会在工程中加入这2个宏, 但事与愿违, 有时却会造成一些尴尬的情况.

UIView 分类

在开发中, 我们往往会为 UIView 写上一个分类, 加入width, height, x, y等属性方便我们使用, 比如说我们拿一个 view 的width属性需要view.bounds.size.width, 写上分类后我们只需要view.width就可以了, 非常方便, 那你可能会问, 这跟Masonry的宏有什么关系呢?

冲突

还记得第1个宏#define MAS_SHORTHAND吗? 今天的主角就是它了, 它可以帮我们把控件的mas_xxx属性的mas_前缀省掉, 比如我们想要约束 aView 的高度跟 bView 的宽度一样, 我们会这样写.

make.height.equalTo(bView.width);

那么问题来了, 括号中width返回的是我们分类中的宽度数值还是Masonry中的约束对象呢? 所以就产生冲突了.
编译是不会有问题的, 可是只要代码一运行到这一行就会悲剧了...事实上只要写入了这个宏, 即使不调用约束的方法, 只是随便访问一下控件的width或height属性, 结果也一样.

这里需要说明一下的是, 最新的Masonry已经不会崩了, 不过拿到的也不是我们想要的东西, 比如说获取控件的width或height属性值都是0, 而像make.height.equalTo(bView.width);这样的约束也不起作用...

这就是Masonry宏定义尴尬的地方了, 个人觉得, 可能还是分类的便捷性更为优先, 所以只能牺牲掉这个宏了. 当然你也可以在 UIView 分类所添加的属性名中加上一个前缀, 这也是业界推荐的做法, 用起来麻烦一点就是了.