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