不要担心`retainCount`？真？

Question

我被告知不要担心保留计数。我知道我不应该使用基于release的条件逻辑来retain或retainCount，但我不应该担心吗？我认为这些在某种程度上与内存使用相对应。

例如，如果我有一堆UIView的子视图我已经放入NSArray以便能够遍历它们，那么加倍保留计数，因此应用程序的内存使用情况？如果是这样，如果子视图是500 UIControl个实例，这是否代价高昂或微不足道？ 这假设我当然需要500个实例。

Answer 1

retainCount返回的值是对象保留的绝对次数。 UIView来自一个框架，其实现是不透明的。对于与之交互的文档化界面，您不应该担心实现细节。

在该实现中，UIView的实例可以作为实现的一部分保留任意次。在记忆方面，实际的保留数量毫无意义; 1与5相同。

您应该关注的唯一事情是代码如何更改对象保留计数。

如果您的代码增加了保留计数，则必须将其减少到某个位置，否则对象将永远存在。如果您retain，则必须release（或autorelease）。如果您copy，则必须release或autorelease。如果您new或alloc，则必须release（或autorelease）。

就是这样。

Answer 2

您不应该担心retainCount，因为它通常是引用计数系统的误导性实现细节。您应该关注的是遵循适当的对象所有权政策。

我在Apple的文档中偶尔发布一次：

  

重要说明：此方法在调试内存管理问题时通常没有价值。因为任何数量的框架对象可能保留了一个对象以保存对它的引用，而同时自动释放池可能在对象上保留任意数量的延迟版本，所以您不太可能从此获取有用信息方法

至于你的上一个问题，从一个数组到另一个数组添加对象，你的内存使用率不会翻倍。保留计数只是对象中的无符号整数，当某些东西声称拥有它时，它会递增1。但同样，不要担心自己。

Answer 3

  

例如，如果我有一堆UIView的子视图，我也已经将它放入NSArray中以便能够遍历它们，那么不会使保留计数加倍......

是的，它会。

  

...因此应用程序的内存使用？

没有！结论是错误的。当存储为32位整数时，1000000占用的空间与0相同。

Answer 4

他们说不用担心的原因是retainCount字段通常会产生误导。除了不知道自动释放池的最后刷新时间或自上次自动释放对象的次数以外，还有一些复杂的内部构件，系统组件可能会以无法预测的方式临时保存引用。因此，如果您开始研究retainCount，您可能会花费大量时间来弄清楚系统的其他部分正在使用各种对象，这不太可能帮助您正确使用应用程序。

您应该设计应用程序的工作方式，以便不会过多使用内存。

您应该担心内存中有多少个对象，以及保留它们的次数（这是一个小于retainCount的数字），并确保将它们释放多次保留它们。

多次调用对象上的retain仍然只会导致对象的单个副本存在于内存中。

要检查内存使用情况和/或泄漏情况，请使用仪器泄漏检测器。

Answer 5

保留计数只是一个数字。保留计数为零的对象将被取消分配;除此之外，如果它被保留一次或五十次并不重要。