6

I'm having memory issues with one of my apps and I've identified "Real memory" as defined in Instruments> Activity monitor as a possible culprit.

My app allocates large UIImages within UIScrollViews. There's a CIImageFilter applied to one of the images. Activity monitor shows that upon the first pushing of the view controller containing scrollviews with large images, the real memory use jumps to around 300mb. Subsequent pushes/pops raise it to about 500mb:

I read that "Live Bytes" does not count memory used by textures and CALayers, so my question is: How do I properly release memory that is used by CALayers of my Image/Scrollviews?

See the real memory usage blue pie chart on the right:

enter image description here

Both real and virtual memory are the highest for this process:

enter image description here

What bothers me is that I'm trying to clean up my large scrollviews and images when popping that controller, and the numbers for the "Live bytes" go down to about 5mb, while "Real Memory" stays outrageously high(~500 mb):

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

Here's the allocations profiling: enter image description here

Alex Stone
  • 46,408
  • 55
  • 231
  • 407
  • In you tests, every time that you instantiate a new scrollview, are you instantiating the same images? – Bruno Domingues Apr 02 '13 at 18:26
  • Have you tried triggering a memory warning to ensure that any system caches do their thing in response and (hopefully) drop any unused data? Remember `imageNamed` uses a cache. – jhabbott Apr 02 '13 at 18:27
  • Memory warnings get triggered. Scrollviews receive images from the photo library that the user selects. – Alex Stone Apr 02 '13 at 18:50
  • Are you checking the 'live bytes'? As per http://stackoverflow.com/questions/8795000/live-bytes-vs-real-memory-in-activity-monitor-on-ios/8797272# 'real memory' includes all memory that the process has used and has stopped using but which has yet to be reused. So it's the window that the process currently has possession of within RAM rather than the window it's necessarily using. – Tommy Apr 02 '13 at 19:38
  • I got my live bytes to go down significantly after each popping of the controller, before it was a serious "abandoned memory" issue, now it's much less severe. Still, the Real memory goes up by 120 mb per push, goes down by maybe 30 mb per pop, so after 5 push/pop I'm using about 560 mb real memory, and the app crashes. – Alex Stone Apr 02 '13 at 19:47

1 Answers1

1

I found a person experiencing a similar issue here:

Mysterious CoreImage memory leak using ARC

The answer (I really hope it is) appears to start using NSData dataWithContentsOfFile: and then create a UIImage imageWithData:. Got an image a user picked? Write it to a temporary file and read it back. I do not trust any other image methods, as they, in my 12 hours of testing appear to behave irrationally in iOS 6.1.2 for large image views.

Community
  • 1
  • 1
Alex Stone
  • 46,408
  • 55
  • 231
  • 407
  • Upvoted for doing your own homework so well. See also my answer here: http://stackoverflow.com/a/15694549/341994 along with the comments that follow it. ImageIO framework gives you a lot of options that can be very helpful, and avoids the implicit caching of UIImage imageNamed that lies at the heart of so much memory trouble. – matt Apr 04 '13 at 04:37