使用 Interface Builder 设计视图时是否有任何性能、开发缺点或优点?
6 回答
通常你想使用 Interface Builder;您希望通过编程接口执行此操作的原因有几个:
- 它是创建用户界面的更被接受的方式,因为它的简单性和视觉优势是您无法通过简单地使用代码轻松实现的。
- 它通过使用 Apple 鼓励开发人员遵循的标记等来帮助您的应用程序符合iPhone 人机界面指南,以保持 iPhone 应用程序的一致性和可用性。
尽管如此,编程接口有时比使用 Interface Builder 更有利的主要原因是需要多次创建的接口元素 - 例如,创建n
UIImageView
s - 基于无法在 Interface Builder 中复制的变量。编程接口允许这种灵活性,并且在这种情况下通常更有效。
请注意,NIB/XIB 也会占用内存,如果所有接口都放在主 NIB 文件中,它不仅会增加应用程序的内存使用量(对于可能不会立即需要的资源),而且会增加加载时间。话虽这么说,但是这个问题的正常解决方法不是使用编程接口,而是将不同组的接口元素放在不同的 NIB 文件中,将立即需要的接口放在主 NIB 文件中,该文件在应用程序启动时加载,以及在需要时加载的其他 NIB 文件中的其他界面元素组。
简而言之,一般的方法是使用 Interface Builder,除非您需要创建数量可变且在 Interface Builder 中无法轻松处理的元素。
一个缺点是很容易错过连接插座或动作,并且排除故障可能会很痛苦。两个积极的方面是 UI 元素的定位、对齐和锚定要容易得多,而且当手机旋转时元素会重新绘制自己(这是一个动画过程,否则您需要使用编程元素自己处理)。
就我自己而言,当我尝试学习如何为 iPhone 开发时,我发现界面构建器非常迟钝。您应该使用的工作流程对我来说仍然没有多大意义。对于挑剔的界面布局,界面构建器比手动编码更快。
在您的 UIViewControllers 中以编程方式生成 GUI 的缺点是您模糊了 MVC 模式中视图和控制器之间的区别。如果您可以将 GUI 生成保留给 loadView 方法,您仍然可以在生成信息的代码和显示信息的代码之间保持适当的界限。
简而言之:我更喜欢通过覆盖 UIViewController 子类中的 loadView 来生成 GUI。
为什么没有人提到翻译。我们有一个在 11 个语言环境中的项目 - 这将提供多个 nib*(#locales) - 这是不可接受的(对于 10 个 UI 的项目,超过 100 个 nib)。
从我到现在所见,使用 XIB 生成视图非常容易。但由于我很久没有在 iPhone 上进行开发了,我只能将你引向这篇文章,它展示了一个示例 XIB 转换为 Objective-C 代码。
http://arstechnica.com/apple/guides/2009/04/iphone-dev-convert-xib-files-to-objective-c.ars
界面生成器随时可用!:)
我确信直接对视图进行编码不会带来显着的性能提升。
切勿使用该工具查看 NIB 的代码生成。但是看看苹果的笔记。
注意:虽然您可以在不使用 nib 文件的情况下创建 Objective-C 应用程序,但这样做非常罕见且不推荐。根据您的应用程序,避免使用 nib 文件可能涉及覆盖大量框架行为以实现与使用 nib 文件相同的结果。