以编程方式创建视图与 IB 相比的效率

Posted

技术标签:

【中文标题】以编程方式创建视图与 IB 相比的效率【英文标题】:Efficiency of create views programmatically vs IB 【发布时间】:2009-05-26 17:22:09 【问题描述】:

我有大量在应用程序委托 applicationDidFinishLaunching 中创建并添加到 NSMutableArray 的 UIView。用户使用页面控件和滚动视图浏览这些视图。我在 IB 中创建了 UIView 及其子组件。它们连接到控制器。在 iPhone 上创建 170 个视图大约需要 30 秒。最终,我的浏览量将超过 1000 次。除了速度慢之外,它还会因为内存使用而杀死应用程序。在没有视图的情况下以编程方式创建所有内容的速度和内存效率有多高? 6000 个事实类型的应用程序中的某些应用程序是如何做到的?

有没有更好的方法而不是一次创建所有内容?用户可以访问插槽#400 中的视图并从那里开始滚动。任何建议表示赞赏。

【问题讨论】:

为什么需要这么多视图?它们都是独一无二的吗?如果没有,你为什么不重用它们?它们真的都需要在内存中吗? 请查看 6000 Awesome Facts 应用程序了解原因。谢谢。 【参考方案1】:

UIViewControllers 是懒惰的。它们仅在请求时加载,并在内存紧张时自动卸载(通过调用 self.view=nil 手动卸载它们很容易)。

此处的“加载”表示“读取 NIB”或“以编程方式构建”。 ViewControllers 并不真正关心。以编程方式构建可能会更快一些,因为您不必敲击磁盘,但这很少是瓶颈,因为您一次只显示一个视图控制器。

至于走哪条路,风格比性能更重要(UITableViewCells 除外,在大多数情况下您需要以编程方式构建它是有原因的)。

从研究View Controller Programming Guide开始。它会向你展示 iPhone 打算如何做到这一点。

对于 eJames 关于 NIB 是 XML 文件的评论,这可能有点误导。 NIB 是通过编译 XML 的 XIB 文件生成的二进制文件。在假设NIB加载时间实际上是一个问题之前,我实际上会在手机上进行分析。尽管我天生倾向于程序化布局,但我在实践中发现 NIB 在实践中极大地简化了许多 UI 问题,并且我总是在大型项目中使用它们。

【讨论】:

哇,我不知道这些信息是否正确,但如果是这样的话……肯定会提供信息。【参考方案2】:

在不了解您的具体问题的情况下很难提出答案,但我敢说,如果您希望显示 1000 种不同的东西,那么在 IB 中创建 1000 个单独的视图不是可行的方法。

如果你的页面共享一个共同的布局,你可以使用 UITableView 来显示每个页面的内容,并且在你的NSMutableArray 中只存储每个页面的数据

关于如何使用UITableView 的优秀教程可以在here 找到。

如果他们不共享一个共同的布局,那么以编程方式布局将是可行的方法。这不应该比使用 IB 占用更多的内存或处理器,实际上它可能会更快,因为它消除了读取和解析 XML 文件的需要(实际上是 .NIB 文件)。

【讨论】:

以上是关于以编程方式创建视图与 IB 相比的效率的主要内容,如果未能解决你的问题,请参考以下文章

从 IB 加载视图

Swift:以编程方式添加视图时,UIScrollView 的可滚动内容大小不明确,而不使用 IB

iOS:使用 IB 为以编程方式创建的 UITableView 创建自定义单元格

以编程方式创建 UINavigationController

以编程方式使用堆栈视图

iOS:以编程方式更改从 Interface Builder 设置的约束