xib学习周计划：1——xib文件的基本认识-白红宇

xib学习周计划：1——xib文件的基本认识

阅读量：4296 次

发布时间：2019-05-27

本文共 7093 字，大约阅读时间需要 23 分钟。

前言

近3年APP软件出现爆发式增长，开发迭代速度论天算，纯代码开发由来已久，目前在大厂，主流开发还是纯代码居多，为了协同和兼容低版本，个别大厂的老项目甚至是禁用xib开发的。中小公司的新产品线，为了开发效率，xib开发比例相对较大，并开始转向swift语言。我的前3个项目是用纯代码写的，最近的3个项目主要是xib为主，以下是我总结的xib的优缺点，这个问题其实相对主观，没有绝对，个人观点，仅供参考。

xib优缺点分析

缺点

1.有一定的学习成本

2.没有代码表达清晰

3.出错不易发现，无法调试，尤其是“连线”出了问题

4.文件易冲突，且难解决，不利于团队合作，尤其是在团队中用SB

5.执行效率没有代码高

6.有时不利于封装

优点

1.开发效率高

2.减少大量胶水代码

3.通过xib可以快速、高效的学习控件

4.适配性明显优于代码（auto layout、size classes）

5.能做的事情比你想象中的要多

优缺点的一些个人看法

有学习成本的事情，要看值不值得去做，而xib绝对是值得去做的，因为xib对效率提升帮助相当巨大，是大势所趋，因为无论是iOS开发还是Mac OS X开发，都没有像Android那样丰富的布局概念的引入，如果没有xib，还停留在手写UI的时代，可以说UI开发上Android完爆iOS，但如果用xib进行UI开发，则iOS的优势更大。

2015 WWDC session 215——What's New in Storyboard中，苹果的演讲嘉宾现场统计用xib开发人数的占比已经很高了。我个人对学习新东西一直充满热情，虽然有时浅尝辄止，做技术就是要不断学习，要享受这个过程。

xib的确有时不如代码表达清晰，尤其是“连线”很多的时候，但是如果你对xib很熟悉，看别人的xib远比看别人的代码效率要高很多。

xib有时候出错是不容易被发现，尤其是在对xib掌握不是很好的情况下，多连一条线、少连一条线的错误很难看出来。

xib文件产生的冲突其实很容易被解决，下文中有详细说明。

xib文件实质还是xml文件，执行效率和纯代码的运行效率的差别几乎不及，如有可能xib文件加载太多（几十个）控件造成效率问题，少年不要怀疑xib，是你的xib文件需要逻辑拆分。但是就现在的硬件水平和一般的需求来说，是没有差别可言的。

xib的确有时会使得对象难以封装，但是如果用了xib你会发现有些封装也不是必要的了，因为xib如此方便，拷贝一个xib出来改改就是了。其实如果你对xib掌握及其熟练、对封装理解很好的话，其实xib有时会提高封装性，举个简单的例子：比如现在有个基类叫BrandView，BrandView有个logo的属性，这个属性是UIView的实例，根据不同的品牌展现不同样式的logo，BenzBrandView和BMWBrandView都继承自BrandView，且都是用xib来管理UI的，那么我们就可以在基类中声明：

@property (nonatomic, strong) IBOutlet UILabel *brandLabel;

而在子类的xib文件中分别与基类的这个IBOutlet属性“连线”，这样既将属性“抽”到了基类中，又不用基类写创建的代码，就是说基类可以利用子类的xib文件与自己做关联从而避免了创建UI的代码，同时又能实现很好的封装。

优点方面：不需要繁琐地、千篇一律地创建对象、布局对象，也不再使用代码给属性赋值。SB还会省去很多页面跳转之间的胶水代码（segue），甚至不用写代码就能实现在各个页面中切换，tableView的cell可以直接拖到tableView里，可以给tableView添加header、footer，可以添加手势、设置代理、size classes使得适配变得更加容易、xib也使得国际化变得很容易、可以通过代码给xib动态加入属性...这些东西，有些根本不用写代码，有些只需写极少量代码就能实现。

xib文件的搭建

首先来一个官方说明：

A nib file describes the visual elements of your application’s user interface, including windows, views, controls, and many others. It can also describe non-visual elements, such as the objects in your application that manage your windows and views.

nib文件是描述应用外观的视觉元素，包含了窗口、视图、控制和其他，它也可以描述非视觉元素，如你应用中管理窗口和视图的对象。

通常官方说明都很晦涩，下面浅显、直白地解释一下。等等，说好的xib、SB的，怎么还没开始，就又弄出来了一个nib？别急，现在就开始慢慢道来。

创建Demo工程

