多storyboard协作开发

学习IOS开发是从xib开始，再到学习auto layout发现自动布局，适配多款机型，用起来非常顺手，效率也是不低，当然也曾经使用纯代码封装一些控件，不得不说使用纯代码编写UI对抽象能力、想象能力是一个很大的考验，需要对控件各种使用方式有了足够的了解。对比而言还是更喜欢使用xib、storyboard的编写方式，对纯代码写UI有一定的抵触，原因有二：

1.纯代码写UI效率太慢，尤其是不适用constraint，计算坐标的方法对不同分辨率只是使用等比缩放；2.直观性差，打开一个viewController，UI布局代码就占用了上百行。

但使用纯代码写UI的好处在于:

1.版本维护性好，无论是使用svn、还是git管理代码，不同版本间的差异对比十分直观，merge起来也是轻车熟路；
2.可复用性高，对于某些常用、优秀的控件，在不断的积累和使用过程中，不断修改、进化。可以封装出适用性广、性能优良的控件。

关于这三者之间的争论没有停止过，一般情况下对于有一定历史、多人协作开发的项目中，倾向于使用纯代码编写UI，甚至很多项目明确要求不得使用xib、storyboard。但是从历年WWDC的潮流来看，使用xib、storyboard是未来开发方向。
代码手写UI，xib和StoryBoard间的博弈，以及Interface Builder的一些小技巧
UI到底应该用xib/storyboard完成，还是用手写代码来完成？

最近接手的一个项目便是采用纯代码编写UI界面，而我本身倾向于使用xib、storyboard写界面，于是对这个问题进行了一番思考，看了很多相关讨论、结合自身兴趣、以及未来发展而言。在原生开发中我更倾向于使用xib、storyboard开发界面。
而多storyboard协作开发正是本文的一点思考与探索。使用storyboard开发的优势在于：

1 原型既成品：用storyboard可以一行代码都不写，非常快速的做出界面交互的原型设计。
2 直观：利于我们在项目初期整体的规划项目，对整体有一个宏观的把控。
3 简单：页面跳转管理统一在一起、简洁清晰。通过连接segue、或者页面从属关系

不好的地方在上两篇文章中已经列出很多，尤其对于单一storyboard的项目，随着业务功能的增加，整个storyboard中内容增多，会变得非常复杂。那是否可以考虑使用多个storyboard 对不同业务功能、不同开发分工进行工作分割呢？
IOS9 中引入了storyboard reference，可以将一个复杂的storyboard分割成多个小的storyboard，对于实际项目中可以使用该功能实现功能业务的模块化、对于多人协作项目也可以按人分配，主storyboard中设计好storyboard reference入口，每个开发者对自己开发的storyboard负责。(再次证明，Apple对于使用storyboard进行UI布局的支持)
对storyboard reference更进一步的使用，可参考Apple官方例子，或以下文章。
iOS 9 学习系列：Storyboard References
针对以上思考与调研学习，坚定了在后续项目开发中使用storyboard的决心，当然不否定使用纯代码编写UI的做法，3中方式灵活使用：在宏观布局中使用storyboard快熟搭建App，对于需要定制的控件，多积累、多应用。封装出优秀的、复用度高的控件。
多storyboard协作开发Demo

最后，附一点小知识，对于新建的storyboard，拖拉viewController进来时，因为没有设置storyboard entry point，会有以下报错：

ain.storyboard references the initial view controller of First.storyboard, but no designated entry point was found.

用以下方法添加storyboard entry point，指向storyboard启动后第一个加载的viewController。