引言
"一天一点爱恋，一夜一点思念~~"，这是梁朝伟的一首歌，讲解xib用这个标题，主要是个人比较喜欢梁朝伟演的电影，而且这首歌也算是经典，但最重要原因是很多程序员对xib并没有"爱恋"，这部分一共九篇文章，就是为了帮助广大程序员对xib产生"爱恋"与"思念"。(文中的xib也包括storyboard，后面专门提高storyboard的地方统一简写为SB)
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:3先学会解决文件冲突中有详细说明。
xib执行效率的确没有代码效率高，因为加载要多一步——把xib文件加载到内存中，当年我在iOS4上用iPad一代开发的时候，就有明显感觉——一个页面xib文件过多（当时用xib做表单提交数据，大概有60、70个控件）加载速度变慢（当时延时1、2s），但是就现在的硬件水平和一般的需求来说，这绝对不是瓶颈。
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的世界，共同学习、共同成长。
欢迎大家和我交流沟通，若文章中有错误和纰漏，恳请指正，谢谢。
网友评论