我们首先建一个基于single view application模板的工程，叫xibDemo，为了后面演示。然后command + n，调出新建文件的窗口，然后选择iOS->User Interface->Empty，新建一个空的xib文件，名字叫TestXib，点击该文件，command + option + 0，调出右边栏。

在最下面选择UIView，像拖动文件一样拖动到中间空白处松手，如果是新版的Xcode，显示的View可能是正方形的，这是由于xib文件自动开启了size classes功能，该功能是做适配用的，我们这里为了屏幕显示全，暂时去掉该功能，然后像刚刚一样，拖一个UIButton，到这个View，取名hello world。

xib、storyboard、nib总体认识

xib是一个可视化文件，我们通过选中并拖动UI控件到"画布"上，就能可视化的创建UI控件，并对其进行布局，SB可以理解成为加强版的xib，它功能更加强大，同时也可以理解成为把多个xib文件合成为了一个.storyboard文件，而实际上xib与SB都是xml格式的文件，所以其实我们是可以以两种方式查看一个xib或SB文件的，这也为我们日后解决xib文件引起的冲突找到了一个突破口。

注：xib、storyboard都属于资源文件，而不是源文件，这一点十分重要，切记。

nib是经过Xcode编译之后的，加密的文件，是无法在用Xcode正常打开的，SB文件在编译之后变成了.storyboardc文件(例如：Main.storyboardc)，也是打不开的，两者都是存放在app的main bundle中。

xib、 storyboard文件的创建

xib文件的创建

目前我们简单的理解：只有UIViewController、UIView的子类才能使用xib文件，他们两者在创建和使用xib的时候是有所不同的。

1.为UIViewController子类创建对应的xib文件

创建文件的时候勾选also create xib file即可

2.为UIView子类创建xib文件

这个过程比上面要稍微复杂一点，1）先分别创建UIView子类文件和xib文件。2）将两者建立起关系。通常我们一般习惯将两者命名为相同的名字,当然，不同也是可以的。给一个类与一个 xib文件建立关系是很重要的一步，具体方法：右边栏第三个选项(show the identity inspector)下面的custom class-> class中填写你要与该xib绑定的UIView子类的名字

其实UIView子类创建xib文件的方法也是适用于UIViewController的，只是，我们在创建一个VC类的时候默认有勾选xib的选项，比较方便，如果我们为现有的、且没有xib文件的VC创建一个xib的话，就用这种方法，其实在早期xcode中，我们创建UIView子类的时候也是可以勾选xib的，只是后来版本的Xcode不提供该功能了。

SB文件的创建

从xib文件的创建我们可以看出，xib文件是与UIViewController或UIView的子类保持一一对应的（一般情况下），但是SB文件却不然，主要表现在两个方面：

1.SB只能被UIViewController的子类使用，并不能被UIView的子类使用。

2.SB与UIViewController可以是一对多的关系，一般情况下也往往是如此的。所以，当我们建立了一个.storyboard文件之后并不能像xib一样往里面拖View了，只能拖VC。

xib、storyboard文件的使用

xib文件的使用

1.基于UIViewController子类的xib的使用

这种情况下使用很简单，对VC直接alloc，init就可以，VC会自动去找自己对应的xib文件，即使我们自定义了一些init方法，也不需要对加载他的xib做处理，系统会自动帮我们找是否有与其对应的xib文件，例如我们有这样一个初始化方法：

- (instancetype)initWithCustemData:(id)aData;

我们在创建VC实例的时候可以直接调用这个函数，不用理会xib文件的问题，我们的父类在初始化的时候去自动帮我们找与之对应的xib文件，那么问题来了，父类怎么知道我有没有xib文件呢？是这样，父类会判断有没有和我们这个要初始化的VC相同名字的xib文件，如果有就会加载该xib文件，如果没有，父类就认为我们该VC没有xib文件，就会走正常的init方法。

加载xib的init方法是：

- (instancetype)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil;

如果一旦我们的VC类的名字与对应的xib文件名字不同的时候，我们就必须调用这个初始化方法来创建VC实例了；

[[ViewController alloc] initWithNibName:@"xxx" bundle:[NSBundle mainBundle]]

xxx的地方填那个与我们VC类名不同的那个xib文件的名字，不过一般情况下，我们的VC都与xib保持相同的名字，这里只是想说明，如果名字不同也是可以的。

2.基于UIView子类的xib的使用

TestView *tView = [[NSBundle mainBundle] loadNibNamed:@"TestView" owner:self options:nil][0];

