iOS不会自动清除ImageIO脏内存 [英] ImageIO dirty memory is not automatically cleared by iOS

问题描述

我正在创建一个应用程序，它是一种图库 - 它将不同的媒体内容显示为全屏查看器。分配工具显示使用应用程序时，实时字节参数不会超过40 Mb。与此同时，在我将页面滑动20-30次后，应用程序被100％杀死。
我检查了Dirty Memory参数，发现它比Live Bytes大小大10倍。
大部分脏内存消耗Image IO：

I am creating an application which is a kind of gallery - it shows different media content as a fullscreen viewer. Allocations instrument shows that Live Bytes parameter doesn't grow higher than 40 Mb when using application. Meanwhile the app is 100% being killed after I slide pages 20-30 times. I checked Dirty Memory parameter and found it was 10 times bigger than Live Bytes size. And the most of that dirty memory consumed Image IO:

截图http://i40.tinypic.com/25ge51i.jpg

编辑，另一个截图：

截图http://i40.tinypic.com/9t1mh5.png

上面的分配高峰是切换视频/图像媒体内容。
问题是脏内存几乎呈线性增长，我需要以某种方式释放它。

The allocations peaks above are switching video/image media contents. The problem is the dirty memory grows almost linearly and I need to release it somehow.

现在关于应用程序设计。
应用程序屏幕有一个水平滚动视图。滚动视图包含包含多个图像的视频或拼贴对象。为了节省内存，一次只创建三个页面 - 当前页面和左/右页面。所以当滑动滚动视图时，页面总是在运行时创建和删除。

Now about application design. Application screen has one horizontal scroll view. Scroll view contains videos or collage objects which contain multiple images. To save memory only three pages are created at a time - current page and pages on the left/right. So pages always created and removed on-fly when sliding scroll view.

我使用 [UIImage imageWithContentOfFile：path]加载的所有图像方法。
Collage对象在imagesArray中存储UIImage实例。在dealloc方法中，imagesArray属性被清除。

All the images I load using [UIImage imageWithContentOfFile: path] method. Collage object stores UIImage instances inside imagesArray. In dealloc method imagesArray attribute is cleared.

所以，问题：

• 是它是中的一种系统错误[UIImage imageWithContentOfFile？]


• 是图像IO缓存吗？


• 我可以清除它吗？

推荐答案

将此放在太大而无法发表评论，只是一些想法：

Putting this here as too big for a comment, just some ideas:

1）错误地保留对象的一种方法是让视图中的对象隐藏但不从超级视图中删除（因此保留）

1) one way to retain objects by mistake is to have objects in views that get hidden but not removed from their superview (and thus stay retained)

2）如果你在任何线程上使用UIImageView等做任何事情而不是主线程会发生坏事（比如这个）

2) if you do anything with UIImageView etc on any thread not the main thread bad things can happen (like this)

3）复制你的项目，这样你就可以自由地搞乱它，并尝试一些东西：

3) copy your project so you can freely mess with it, and try a bunch of things:

• 多个图像，总是加载相同的图像，但保留代码的其他部分 - 做的事情会改变吗？

• instead of multiple images, always load the same image, but leave the other parts of your code as they are - do things change?

在你创建的任何子类中会坚持/重新tain图像，在dealloc中放入一条日志消息，看看实际上这些对象是否被释放。

In any subclasses you create that would hold/retain images, put a log message in the dealloc to see if in fact those objects are getting dealloced.

子类UIImageView，将其用于图像，并记录dealloc

subclass UIImageView, use it for the images, and log the dealloc

子类UIImage，用于这些图像，记录dealloc

subclass UIImage, use it for these images, log the dealloc

4）我很难相信imageio有一个可以做到这一点的缺陷，但你可以做的是切换到使用imageWithData，并自己加载数据。当你真正读取数据时使用F_NOCACHE标志 - 在SO上有关于如何执行此操作的其他代码，你可以搜索它（我回答了一个问题）。

4) I am having a hard time believing imageio has a defect that would do this, but what you could do is switch to using imageWithData, and load the data yourself. Use the F_NOCACHE flag when you actually read the data - there is other code on SO on how to do this, you can search on it (I answered a question on it).

如果你可以用这个缺陷创建一个演示项目，那么调试它会比猜测做什么容易得多。记录获得dealloc的类会有很长的路要走，因为你会立即看到未发布的内容，然后更好地关注问题。

If you can create a demo project with this defect, it would be a lot easier to debug it than just guess at what to do. Logging the class that gets dealloc'd goes a long way, since you will see immediately what is not getting released, and then better focus in on the problem.

这篇关于iOS不会自动清除ImageIO脏内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！