ARC 导致 UIDatePicker 内存泄漏

发布于 2024-12-29 06:24:59 字数 517 浏览 4 评论 0原文

我正在制作一个应用程序,它有一些带有 UIDatePicker 控件的视图控制器。

在出现大量内存警告后,我对原因进行了大量调试。使用仪器,我可以看到每当包含 UIDatePicker 的视图控制器出现时,内存使用量就会增加 2-3mb。最终,这会导致内存警告。虽然我可以在这里做很多事情,并且自从重写这些函数以来崩溃次数急剧减少,但我仍然对这种行为感到不满意并希望修复它。

UIDatePicker 是 XIB 文件的一部分。我尝试将它们从 XIB 中取出并以编程方式添加它们。这并不能解决问题。我还尝试过使用(线程安全的)单例。这将内存使用量限制为只有一个实例(因此内存使用量不会增加),但我试图尽可能避免单例。我应该接受它并使用单例吗?

我在运行它的所有设备上都看到了这种行为,正如标题所示,

这是 Instruments Each 的屏幕截图 增加使用量是 开头的内存使用量为 2.3mb。

当包含日期选择器的 VC 出现时,图表 ://i.sstatic.net/1S7ns.png

干杯!

I'm making an app that has a few view controllers with UIDatePicker controls.

After having lots of memory warnings, I've done a lot of debugging on the cause. Using instruments, I was able to see that whenever a view controller containing a UIDatePicker appeared, memory usage was going up by 2-3mb. Ultimately, this leads to a memory warning. While I can do so much in here, and have seen a dramatic decrease in crashes since re-writing these functions, I'm still not comfortable with this behaviour and want to fix it.

The UIDatePicker's are part of the XIB file. I've tried taking them out of the XIB and programmatically adding them. This doesn't solve the problem. I've also tried using a (thread-safe" singleton. This limits memory usage to only one instance (so memory usage doesn't increase), but I'm trying to avoid singletons wherever possible. Should I just suck it up and use a singleton?

I'm seeing this behaviour on iOS 5 and 4.3, across all devices that run it. I'm using ARC, as the title suggests.

Instruments does not show any memory leaks.

Here is a screenshot from Instruments. Each step up in usage is when a VC containing a date picker appears. The baseline at the start of the graph is 2.3mb of memory usage.

https://i.sstatic.net/1S7ns.png

Cheers!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

猫卆 2025-01-05 06:24:59

您要在此处使用的工具称为 堆快照。它将帮助您缩小错误握住物体的类型范围。正如 @sudo 指出的,问题可能出在您的委托中,而不是日期选择器本身。从最严格的意义上来说,您可能没有“泄漏”。您可能只是保留了无意的内存(这看起来很像泄漏)。

您应该仔细查看是否有任何循环强引用。例如,您是否有对其委托具有强引用的对象?这通常会导致保留循环(在 ARC 下永远不会被释放)。 Heapshot 可以帮助您找到这些对象。

The tool you want to use here is called heapshot. It will help you narrow down the types of objects that are being incorrectly held onto. As @sudo notes, the problem is probably in your delegate rather than the date picker itself. You're probably not "leaking" in the strictest sense of the term. You're probably just holding onto memory that you didn't mean to (which looks a lot like a leak).

You should take a careful look at whether you have any circular strong references. Do you have objects that have a strong reference to their delegate for instance? That will typically lead to a retain loop (which will never be released under ARC). Heapshot can help you find these objects.

孤者何惧 2025-01-05 06:24:59

我似乎已经解决了我自己的问题。因为这是一个 inputView,而且我还有一个带有“完成”按钮的 UIToolbar 作为 inputAccessoryView。

所以现在我在 viewWillAppear 中以编程方式创建这些。在 viewWillDisappear 中,我将 UITextField 的 inputView 和 inputAccessoryView 设置为 nil,并将日期选择器和日期选择器工具栏设置为 nil。

它们不再位于 XIB 文件中。这似乎工作得非常好 - 内存猛增 3mb,然后在视图消失时又回落。现在,该应用程序始终以低于 10mb 的实时内存运行 - 有时会飙升至 15mb,但很少见。

感谢您的帮助 sudo rm -rf 和 Rob - heapshot 分析帮助我们尝试找出问题的根源。

I seem to have solved my own question. As this was an inputView, and I also had a UIToolbar with a "Done" button as the inputAccessoryView.

So now I create these programatically in viewWillAppear. In viewWillDisappear, I set the UITextField's inputView and inputAccessoryView to nil, and the date picker and date picker toolbar to nil.

They are no longer in the XIB file.This seems to work really well - memory spikes up by 3mb, then goes back down the second the views disappear. Now the app is running consistently at under 10mb of live memory - it spikes up to 15mb on occasion but very rarely.

Thanks for the help sudo rm -rf and Rob - heapshot analysis helped to try and get to the bottom of it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文