14

为什么我不应该使用具有高度自定义 UI 和大量动画以及超低内存占用需求的 XIB / NIB 文件有什么好的理由？

作为初学者，我从 XIB 开始。然后我发现我不能只做他们的所有事情。以我希望的方式定制事物开始变得非常困难。所以最后，我把所有的 XIB 都扔掉了，并以编程方式完成了这一切。

所以当有人问我XIB好不好的时候，我一般会说：是的，如果你想制作蹩脚无聊的界面并且不太关心性能，那就去吧。但是还有什么理由不使用 XIB 呢？

因为这个原因，我是唯一一个喜欢以编程方式做所有事情的 iPhone 开发者吗？

4

6 回答 6

12

我认为 Interface Builder 是 Mac（以及 iPhone）软件开发的最大资产之一。GUI 是可视的；为什么不使用可视界面创建它们？IB 足够灵活，您可以使用其“通用”组件来布局接口，然后在必要时对它们进行子类化。当然，如果您有一个独特的界面，您将不得不继承一个视图类并执行自定义绘图，但您也可以在 IB 中布置您的界面，然后轻松使用检查器将类切换到您的自定义子类。

于 2010-05-04T22:15:09.140 回答
4

老实说，我认为这是一种方便的范围。如果您愿意用代码编写所有内容，那就去吧。如果你的项目设计得很好，那么创建新窗口等的工作量应该差不多。但我知道很多人对 GUI 世界不太满意，所以 nib/xibs 在那里工作得很好。

老实说，我发现自己经常使用 XIB 作为基础，并使用代码对其进行编辑以获得我想要的特定外观。个人喜好。

对于这一点的特定问题，从 xib 加载视图后可能难以配置视图。当您在 IB 和代码之间有冲突的设置时，可能很难排除故障。

这是列表的问题。使用 xib 对性能有何影响？我认为它们是一个加分项，因为在您需要它们之前它们不会被加载到内存中。也就是说，加载时间更长，这会减慢您的程序速度。想法？

于 2010-05-04T22:03:28.650 回答
3

当您的应用程序具有某种“标准”视图时，请使用 XIB。如果您需要真正的定制，请根据外部内容（XML ...）以编程方式进行。

我开始使用 XIB，现在都是代码，我发现自己这样更舒服。我在使用 XIB 时遇到了真正的问题，现在用代码编写接口真的节省了我的时间。

于 2011-09-08T15:45:53.620 回答
3

我发现关于代码更好的一件事是控件上的事件连接，当您搜索方法（消息）的使用时，如果它们是编码的，您会找到它们，如果它们是在 IB 中设置的，则找不到它们。

另一方面，在 IB 中在视图上布置对象要容易得多，您可以在其中看到它们的大小和位置。当您在代码中执行此操作时，您必须猜测大小和原点设置，然后运行它并进行调整，然后再次运行它以查看它的外观。

于 2010-05-04T23:08:24.737 回答
2

在连接所有导航内容的启动阶段处理 UIControllers（UITabBarControllers、UINavigationControllers 等）时，我节省了大量时间。

我只是用附带的 XIB 构建 X viewControllers，加入 IB、标签、图像等所需的东西。这意味着对于几乎任何类型的应用程序，您都可以在几个小时内完成概念验证。这足以证明花一些时间学习 IB 的来龙去脉是合理的。尤其是在 iPhone 上，你可以有很多好的 UI 创意，但是当它们从模拟器转移到实际设备时，它们都失败了。

在我看来，最好的办法是平衡它，如果你发现自己花了很多时间做“改变帧 3 px -> 编译 -> 啊.. 需要多两个像素 -> 改变 2 px - 编译-> 啊.. 1 px" 对于可以在 IB 中完成的事情，您将开始严重浪费时间。

我从上面开始，但之后我经常将 XIB 扔掉以获取定制的东西。诀窍是不要花几个小时在代码中一遍又一遍地实现自定义内容的版本，而是弄清楚它应该如何并做一次自定义内容:)

于 2010-06-11T10:08:22.233 回答
2

nib 文件的 XML 内容非常复杂。这使得使用 Git 等版本控制系统审查更改或修复合并冲突变得极其困难。

Interface Builder 是一个好主意，但Bret Victor在他的演讲“ Inventing on Principle ”和他的文章“ Learnable Programming ”中含蓄地挑战 Apple 构建一个更好的 IDE。

一个想法，基于 Bret Victor 的原则：如果我可以在 iOS 模拟器应用程序中选择一个“移动工具”，让我在我的应用程序中移动一个按钮，然后在实现 ( .m) 文件中更改框架代码，该怎么办？这样会好很多。

于 2012-11-23T02:26:18.907 回答