ios开发学习1：开发的方法（转）

看完了OC语言，开始学习UI，看了一些资料写的很好就转过来。

现在开发IOS有3种方法，第一用纯代码来写，优点是后期维护修改比较容易，重用性高，缺点是速度比较慢，修改布局比较繁琐。

第二是用xib的方法，单个的xib文件对应一个 ViewController，而对于一些自定义的view，往往也会使用单个xib并从main bundle（捆绑）进行加载的方式来载入对于初学者来说，牢记xib的文件都是view的内容，有助于建立起较好的MVC的概念，从而在开发中避免或少走弯 路。优点是相比代码开发来说速度快，缺点是文件内容过于复杂，可读性很差，即使只是简单打开没有编辑也有可能造成变化而导致合并和提交的苦难。

在Xcode 5中Apple大幅简化了xib文件的格式，使其变得易读易维护。可以说现在对于xib文件在版本管理上其实和纯代码已经没有太大差异，只要仔细看过一遍 xib的文件内容，自然能理解绝大部分，并很好地追踪并查找过往的修改记录了。当然xib也不是完美的。最大的问题在于xib中的设置往往并非最终设置，在代码中你将有机会覆盖你在xib文件中进行的UI设计。在不同的地方对 同一个属性进行设置，这在之后的维护中将会是噩梦般的存在。因为其实IB还是有所局限的，它没有逻辑判断，也很难在运行时进行配置，而反之使用代码确是无 所不能的。在使用xib时，辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视，如果选择xib，那么要尽量将xib的工 作和代码的工作隔离开来：能够使用xib完成的内容就统一使用xib来做，而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽 量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。

第三种方法是storyboard，iOS5之后Apple提供了一种全新的方式来制作UI，那就是StoryBoard。简单理解来说，可以把StoryBoard看做是一组 viewController对应的xib，以及它们之间的转换方式的集合。在StoryBoard中不仅可以看到每个ViewController的布 局样式，也可以明确地知道各个ViewController之间的转换关系。相对于单个的xib，其代码需求更少，也由于集合了各个xib，使得对于界面 的理解和修改的速度也得到了更大提升。减少代码量就是减少bug量，这也是程序开发中的真理之一。 

在Xcode5之后，StoryBoard已经成为新建项目的默认配置，这也代表了Apple对开发者的建议和未来的方向。WWDC2013的各个 Sample Code中也基本都使用了StoryBoard来进行演示。可以预见到，之后Apple必定会在这方面进行继续强化，而反之纯代码或者单个xib的方式很 可能不会再得到增强。 

如果不考虑iOS版本的支持（其实说实话现在已经很少还见到要从iOS4开始支持的app了吧），现在StoryBoard面临的最大问题就是多人 协作。因为所有的UI都定义在一个文件中，因此很多开发者个人或企业的技术负责人认为StoryBoard是无法进行协作开发的，其实这更多的是一种对 StoryBoard的陌生所造成的误解。虽然Apple并没有在WWDC明确提及，但是没有人规定整个项目只能有一个StoryBoard文件。一种可 行的做法是将项目的不同部分分解成若干个StoryBoard，并安排开发人员对自己的部分进行负责。简单举例比如一个有4个tab功能相互独立的基于 UITabBarViewController的应用，完全可以使用4个StoryBoard来分别代表4个tab，并在相互无干扰的情况下完成开发。这 样一来就不会存在所谓的冲突问题了。StoryBoard的API是如此简单，现在的SDK中一共方法数量一只手就能数过来，所以具体方法在这里就不再罗嗦了。 

StoryBoard的另外的挑战来源于ViewController的重用和自定义的view的处理。对于前者，在正确封装接口以及良好设计的基 础上，其实StoryBoard的VC重用与代码的VC重用是没有本质区别的，在StoryBoard中添加封装良好需要重用的Scene即可解决。而对 于后者，因为StoryBoard中已经不允许有单个view的存在，因此很多时候我们还是需要借助于单个的xib来自定义UI。这一点可以说是由于 StoryBoard的设计思路所造成的，StoryBoard更强调的是一种层次结构，是在全局的视角上来组织UI设计和迁移。而对于单个的view， 更多的会注重于重用和定制，而与整个项目的流程没有太大关系。相信抓住这一要点，就能很好地了解什么时候使用xib，什么时候使用StoryBoard。 

关于StoryBoard最后要说的是，现在会有一些对于StoryBoard性能上的担忧。因为相对于单个xib来说，StoryBoard文件 往往更大，加载速度也相应变慢。但是其实随着现在设备的更新换代，在iPhone4都难觅的今天，这点性能上的差距几乎可以忽略了。而再之后的设备，不论 读取还是解析，只会越来越快。所以性能上的问题完全是没有担心的必要的。

是手写代码，还是XIB或者Storyboard各有各的好处和坏处。业内并没有定论。

纯手写代码的好处，一是在代码版本管理系统中不易产生冲突，有冲突也好解决。二是容易写出通用的UI组件，通过合理的设计模式进行重用。三是灵活，可以达成任何想要的效果。
坏处：对于复杂的界面，代码不管是写还是读都太费劲。尤其是现在iOS8时代，auto resize mask力不从心，UI布局使用autolayout几乎是必然的，而放弃设计工具使用纯代码调试autolayout那几乎是噩梦，光是layout constraint的那个丑得一比的字符表现形式就让人不爽。当然也有团队更极端，连autolayout也不用，用代码在layoutSubviews里面硬算，“手动”布局，这个本座认为就是纯粹吃饱撑的了。

XIB/Storyboard的好处：好用，易用。坏处：很难重用。以及容易被新手滥用。在版本管理工具里面也不容易看出到底是哪些修改。
本座绝对禁止团队把多个UIViewController放到一个Storyboard里面，一个Storyboard里面只允许一个UIViewController，跳转逻辑用代码写。原因很简单：避免冲突。如果把整个App所有的布局逻辑写到一个Storyboard里面，在多分支下版本冲突几乎是无法避免的事，而Storyboard作为一个格式不透明的巨大XML文件，一旦产生冲突，几乎是无法解决的，只能放弃一个冲突版本，在另一个版本的基础上重做一遍。在Xode5以后，苹果改进了Storyboard的格式，XML的结构在GIT中更容易无冲突地merge，但巨大化的Storyboard还是应该避免。

Storyboard如果使用得当，对于生产力的提高极有好处。别的不说，光是Storyboard可以设计静态UITableView这一点，就省了很多事。最新的Size class可以支持Storyboard在不同的设备上截然不同的布局，如果用纯代码？分分钟写死你。所以本座主张该用Storyboard就用，但不能滥用。具体操作的时候，什么逻辑可以放Storyboard里面，什么应该放代码里面，也是有技巧的，做好了事半功倍，做坏了下一个程序员接手的时候会骂你祖宗十八代。具体什么技巧这里就不展开了。

转自：知乎用户alienbat
http://www.zhihu.com/question/26425301/answer/32846756