【发布时间】：2010-11-26 03:48:35
【问题描述】：
我想知道使用 .xib 文件进行 GUI 设计和以编程方式执行此操作之间是否有区别。
因为它是一个编译器，我会假设没有相关的时间损失。
我错了吗？
【问题讨论】：
标签： iphone objective-c performance nib xib
【发布时间】：2010-11-26 03:48:35
【问题描述】：
很少。有一些例外。例如，如果您使用 xib 加载进入 UITableViewCell 的图像，那么这可能是一个问题，因为具有许多单元格的 UITableViews 对加载时间很敏感。但是，出于所有意图和目的，应该不会对性能造成明显影响。
xib 中的信息确实必须在运行时解码并加载到内存中，这不如直接以编程方式创建 UI 元素那么快。
【讨论】：
-
如果您也像预期的那样重用单元格，则创建的单元格数量只会与屏幕上显示的一样多，因此开销不会太大（您可以在 IB 中设置重用标识符）。
-
没错，为 UITableViewCell 使用 xib 只会影响它的创建，并且只影响可见单元格的数量，而不是所有单元格（除非你做错了什么）。
提防过早的优化，尤其是当它涉及编写比您需要的大量代码时。
【讨论】：
-
没错，但是当谈到 iPhone 及其有限的资源时，我通常认为疯狂的优化可以产生实际的影响。 Wil Shipley 对此有一些有趣的 cmets：vimeo.com/4421498
（注意：在我的手机上敲出这个，所以对于任何奇怪的格式或语法，我提前道歉 - 如果有问题，我会在我回到笔记本电脑时修复它们。）
我已经做了一些快速、肮脏和非常非正式的测试来亲自检查一下，这就是我发现的（请注意，我为测试构建的应用程序只是草稿，不一定代表“真实”应用程序）：
当初始屏幕是笔尖时，启动时间会更快
对于所有后续屏幕，手动编码 UI 时性能提高
一开始很奇怪，但仔细想想，也许并没有真的那么奇怪。
启动问题让我感到困惑，但我认为这是因为 Apple，作为 Apple 并且痴迷于启动时间（当然，以一种好的方式），只是以这种方式优化了手机的 unarchiver从存档（nib）加载可以比手动编码更快。
也就是说，大多数人编写的应用程序不会受到任何差异的显着影响。我的（又一次：又快又脏）测试表明，从冷启动（你还没有运行应用程序或有一段时间），基于 nib 的应用程序始终加载其初始屏幕的速度大约是手动编码的两倍版本。虽然这听起来很重要，但我们说的只是几毫秒。这种差异对用户来说是察觉不到的。对于热启动（您已经打开和关闭应用），启动时间的差异要小得多。
出于这个原因，我喜欢使用 nib 来布置应用程序的基础：任何顶级导航（选项卡控制器、导航控制器等），然后手动编写 UI 的其余部分。
另外，由于 iPhone 用户界面是如此特定于 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。我们为这些（和其他）应用程序构建了一个框架，平滑表格滚动的秘诀在于我们从未使用过从 nib 加载的单元格（它比这更复杂，但跳过 nib 是获得性能的第一步）会在这些应用中看到）。
一般来说，使用 nib 时要考虑的最重要的事情可能是您需要将 UI 分解为多个文件。也就是说，不要将应用的整个 UI 粘贴到一个 nib 中。当一个笔尖被加载时，它就是整个事情 - 笔尖中可能有一个视图，你的用户很少会看到，如果有的话，那些像其他所有东西一样被加载，吸收资源没有理由。如果您不为每个应用的屏幕使用单独的 nib，则很容易遇到内存和性能问题。
进一步澄清：如果您的应用程序有五个视图控制器，请将每个控制器固定在自己的 nib 中。在需要之前，您不想加载任何内容。这也有例外，但这就是编码的方式 - 如果有足够的时间，你会找到一个理由去做“错误的方式”，但每个屏幕的一个笔尖方法是你应该的方式除非你有充分的理由不这样做。
我会把它留在那里 - 我希望它会有所帮助。
记住：
我的非正式闲逛表明 启动 使用 nib 更快（只要您保持 nib 尽可能简单，只保留您需要的东西在里面）。
启动后，手动编码 UI 的性能似乎有所提高。
如果操作正确，并且您没有编写游戏或其他内容，笔尖不会导致明显的性能问题。
根据我的经验，桌子是不同的——它们是我很少使用笔尖的地方。
如果您使用 NSCoding 来保持应用程序状态，则 nib 可能会出现问题，并且任何变通方法都可能不值得付出努力，因为手动编写 iPhone UI 相对容易。
让你的笔尖尽可能简单——我说的还不够。尽可能为应用的每个屏幕创建一个 nib，而不是将整个应用的 UI 塞进一个 nib。
好的。这次真的停了。
希望这会有所帮助:)
【讨论】：