【问题标题】:Don't worry about `retainCount`? Really?不要担心`retainCount`?真的吗?
【发布时间】:2010-07-28 15:50:05
【问题描述】:

有人告诉我不要担心保留计数。我知道我不应该使用基于retainCount 的条件逻辑来决定releaseretain,但我应该不用担心吗?我认为这些在某种程度上对应于内存使用情况。

例如,如果我有一堆 UIView 的子视图,我也将它们放入 NSArray 以便能够遍历它们,那么 double 保留计数,因此应用程序的内存使用?如果是这样,如果子视图是 500 个UIControl 实例,这是代价高昂还是微不足道? 这是假设我当然需要 500 个实例。

【问题讨论】:

    标签: iphone objective-c memory-management


    【解决方案1】:

    retainCount 返回的值是对象被保留的绝对次数。 UIView 来自一个实现不透明的框架。除了您与之交互的文档化接口之外,您不必担心实现细节。

    在该实现中,UIView 的实例可以作为实现的一部分保留任意次数。在内存方面,实际的retains数是没有意义的; 1 与 5 相同。

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

    如果您的代码增加了保留计数,它必须在某处减少它,否则该对象将永远存在。如果您retain,则必须release(或autorelease)。如果您copy,则必须releaseautorelease。如果您newalloc,则必须release(或autorelease)。

    就是这样。

    【讨论】:

      【解决方案2】:

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

      我偶尔会从 Apple 的文档中发布此内容:

      重要提示:此方法在调试内存管理问题时通常没有价值。因为任何数量的框架对象可能已经保留了一个对象以保存对它的引用,而同时自动释放池可能在一个对象上保存了任何数量的延迟释放,所以您不太可能从中获得有用的信息方法。

      至于您的最后一个问题,您的内存使用量不会因将对象从一个数组添加到另一个数组而增加一倍。保留计数只是对象中的一个无符号整数,当某物声称拥有它时,它会增加 1。但同样,不要担心这一点。

      【讨论】:

      • 谢谢,这对我有用。并再次感谢您没有重申正确的对象所有权政策,我牢记在心。
      【解决方案3】:

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

      是的,会的。

      ...以及应用程序的内存使用情况?

      不!结论是错误的。当存储为 32 位整数时,1000000 占用的空间与 0 一样多。

      【讨论】:

        【解决方案4】:

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

        您应该设计应用程序的工作方式,以免内存使用过多。

        您应该担心内存中有多少对象,以及您保留了多少次(这个数字将小于retainCount),并确保您释放它们的次数与您的释放次数一样多保留它们。

        对一个对象多次调用 retain 仍然只会导致该对象的一个​​副本在内存中。

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

        【讨论】:

          【解决方案5】:

          保留计数只是一个数字。保留计数为零的对象将被释放;除此之外,保留一次或五十次都没有关系。

          【讨论】:

          • 所以你是说一个对象要么被分配,要么没有,这是唯一在内存占用方面有所不同的东西?在这里推断...
          • @Yar:这正是他所说的。
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2012-07-31
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多