img_data_lock iphone - imageNamed vs imageWithContentsofFile

I am noticing a surge in memory and the responsible caller as listed in instruments is img_data_lock and responsible library is CoreGraphics.

I have been reading that the issue relates to cached vs not cached image load (Difference between [UIImage imageNamed...] and [UIImage imageWithData...]?) Currently my app loads a series of images via imageNamed

replacing the imageNamed call with imageWithContentsOfFile seems to solve the issue.

Does anybody have any information about the img_data_lock caller ? Why would someone use imageNamed if it开发者_如何学Python takes such a toll on memory ?

UIImage's methods imageNamed: and imageWithContentsOfFile: do slightly different things. imageNamed loads the image in a special system cache, and then future calls with that image path will return the image in the cache instead of reloading it from disk. imageWithContentsOfFile simply loads the image at the path you specify, but does no caching. Multiple calls to imageWithContentsOfFile for the same image will result in multiple copies in memory.

iOS doesn't seem to empty the cache (well or at all, I'm not sure) when a memory warning is issued, which can lead to apps being terminated for lack of free memory. UIImages loaded with imageWithContentsOfFile respond to memory warnings by purging their images and reloading it when needed, which might explain why your memory spike went away.

Also, the cache seems to be much larger in simulator than in actual hardware, the problems and crashes I've seen with UIImages using imageNamed have only happened on a device. Watch out when testing on the simulator!

The only reason I can see for using imageNamed the same image is used many times in your views. Alternatively, you can implement your own image cache, and get the benefits of having a cache that you can control, as described here: http://www.alexcurylo.com/blog/2009/01/13/imagenamed-is-evil/