上述代码再次说明xib文件是资源文件，放在main bundle中，@"TestView"是xib文件的名称，后面两个参数暂时不用了解，就固定传self和nil就行，值得说的是，loadNibNamed: owner: options方法返回的是一个数组，而不直接是对象，这是考虑到了Mac开发会有多个对象返回的情况，在iOS开发中就只有一个，固定取[0]就行。

注：一般的UIView对象，代码初始化的时候都会调用initWithFrame:方法，但是用xib创建的UIView对象是不会调用此方法的，因为该对象的Frame在xib文件中就可以确定了。以xib的形式保存控件对象的过程其实叫做固化(archive)，通过xib文件创建控件的过程叫做解固(unarchive)，固化是iOS持久化的一种比较好的解决方案，以后有机会会说说iOS持久化的各种方式的优劣，这里不再深入，而与固化相关的初始化函数是：

- (instancetype)initWithCoder:(NSCoder *)aDecoder

所以，当以xib创建UIView对象的时候这个函数会调用，之前在initWithFrame:中要做的事情，可以放在initWithCoder:中，或者放在：

- (void)awakeFromNib{    [super awakeFromNib];    //...}

该函数会在initWithCoder:后调用，从名字我们就能看出，这个函数的触发时机是控件已经从xib文件中“解固”之后，两个函数之间的关系有点像VC的loadView和viewDidLoad之间的关系。

SB文件的使用

由于SB文件与VC一般是一对多的关系，所以我们不仅要知道即将创建的这个VC的实例对象是加载的哪个SB，而且还要知道加载的是该SB中的哪个具体的VC。

SecVC *secVC = [[UIStoryboard storyboardWithName:@"Demo" bundle:[NSBundle mainBundle]] instantiateViewControllerWithIdentifier:@"SecVC"];

@"Demo"参数代表SB的文件名字，@"SecVC"代表该VC在SB中的ID，具体使用会在下面的文章中提到。个人建议，该ID最好与类名相同，这样便于将实例化的方法封在基类中。eg：

#import 
   
    @interface GJBasicController : UIViewController+ (NSString *)gj_storyboardID;+ (instancetype)gj_controllerInstanceFromStoryboardWithName:(NSString *)aStoryboardName;@end

#import "GJBasicController.h"@implementation GJBasicController+ (NSString *)gj_storyboardID{    return NSStringFromClass([self class]);}+ (instancetype)gj_controllerInstanceFromStoryboardWithName:(NSString *)aStoryboardName{    return [[UIStoryboard storyboardWithName:aStoryboardName bundle:[NSBundle mainBundle]] instantiateViewControllerWithIdentifier:[self storyboardID]];}@end

xib、SB文件冲突的解决

前文中列出的xib的缺点当中，我想在代码管理上，文件容易冲突是比较典型、且重要的问题，那么在详细学习xib之前，先来学习解决文件冲突的问题会让大家的学习更有积极性。

注：xib与SB文件的冲突问题是一样的，解决方法也一样。

为什么xib、SB文件会很容易冲突？

因为xib文件十分容易造成修改，它不像源文件中的代码，必须真正修改才算，xib和SB文件，只要你点开，不经意的点击几个控件看看，就很容易造成了文件的修改，因为你很容易把控件挪动了1、2个像素，而你自己不知道，我们之前说过xib文件其实是以xml形式存储的，你挪动了1、2个像素这个文件也算修改过了。

如何避免xib、SB文件造成冲突？

1.最好在分工上就使得一个xib或SB文件单独由一个人负责开发、修改。xib做到这一点相对容易，因为它和源文件最多是一对一的关系（有时可以没有源文件而直接使用），SB一般与源文件是一对多的关系，如何把每个人负责的任务对应到自己的SB文件中？这个时候可能要用到storyboard reference，我们在后续文章中会讲到这个问题。

2.在修改xib、SB文件的时候加锁（这个是代码管理层次上的问题，其实必要性不大，操作也繁琐）

3.提交代码的时候看清楚有没有提交xib、SB文件，弄清楚这个提交是自己要修改的，还是不小心就修改了。

如果冲突已经产生了，如何解决冲突？

上文中提到过，xib、SB文件有两种查看方式,当文件冲突的时候普通的interface builder方式打开文件会失败，参考样式。

解决思路

可以想到，应该是合并造成xib文件版本冲突，一种简单的方式可以拿最新的版本直接覆盖出问题的xib文件。但是这种办法简单粗暴，没有深入探究该xib文件问题到底出在哪里。联想到代码发生版本冲突时，头文件或实现文件中，会标记出冲突的代码，那么出问题的xib文件对应的源码中同样也应该存在冲突的代码。带着这样的想法，我打开了该xib文件的源码。

选中xib文件->右键->Open As->Source Code,打开xib文件对应的xml文档：