12

I've been doing a lot of iPhone UI work with image files that are used in multiple locations in a single view or in several views throughout the application. In some cases, I'm drawing new icons, usually by compositing 2 small images (each less than 4 KB).

I've thought a bit about optimizing the loading of images, but I'm not sure what the best practices would be. I would guess that it would be worthwhile to save any images that are created or altered using CG functions. With images that aren't altered, what is the overhead of loading images from a bundle?

UIImage* image = [UIImage imageNamed:@"myImage.png"]

With the memory constraints of a mobile device in mind, what factors are most important when considering caching images? The size of the image, the total number of images that may be cached, and the number of times a single image is loaded come to mind.

goldierox
  • 1,085
  • 1
  • 8
  • 23
  • 4
    `UIImage imageNamed:` does actually cache images already. – Till Jul 15 '11 at 20:40
  • Totally right, @Till. I don't know how I missed that in the documentation. It seems like I was continuing a bad practice already in our code base. – goldierox Jul 15 '11 at 20:48

1 Answers1

17

In the latest performance sessions at WWDC (2011), Apple didn't recommend caching images for most cases. They recommend that you only cache images when you know for a fact, after a performance analysis, that you need to cache images ahead of time because you can't afford the time to load them off disk and decode them. In most cases you probably can afford it.

They specifically noted, as @Till does, that +[UIImage imageNamed:] caches images for the lifetime of your process, and so they recommend using a non-caching loading method, such as +[UIImage imageWithContentsOfFile:]

The reason is that memory is a constrained resource on iOS devices, so if you cache your images, you are likely to cause memory pressure on the system, and apps to get jetsammed. And since iOS 5 jetsams apps using more memory first, if you're caching a bunch of UIImages you're going to make it more likely for your app to get jetsammed.

goldierox
  • 1,085
  • 1
  • 8
  • 23
Ryan
  • 16,626
  • 2
  • 23
  • 20
  • Thanks for the very thorough answer. Given how small most of our images are and how often they're reused, I think we can get away with using `+[UIImage imageNamed:]` in most places. – goldierox Jul 15 '11 at 23:48
  • This answer is awesome and surprising. Just the kind of thing you'd expect not to get any upvotes on SO :). Anyway, I've linked to it from here http://stackoverflow.com/a/14032531/8047 (just some category-love for the non-caching option). – Dan Rosenstark Dec 26 '12 at 23:30
  • 1
    Wait, it's ONLY a time/performance issue? I thought that if I have a `UIImage` cached I save resources by not having it in memory X times... no? – Dan Rosenstark Dec 26 '12 at 23:31
  • @VictorEngel that would be nice to know...has anyone tested this? – Habizzle Oct 14 '13 at 11:28
  • I'm sure someone has. From Apple's documentation: "In low-memory situations, image data may be purged from a UIImage object to free up memory on the system. This purging behavior affects only the image data stored internally by the UIImage object and not the object itself. When you attempt to draw an image whose data has been purged, the image object automatically reloads the data from its original file. This extra load step, however, may incur a small performance penalty." But I'm not sure if this is the same cache. – Victor Engel Oct 14 '13 at 13:18