Nib/Xib文件的产生，编译和运行本质[转]

 NIB 和 XIB 都是 Interface Builder 的图形界面设计文档。引用《Cocoa Programming for Mac OSX》一书的说法，Interface Builder 把窗口、菜单栏以及窗口上的各种控件的对象都“冻结”在了一个 NIB文档里面了；程序运行时，这些对象将会“苏醒”。

在终端下我们可以看到，NIB 其实是一个目录。它里面有两个也是后缀为 NIB 的文件：designable.nib 和 keyedobjects.nib。前者是一个 XML 文档，而后者则是一个二进制文件。Interface Builder 3 之后，引入了新的文档格式：XIB。它是单一的 XML 文档，也就是一个纯文本文件。纯文本文件的好处是显而易见的。嗯，就是便于源代码版本管理。现在最新版本的 Xcode 在创建项目时，已经默认使用 XIB 格式的文档了。

不论在 Interface Builder 中选择的是 NIB 还是 XIB 格式，Xcode 编译后都将得到一个供程序运行时使用的经过编译的 NIB 文件。
开说之前对以上的补充几点。
nib 的发展经过了nib2.0, nib3.0和xib.。nib2.0（nib文件夹中包含3个文件）和nib3.0（nib文件夹中包含2个文件）的文件结构相差一个二进制文件，且 2.0可读性不高，不过已经很少见到这种格式了。如果你发现的你nib还是这种格式，赶紧转换吧，利用IB的Save As....
另外建议工程里面全部使用xib，如果是nib3.0，也赶紧转换吧。因为nib2.0/3.0编译后nib中包含的界面信息不会被去除，程序发布出去后别人可以打开你的nib进行编辑查看的。
xib编译后生成二进制的nib文件，这个是不可打开编辑的，所以不会暴露你的接口什么的信息，而且如果包含二进制文件的话，你的代码管理系统是不能merge or diff的。
感谢simonwang补充
为什么会有这两种奇怪的名字?
         nibs这个名字来自于被Apple收购之前的NEXTSTEP系统.在NEXTSTEP被Apple拿下后, Apple给nib文件弄了一种新的基于XML Schema的文件格式,并且把nib的扩展名改为了xib.但是人们仍然习惯于把这种新的格式的文件称为nibs文件.所以我们会感觉nib这个词比较 奇怪,实际上道理和我们第一次见到类似"NS...这样子奇怪的名字是一样的,历史遗留而已. 
开讲。。。。。。（以下内容是本人自行研究出来的，没有任何官方文档的支持，如无把握，请勿自行修改nib文件，发生任何问题，本人概不负责！）
1）打开IB，新建一个Application的nib，拖一个tab和button进去，保存成sample.xib。如图
=700) window.open('http://cdn.cocimg.com/bbs/attachment/Fid_2/2_1860_2fdb321b3245f4d.png');" border=0 src=\'#\'" //cdn.cocimg.com/bbs/attachment/Fid_2/2_1860_2fdb321b3245f4d.png" onload="if(this.offsetWidth>'700')this.width='700';if(this.offsetHeight>'700')this.height='700';"> 
2）用textmate打开xib文件（右击选择open with...），收拢所有节点后你会看到一下内容。
=700) window.open('http://cdn.cocimg.com/bbs/attachment/Fid_2/2_1860_4ce6c19d40db4e7.png');" border=0 src=\'#\'" //cdn.cocimg.com/bbs/attachment/Fid_2/2_1860_4ce6c19d40db4e7.png" width=700 onload="if(this.offsetWidth>'700')this.width='700';if(this.offsetHeight>'700')this.height='700';"> 
从被黄色高亮的部分可以看出xib就是一个标准的xml文件，文件一开始标识出了当前使用的nib版本，即nib2.0/nib3.0/xib，此值不可修改！
另外可以看到很熟悉的字眼key，跟plist很像，但跟其不一样。xib里所有节点的顺序不可被改变，为什么呢？试一下就知道了，改了之后IB不认识了！
当然，谁没事去改变节点的顺序呢。不过可以深入探讨一下为什么不能改变，这样可以了解IB工作的部分原理。
（个人猜测，欢迎讨论）
观察根节点，是archive，Objective-C里什么叫做archive？数据永久化。IB运行时保存的都是object的信息，所以得进行序列化。
做过Java或者C++序列化的应该知道，你是怎么序列化的，那你就得怎么反序列化。
所以这些节点的排列顺序是有道理的。
我相信apple不会傻到直接来解析一个xml文件，xml文件应该是其序列化到文件的某一种反映形式，只要apple愿意，可以把这个文件写成任意形式。
所以拿xml文件的特点来对应nibfile的特点是不行的。当然，nib文件写成xml的格式增加了可读性，但是其很复杂，虽然每一个key都表明了它是干吗的，英语好的也能猜出来，但是其结构还是蛮复杂的，需要上下一一对应才能理解IB中资源对象的数据是什么样的。
被 桔黄色高亮的部分应该很容易就看出来是什么。这里有几个值会经常变化。比如team里两个人，一个用的10.5，另一个10.6。10.6创建这个 nib，10.5上打开nib看了下，保存。此时虽然没做任何改动，其实IB已经帮你改了，比如SystemVersion，这个就是你系统的build 版本，InterfaceBuilderVersion，这个是nibtool的版本，在如AppKitVersion之类的，所以你svn diff时发现只有这些东西变了的话，那就没关系的。
上面字里说到一个词，序列化。
话说一般序列化后不都是二进制文件么，为什么这里是xml格式的。恩，这就要讲到nib文件的编译和运行的原理了。
nib文件从创建，保存，编译到运行要经历两种序列化。
第一个是IB所用的文档的序列化，序列化的结果就是这个xml文件。它保存的是所有界面的资源信息和各个对象之间的关系。
第二个就是编译时对这个xml文件进行的序列化，序列化的结果就是2进制的nib文件。
写过IBPlugin的人应该知道，所有的控件必须支持initWithCoder和encodeWithCoder的NSCoding规范，这个就是用来被NSKeyedArchiver序列化用的。
编译时对xml文件做了如下操作
1，读取xml文件，生成所有界面对象，生成所有object（即自定义的controller类等），设置好各个obejct之间的联系（IBAction，IBOutlet）
2，对这一坨对象进行序列化，即调用encodeWithCoder方法来序列化，生成二进制nib文件
为什么要生成二进制文件，因为从二进制文件生成类实例更快一些。
运行时对nib的操作
1，反序列化，调用所有对象的initWithCoder方法
2，某些类的initWithFrame，init之类的方法被调用，生成所有类实例
3，发送awakeFromNib消息，每个类实例的awakeFromNib被调用
猜测nib2.0/3.0时代的多出来的二进制文件应该就是被编译序列化之后的文件，即nib2.0/3.0的nib文件由界面信息文件和运行时二进制文件组成。
由以上的可以看出，凡是被拖到nib里面的对象都会被自动创建实例，无需你代码手动创建（扫盲了。。。），需要用到的话，添加一个IBOutlet即可。
好了，解析完nib的文件结构之后，应该对IB的工作方式有了一个认识，也对你用IB打开nib后看到的东西的背后的实现方式也应该有了一个清晰的认识。
（iPhone的nib跟Mac没有区别，可以参考）

xib本质就是一个xml文件,这点在head first iphone上有清楚的解释。

本文转自:http://heidianfeng.blog.163.com/blog/static/6184345620107311175472/