iOS-UI布局 Xib，Masonry，Frame之间的比较选取

image

如果你要让两个iOS开发吵起来，只需要说一句：Frame布局比Masonry好!

iOS常见的布局方式有三种：xib, Masonry,frame,相信对于iOS开发者来说,这三种布局并不陌生，并且时常会看到Frame与Masonry谁更好的争论，其实并没有谁比谁好这一说，只有谁比谁更合适当前项目，灵活运用才是王道

Xib: 基于Autolayout，简单，上手快，可视化视图大大提升了开发效率，缺点是静态布局不够灵活，修改麻烦，性能相对其他会稍低一点，适合需要快速开发，页面较为固定的项目
Masonry: 基于Autolayout,布局上比Xib灵活，适配方便快速，缺点是约束有错误不直观，且容易代码冗余,性能次于Frame，适合需要快速迭代，产品经理脑洞贼大经常修改的UI的项目
Frame: 纯手工计算，适用于复杂、多变的页面，性能最好，布局最灵活，做动画相对比Masonry方便；缺点是需要大量的计算，容易造成阅读困难，接手难度大

这里一般会有三个疑问

一. 为什么说Frame的性能比Masonry的好，Xib的次之？

Masonry和Xib都是基于Autolayout相对布局，所有的相对布局最终都会转换成Frame绝对布局；AutoLayout是线性方程组求解，当计算过多时，会占据较大系统内存，甚至影响GPU绘制造成卡顿，这也是很多人尽量压缩视图层级，减少计算量的原因；Frame则干脆得多,基于XY坐标轴系统的布局。从数学上限定了UI控件的具体位置，是iOS开发中最底层、最基本的界面布局机制。
就像是去电影院找位置，直接说第几排第几座肯定比“距离最右边第三个距上边第十个位置”这种说法来的省力一些；至于Xib原理和Autolayout一样，但多耗费了些性能在图形转化上

二. 上面三种对各种尺寸屏的适配和使用上如何？

这点综合起来Masonry占优，纯代码设计，在页面布局的操控上会更为方便，控件间的关系也一目了然。但这里需要提一下一些没接触过Xib和Frame上的一些错误理解

在Xib设置的高度是死的，且不能根据屏幕大小适配？

Xib可以可以将高度约束NSLayoutConstraint引出，设置NSLayoutConstraint的constant即可随意修改高度，而且可以通过添加分类

- (void)setAdapterScreen:(BOOL)adapterScreen{
    adapterScreen = adapterScreen;
    if (adapterScreen) {
        //这里也可以改成以其他屏幕为基准
        self.constant = self.constant * ([UIScreen mainScreen].bounds.size.width / 375.0);
    }
}
- (BOOL)adapterScreen{
    return YES;
}

后面在需要适配的NSLayoutConstraint上Adapter Screen修改为On即可，修改后的NSLayoutConstraint都会跑这个方法适配。这两个配合基本可以满足大部分页面的适配需求。

Frame是停留在4s年代的远古布局，各种值也是死的，不能根据屏幕大小适配？

Frame不是停留在4S年代的布局，而是怎么都不会变动的的基础，所有布局最终转换的目的，诚然使用Autolayout能帮我们减少大量的计算，但这些是基于损耗性能的情况下进行的，如果对性能有较高的追求的话，一般都建议用Frame布局。
没接触过的很多人不理解Frame的情况下，会本能的认为Frame就是写死几个值，后续根据各种屏幕判断值，刘海屏什么的都要单独适配，这个认知是错误的，一般在熟悉Frame布局的人都会设置好宏定义

// 屏幕宽
#define kScreenW                         ([UIScreen mainScreen].bounds.size.width)
// 屏幕高
#define kScreenH                         ([UIScreen mainScreen].bounds.size.height)
// 适配iPhone X 状态栏高度
#define  kScreenStatusBarHeight          (iPhoneX ? 44.f : 20.f)
// 适配iPhone X 导航栏高度
#define  kScreenNavHeight                (iPhoneX ? 88.f : 64.f)
// 状态栏
#define kNavH                            (iPhoneX ? 88.f : 64.f)        
// iPhone X
#define iPhoneX (([[UIScreen mainScreen] bounds].size.height - 812) ? NO : YES)

使用时

_tableView = [[UITableView alloc]initWithFrame:CGRectMake(0, 0, kScreenW, self.view.height - kNavH) style:UITableViewStyleGrouped];

这样就很方便的根据各种情况进行适配，本身代码量并不会增加多少，而性能却提升不少。

三. 这些布局应该如何选取

在我看来，这三种布局的优缺点都非常的明显，根据项目本身需求选取对应的方式即可。上面提到非常多次的性能问题，但随着手机性能的不断提高，一些性能损耗的对App的影响越来越小

在项目较小，页面变动不大，需要快速开发的情况下，Xib也是一个很好的选择，苹果本身推出Xib的原因就是为了让程序员把更多的精力放在业务逻辑上；
在项目迭代频率较高，产品脑洞奇大，经常需要修改UI的情况下，建议用Masonry。
在页面较为复杂，或追求操作顺滑，或页面有动画的情况下Frame才是最佳。