关于内存消耗：为什么选择静态let over（计算）静态var？

Question

我的项目已经增长，我的扩展程序也使用实用程序方法来访问某些类型。我有UINib的扩展名，例如，如下所示：

extension UINib {
  static let collectionViewCellNib1: UINib = UINib(nibName: "collectionViewCellNib1", bundle: Bundle.main)
  static let collectionViewCellNib2: UINib = UINib(nibName: "collectionViewCellNib2", bundle: Bundle.main)
  static let collectionViewCellNib3: UINib = UINib(nibName: "collectionViewCellNib3", bundle: Bundle.main)
  // etc.
}  

现在关于内存消耗：如果我理解正确，那么当我访问任何一个类型属性时，它不会被垃圾回收。只要我的应用程序存在/没有被终止，它就会留在内存中。

如果我将上面的代码重构为：

，我的应用程序是否会在内存消耗方面受益

extension UINib {
  static var collectionViewCellNib1: UINib {
     return UINib(nibName: "collectionViewCellNib1", bundle: Bundle.main)
  }

  static var collectionViewCellNib2: UINib {
     return UINib(nibName: "collectionViewCellNib2", bundle: Bundle.main)
  }

  static var collectionViewCellNib3: UINib {
     return UINib(nibName: "collectionViewCellNib3", bundle: Bundle.main)
  }
  // etc.
}

由于我的UINib实例现在绑定到一个视图，该视图具有它自己的生命周期，因此当视图被销毁/删除时，将释放连接到此生命周期的所有对象。

为什么我应该选择常量类型属性而不是计算类型属性，如果后者更适合内存消耗？

Answer 1

带有计算属性的第二个示例（可能）会在每次获取属性时为您提供一个新的UINib。完成它们后，将回收每个存储器的内存是正确的，但这可能会通过让多个UINib对象同时代表同一个NIB来抵消。

另一个问题是，就CPU周期和IO而言，构建UINib是一项昂贵的操作（您必须读取磁盘上的文件并根据其中的内容创建对象）。这可能会抵消较小内存占用的优势。