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

若是你要让两个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才是最佳；

这里并没有意讨论三者间的优劣，技术的选取自己就是要看项目需求，只是我看到网上太多开发者固守Masonry/frame/xib而一昧的贬低其余，做为一个开发人员应该更多的走出本身的温馨区，尝试各类开发方案