每次运行该方法时，都会有大约 1MB 的巨大堆增长。几次通话后应用崩溃。发现每次运行一种更新数据和 UI 的方法时都会出现堆增长。
这是我在 Inspector 中看到的内容:
每次运行该方法时，都会有大约 1MB 的巨大堆增长。几次通话后应用崩溃。
通过调用堆栈向下找到这个静态函数:
在代码中找不到任何内存泄漏。请帮忙。 (ARC 开启)
更新:
所以现在我在该静态方法中使用了一个 NSCalendar 对象，它帮助了一些，但每次运行该方法时仍然有 1MB 以上。
现在 Inspector 显示了许多与代码无关的内存地址。
你不需要创建这么多 NSCalendars - 如果你重复使用 autoupdatingCurrentCalendar(例如，将它保存到 GraphController ivar)并且将其传递给 -dateDifferenceFromDate:to:，您可以(实际上)消除日历创建。
更新
Can this help with abandoned memory or it's only improves speed?
了解此建议有多大帮助的最佳方法是衡量。您的屏幕截图表明 ICU 时区(由日历使用)创建是最重的部分。 IDK 在绘制图形时您调用了多少次(即您创建了多少 NSCalendars，或者实现是否通过此 API 共享/缓存信息)……但是您提供的信息让我相信它是'many' - 每次调用 -dateDifferenceFromDate:to: 一个日历。
所以是的，它可以消除(不必要的)重复对象——[NSCalendar currentCalendar] 不会返回单例(您的示例证明了这一点)。
还要注意 NSDateComponents 可能会引用日历实例。
创建日历可能非常耗时(不仅仅是内存)。
另请注意，NSCalendar 不是线程安全的。
因此，您的程序可能会不必要地创建大量临时变量。大多数(如果不是全部)内存将“很快”释放，但如果您有很多“计算”，那么您的自动释放池中可能会有大量存款(最终会被耗尽)。您可以创建内部自动释放池来减少这种情况，但使用一个日历可以轻松优化速度和内存。
许多系统 API 会在后台缓存并导致惊人的内存增长，但 IDK 如果这是其中之一。
这篇博文可能也很有趣:http://www.mikeabdullah.net/NSCalendar_currentCalendar.html
但实际上，我只是尝试使用一个自动更新日历，然后进行测量。然后你就会知道它对你的实现有多大帮助。
关于ios - 启用 ARC 的堆增长，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17751399/
| 欢迎光临 OStack程序员社区-中国程序员成长平台 (https://ostack.cn/) | Powered by Discuz! X3.4 |