[MonoTouch] UIImageView memory model

[Chris Toshok]

It really depends - there are a few places where you're taxed for images
that you load and/or manipulate.  The activity instrument doesn't tell the
whole story, because not all memory is the same in iOS.

You should use the VM tracker instrument, and look for these guys:

Memory Tag 70:

this is where the decompressed image data gets stored.
 decompressed/decoded, but not inflated to RGB(A). so if you load a full
screen ipad image of 1024x768 but it's a 256 color indexed color, it will
only take up 768k.  an RGBA image will set you back ~3 megs.  Memory Tag 70
is dirty memory, and afaict it's 99-100% of the time resident, which means
it counts against your tally with the OS watchdog, and means your app will
be terminated if it's in the background and the foreground app needs more
memory.

This is the biggest reason why UIImage.FromBundle is a bad idea for big
images.  .FromBundle allows for caching which is all well and good but you
have no control over when/if the image is kicked from the cache.  Use
UIImage.FromFile, and manually dispose of the UIImages when you're done.

CG Image:

This is where you'll see image data you build up programmatically (i.e. if
you use CG Image bitmap context and then pull the image out of it and use
it).  You're taxed for the actual expanded  image data (so if you use RGBA,
it's w * h * 4).  This memory sticks around until you dispose of the
UIImage, so in most cases it's better to cache these images to disk,
dispose of the UIImage you built up, then reload it.  It'll shift the
memory burden over to Memory Tag 70, but the increase there will often be
less than the decrease to CG Image memory.

Core Animation:

I'm guessing about this one, but I assume this is memory tied to backing
stores for UIView subclasses.  A UIImageView will take up either 3 or 4
bytes per pixel for the size of the view depending on if the data is RGB or
RGBA.

That said, loading 64 images into a scrolledview is likely a bad idea if
they're of any size.  you can load them dynamically using a sliding window
of 3 images or something, and it'll save you a ton of memory.  Just make
sure you dispose of the UIImage's manually when they leave the window.

On Mon, Nov 21, 2011 at 11:19 AM, kentfonager <kent at netcoders.dk> wrote:

> Hi everyone
>
> Does anyone know how a UIImageView stores the loaded UIImage in memory ?
>
> I have made several test and have used Instruments (Activity) to read out
> memory usage for my simple app.
>
> The simple app loads 64 images (different named jpgs) into memory and adds
> the views onto a UIScrollView. I'm testing with two different image sets.
> The first one "red" is an image 100% red. The second one "map" is a tile
> from a graphical map. So the detail level is much higher on the map tiles
> than the red one.
>
> But the test shows that when loaded into the UIImageView, they both consume
> the same amount of memory. Can anyone explain this to me ? Is it because
> the
> the framework unpacks the images into some "raw" format or what ?
>
> I hope someone can help spread some light on this for me :-)
>
> Take care and thanks in advance,
> Kent Fonager, netcoders aps
>
> --
> View this message in context:
> http://monotouch.2284126.n4.nabble.com/UIImageView-memory-model-tp4092801p4092801.html
> Sent from the MonoTouch mailing list archive at Nabble.com.
> _______________________________________________
> MonoTouch mailing list
> MonoTouch at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monotouch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monotouch/attachments/20111203/c3c25890/attachment.html