我是否有充分理由不使用具有高度自定义UI和广泛动画以及超低内存占用需求的XIB / NIB文件？
作为初学者，我开始使用XIB。然后我发现我无法做到其中的一切。它开始变得非常难以按我希望的方式定制东西。所以最后，我扔掉了所有的XIB，并以编程方式完成了所有工作。
所以当有人问我XIB是否合适时，我通常会说：是的，如果你想制作糟糕乏味的界面并且不太关心性能，请继续。但是还有什么可能是不使用XIB的原因？
我是唯一一位喜欢以编程方式执行所有操作的iPhone开发人员吗？
答案 0 :(得分：11)
我认为Interface Builder是Mac（以及扩展，iPhone）软件开发的最大资产之一。 GUI是可视的;为什么不使用可视化界面创建它们？ IB足够灵活，您可以使用其“通用”组件布局接口，然后在必要时将它们子类化。当然，如果你有一个独特的界面，你将不得不继承视图类并执行自定义绘图，但你也可以在IB中布局你的界面，然后轻松使用检查器将类切换到你的自定义子类。 / p>
答案 1 :(得分：4)
老实说，我认为这是一种方便。如果您愿意在代码中编写所有内容，那就去吧。如果你很好地设计你的项目，那么它应该与创建新窗口的工作量相同，但是我知道很多人对GUI世界不太熟悉，所以nib / xibs在那里工作得很好。
老实说，我经常发现自己经常使用XIB作为基础，并使用代码编辑它们以获得我想要的特定外观。个人偏好。
对于该点的特定con，在从xib加载视图后，可能难以配置视图。当您在IB和代码之间存在冲突的设置时，可能会讨厌进行故障排除。
这是列表的问题。使用xib会有什么性能影响？我认为它们是一个加号因为它们在你需要之前不会被加载到内存中。也就是说，加载时间较长会降低程序速度。想法？
答案 2 :(得分：3)
我发现代码更好的一件事是控件上的事件连接，当你搜索方法（消息）的使用时，如果它们被编码就找到它们，如果它们在IB中设置则你找不到它们。
另一方面，在IB中可以更容易地在视图上布置对象，您可以在其中查看其大小和位置。当您在代码中执行此操作时，您必须猜测大小和原点设置，然后运行它并进行调整，然后再次运行它以查看它的外观。
答案 3 :(得分：3)
当您的应用程序具有某种“标准”视图时，请使用XIB。如果您需要真正的自定义，根据外部内容（XML ...）以编程方式进行。
我开始使用XIB，现在它是所有代码，我觉得这样更舒服。我有XIB的实际问题，现在用代码编写接口真的可以节省我的时间。
答案 4 :(得分：2)
在启动阶段处理UIControllers（UITabBarControllers，UINavigationControllers等）时节省了大量时间，其中所有导航内容都被连接起来。
我只是使用附带的XIB构建X viewControllers，投入IB中所需的东西，标签，图像等。这意味着对于几乎任何类型的应用程序，您可以在几个小时内获得概念证明。这足以证明花一些时间来学习IB的来龙去脉。特别是在iPhone上你可以拥有大量优秀的UI创意，但是当它们从模拟器转移到实际设备时它们都会失败。
在我看来，最好的事情是平衡它，如果你发现自己花了很多时间做“改变帧3 px - ＆gt;编译 - ＆gt;啊......需要两个像素 - ＆gt ;改变2 px - 编译 - ＆gt;啊......再多1次px“对于可以在IB中完成的事情，你会认真地开始浪费时间。
我从上面开始，但之后我经常把XIB扔掉去自定义东西。诀窍是不要花费数小时一遍又一遍地在代码中实现自定义东西的版本，但要弄清楚它应该如何并且做一次自定义的东西：）
答案 5 :(得分：2)
nib文件的XML内容非常复杂。这使得查看更改或修复与Git等版本控制系统的合并冲突非常困难。
Interface Builder是个不错的主意，但Bret Victor在他的演讲“Inventing on Principle”和他的文章“Learnable Programming”中暗中挑战Apple建立一个更好的IDE。
一个想法，基于Bret Victor的原则：如果我可以在iOS模拟器应用程序中选择一个“移动工具”，让我在我的应用程序中移动一个按钮然后在实现中更改了框架代码（{{1} }）文件？这会好得多。