12

我想知道使用 .xib 文件进行 GUI 设计和以编程方式执行此操作之间是否有区别。

由于它是一个编译器，我会假设没有相关的时间损失。

我错了吗？

4

3 回答 3

26

（注意：在我的手机上点击它，所以我提前为任何奇怪的格式或语法道歉 - 如果有问题，我会在我回到笔记本电脑时修复它们。）

我已经做了一些快速、肮脏和非常非正式的测试来亲自检查一下，这就是我发现的（请注意，我为测试构建的应用程序只是草稿，不一定代表“真实”应用程序）：

  • 当初始屏幕是笔尖时，启动时间更快

  • 对于所有后续屏幕，手动编码 UI 时性能提高

一开始这很奇怪，但当你仔细想想，也许它真的不是那么奇怪。

启动问题让我感到困惑，但我认为这是因为 Apple 作为 Apple 并且痴迷于启动时间（当然，这是一种很好的方式），只是优化了手机的 unarchiver，以便可以从存档（nib ）加载比手工编码更快。

也就是说，大多数人编写的应用程序不会受到任何差异的显着影响。我的（又一次：又快又脏）测试表明，从冷启动（你还没有运行应用程序或有一段时间），基于 nib 的应用程序始终加载其初始屏幕的速度大约是手动编码的两倍版本。虽然这听起来很重要，但我们说的只是几毫秒。这种差异对用户来说是察觉不到的。对于热启动（您已经打开和关闭了应用程序），启动时间的差异要小得多。

出于这个原因，我喜欢使用 nib 来布置应用程序的基础：任何顶级导航（选项卡控制器、导航控制器等），然后手动编写 UI 的其余部分。

另外，因为 iPhone UI 是专门针对 iPhone 的（惊喜！），所以手动编写 UI 并不像编写桌面应用程序那样困难。你一遍又一遍地使用相同的 UI 组件——一旦你把它弄下来，在代码中创建一个 UI 就很容易了。您没有 80 亿个小部件可供选择，就像开发 Windows/OS X/任何应用程序一样。iPhone 的一致性使它成为我多年来开发的最简单的平台，当涉及到手动编码 UI 时。

我还发现，当我手动编写 UI 时，NSCoding（这是我用于在应用程序运行中保持状态的东西）更容易使用。由于 UIImage 实例，我遇到了基于 nib 的屏幕无法正确存档的问题。UIImage（至少我最后一次检查）不符合 NSCoding，因此存档过程终止（这是一个相当不愉快的死亡）。我在这里使用 UIImage 作为示例，但是存档器尝试存储的任何不符合 NSCoding 的内容都会破坏该过程，因此需要考虑一下。

另一次我总是手动编写 UI 代码是每当我使用动态表时。如果我正在创建一个静态表——其单元格基本上永远不会改变——笔尖很好。对于任何其他类型的表格，尤其是那些具有缩略图和其他资源密集型位的表格，我在手动编码时获得的控制可以让您获得使用基于 nib 的表格单元格无法获得的性能. 为此，你做必须跳过 CocoaTouch 并直接使用 CoreGraphics，但是您可以做出的性能改进值得您编写的每一行代码。有关我参与过的项目的表性能示例，请参阅 Barnes and Noble Store（不是电子书阅读器）和 Style.com。我们为这些（和其他）应用程序构建了一个框架，平滑表格滚动的秘诀在于我们从未使用过从 ni​​b 加载的单元格（它比这更复杂，但跳过 nib 是获得性能的第一步）会在这些应用程序中看到）。

一般来说，使用 nib 时要考虑的最重要的事情可能是您需要跨文件分解 UI。也就是说，不要将应用程序的整个 UI 粘贴到一个 nib 中。当一个笔尖被加载时，这就是全部- 笔尖中可能有一个视图，您的用户很少会看到，如果有的话，这些视图会像其他所有内容一样被加载，无缘无故地占用资源。如果您不为每个应用程序的屏幕使用单独的 nib，则很容易遇到内存和性能问题。

进一步澄清：如果您的应用程序有五个视图控制器，请将每个控制器放在自己的 nib 中。在需要之前，您不想加载任何内容。这也有例外，但这就是编码的方式 - 如果有足够的时间，你会找到一个理由去做“错误的方式”，但每个屏幕的一个笔尖方法是你应该的方式除非你有充分的理由不这样做。

我会把它留在那里 - 我希望它有一点帮助。

只记得：

  • 我的非正式讨论表明，使用 nib启动速度更快（只要你保持 nib 尽可能简单，只保留你需要的东西）。

  • 启动后，手动编码的 UI 的性能似乎有所提高。

  • 如果做得正确，并且如果您不是在编写游戏或其他东西，笔尖不应导致明显的性能问题。

  • 根据我的经验，桌子是不同的——它们是我很少使用笔尖的地方。

  • 如果您使用 NSCoding 来保持应用程序状态，则 nib 可能会出现问题，并且任何变通方法都可能不值得付出努力，因为手动编写 iPhone UI 相对容易。

  • 让你的笔尖尽可能简单——我说的还不够。尽可能为应用程序的每个屏幕创建一个 nib，而不是将整个应用程序的 UI 填充到一个 nib 中。

好的。这次真的停了。

希望这可以帮助 ：）

于 2009-12-29T23:00:37.793 回答
16

很少。有一些例外。例如，如果您使用 xib 加载进入 UITableViewCell 的图像，那么这可能是一个问题，因为具有许多单元格的 UITableViews 对加载时间很敏感。但是，出于所有意图和目的，不应该有明显的性能损失。

xib 中的信息确实必须在运行时解码并加载到内存中，这不如直接以编程方式创建 UI 元素那么快。

于 2009-09-07T07:54:29.527 回答
7

提防过早的优化，尤其是当它涉及编写比您需要的更多的代码时。

于 2009-09-07T08:20:18.710 回答