关于Interface Builder的一点思考

Xcode6提供的Interface Builder，为iOS界面建立提供了许多方便。可是，任何事物都存在两面性，这里对IB提出了几点思考。

 

一个Storyboard只对应一个UIViewController

 

这样的好处是显而易见的，权责分明，Storyboard负责界面的绘制，而UIViewController负责逻辑的整理。然而，这也说明了一个Storyboard没法对应多个UIViewController。这意味着若是两个界面基本类似，若是仍是采用Storyboard的方式，则还得绘制两套基本类似的界面，对应的控件若是有类似的逻辑则得所有从新操做一遍。

 

简单的解决方法是把相同的部分以XIB文件的方式绘制为UIView，再在UIViewController中将UIView手动添加进去。虽然这样作仍是违背了Storyboard的初衷，但也只能这样作了。

 

除此以外，Storyboard只能对应一个UIViewController也意味着这个Controller没法在被继承的同时携带Storyboard，就算你想利用父类的逻辑进行新的扩展优化也是无能为力的。

 

布局约束的使用场景

 

布局约束对于界面设计来讲可谓节约了很多工做。不用特别关心某个控件的具体尺寸，而只关心它以怎样的方式存在于界面中，和其余控件之间的位置关系如何。

 

以最原始的方式使用布局约束，即是手动敲代码，但Objective-C在这方面可谓极度欠缺便捷性。几个简单的约束逻辑都须要敲上好几十行代码。好在有其余第三方库封装了这些逻辑并以极简的方式提供给开发者使用。IB中固然也提供了约束的设置，而且在设置、查看、重置界面这几个方面来讲都寄予了开发者极大的方便。

 

虽然IB把开发者从繁杂的代码中解放出来，但并不意味着能在各个方面都如此。在维护方面，IB上的约束显然没有那么便捷。试想一下你接手了一个模块，某个Storyboard里的界面处处都是约束，你会做何感想？若是要在此基础上添加或删除控件，很容易又把界面弄得一团糟。

 

解决方法显然是不要用太复杂的约束，道理和写代码同样。若是界面复杂，说明界面也须要重构，把整个Storyboard里的界面按功能切分，整理为不一样的XIB文件。这样的代码对于别人来讲，噩梦或许会少一点。