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而一昧的贬低其他,作为一个开发人员应该更多的走出自己的舒适区,尝试各种开发方案