Edit Feb 2014: Note that this question dates from iOS 2.0! Image requirements and handling have moved on a lot since then. Retina makes images bigger and loading them slightly more complex. With the built in support for iPad and retina images, you should certainly use ImageNamed in your code.
I see a lot of people saying imageNamed
is bad but equal numbers of people saying the performance is good - especially when rendering UITableView
s. See this SO question for example or this article on iPhoneDeveloperTips.com
UIImage
's imageNamed
method used to leak so it was best avoided but has been fixed in recent releases. I'd like to understand the caching algorithm better in order to make a reasoned decision about where I can trust the system to cache my images and where I need to go the extra mile and do it myself. My current basic understanding is that it's a simple NSMutableDictionary
of UIImages
referenced by filename. It gets bigger and when memory runs out it gets a lot smaller.
For example, does anyone know for sure that the image cache behind imageNamed
does not respond to didReceiveMemoryWarning
? It seems unlikely that Apple would not do this.
If you have any insight into the caching algorithm, please post it here.
tldr: ImagedNamed is fine. It handles memory well. Use it and stop worrying.
Edit Nov 2012: Note that this question dates from iOS 2.0! Image requirements and handling have moved on a lot since then. Retina makes images bigger and loading them slightly more complex. With the built in support for iPad and retina images, you should certainly use ImageNamed in your code. Now, for posterity's sake:
The sister thread on the Apple Dev Forums received some better traffic. Specifically Rincewind added some authority.
whilst warning that
and
So, there you have it. imageNamed: will not smash your windows or murder your children. It's pretty simple but it is an optimisation tool. Sadly it is badly named and there is no equivaluent that is as easy to use - hence people overuse it and get upset when it simply does its job
I added a category to UIImage to fix that:
Rincewind also included some example code to build your own optimised version. I can't see it is worth the maintentace but here it is for completeness.
The trade off with this code is that the decoded image uses more memory but rendering is faster.
In my experience, the image cache created by imageNamed does not respond to memory warnings. I've had two applications that were as lean as I could get them as far as mem management, but were still inexplicably crashing due to lack of mem. When I stopped using imageNamed to load the images, both applications became dramatically more stable.
I will admit that both applications loaded somewhat large images, but nothing that would be totally out of the ordinary. In the first application, I just skipped caching altogether because it was unlikely a user would come back to the same image twice. In the second, I built a really simple caching class doing just what you mentioned - keeping UIImages in an NSMutableDictionary and then flushing its contents if I received a memory warning. If imageNamed: were to cache like that, then I shouldn't have seen any performance upgrade. All of this was running on 2.2 - I don't know if there's any 3.0 implications on this.
You can find my other question around this issue from my first app here: StackOverflow question about UIImage cacheing
One other note - InterfaceBuilder uses imageNamed under the covers. Something to keep in mind if you do run into this problem.