iPad iOS 内存管理 - 如何释放 UIImageViews、UIScrollViews 使用的“Real Memory”？答案

【问题标题】：iPad iOS memory management - how to free up "Real Memory" used by UIImageViews, UIScrollViews?iPad iOS 内存管理 - 如何释放 UIImageViews、UIScrollViews 使用的“Real Memory”？
【发布时间】：2013-03-24 04:19:58
【问题描述】：

我的一个应用程序出现内存问题，我已将 Instruments> 活动监视器中定义的“真实内存”确定为可能的罪魁祸首。

我的应用在 UIScrollViews 中分配较大的 UIImages。有一个 CIImageFilter 应用于其中一个图像。活动监视器显示，在第一次推送包含带有大图像的滚动视图的视图控制器时，实际内存使用量跃升至约 300mb。 随后的推送/弹出将其提高到约 500mb：

我读到“Live Bytes”不计算纹理和 CALayers 使用的内存，所以我的问题是：如何正确释放我的 Image/Scrollviews 的 CALayers 使用的内存？

看右边的真实内存使用蓝色饼图：

这个进程的真实内存和虚拟内存都是最高的：

困扰我的是，当弹出该控制器时，我试图清理我的大型滚动视图和图像，“实时字节”的数字下降到大约 5mb，而“真实内存”保持高得离谱（~ 500 mb）：

ContainerScrollView* container = ...;
[container.view removeFromSuperview];
container.view = nil;

这是分配分析：

【问题讨论】：

在您的测试中，每次您实例化一个新的滚动视图时，您是否实例化了相同的图像？
您是否尝试过触发内存警告以确保任何系统缓存都响应并（希望）删除任何未使用的数据？记住 imageNamed 使用缓存。
内存警告被触发。滚动视图从用户选择的照片库中接收图像。
您是否在检查“活动字节”？根据stackoverflow.com/questions/8795000/…，“真实内存”包括进程已使用和已停止使用但尚未重用的所有内存。所以它是进程当前在 RAM 中拥有的窗口，而不是它必须使用的窗口。
在每次弹出控制器后，我的实时字节数都会显着下降，在它成为严重的“废弃内存”问题之前，现在已经不那么严重了。尽管如此，每次推送实际内存会增加 120 mb，每次弹出可能会下降 30 mb，因此在 5 次推送/弹出后，我使用了大约 560 mb 的实际内存，应用程序崩溃了。

标签： objective-c ipad memory-management ios6 calayer

【解决方案1】：

我在这里发现有人遇到类似问题：

Mysterious CoreImage memory leak using ARC

答案（我真的希望如此）似乎开始使用NSData dataWithContentsOfFile:，然后创建一个UIImage imageWithData:。有用户选择的图像吗？将其写入临时文件并读回。我不信任任何其他图像方法，因为在我 12 小时的测试中，它们在 iOS 6.1.2 中对于大图像视图的行为似乎不合理。

【讨论】：

因自己的功课做得如此出色而受到支持。另请参阅我的答案：stackoverflow.com/a/15694549/341994 以及它后面的 cmets。 ImageIO 框架为您提供了许多非常有用的选项，并避免了 UIImage imageNamed 的隐式缓存，这是造成如此多内存问题的核心。