I am just trying to figure out some memory confusion with my App. Do iphone apps have a cache that store images and such? My memory jumps up when I switch screens, but doesn't go back down when I switch back to the previous screen.
The imageNamed method caches the image, but the cache is purged under memory pressure, so if you're confident that your view controller is being released, then you might not worry about it. If it's an image you don't want cached, use imageWithContentsOfFile and it won't cache. According to the imageNamed documentation:
If you have an image file that will only be displayed once and wish to ensure that it does not get added to the system’s cache, you should instead create your image using imageWithContentsOfFile:. This will keep your single-use image out of the system image cache, potentially improving the memory use characteristics of your app.
Yes. This makes sense, especially for apps with lots of images, because you wouldn't want to be fetching those resources from memory every time a user loaded a view. This is true for dynamically-loaded content as well, which is why apps like Flipboard hog a ton of memory :P
If you're worried about it, just make sure to be more aggressive with releasing resources that are rarely used, for example view-specific images. Other things like background images, which may be on every view, should be kept around in cache.
Related
My iphone application have a lot of high resolution images (eg: 2898 × 779 pixels dimension) and the whole project folder is only 17mb in size but if i run the application and when the first view is loaded the real memory and dirty memory showing in the VM Tracker in Instruments is more than 62mb.Can anyone help me to avoid this?Any suggestions will be thankful.
Images once loaded into memory lose (most of?) their compression. So unfortunately, the images may not look big when on disk (bundled in the app) but they can be a lot bigger once loaded into your app.
one 2898x779 image in ram will effectively use 2898x779x4 bytes = ~9mb, compare that with how big your image is on disk and you should see the difference.
so to actually answer your question, either downsize your images (because your devices screen is probably not that big, unless retina ipad or something) or use a CATiledLayer which will only load up parts of the image that are visible on the screen, and not the whole image.
5 tips to reduce memory issues in iOS apps
1. Use virtual memory
iOS doesn’t use swap file but it does support virtual memory. If an app keeps a lot of data in memory for random access you want to organize it as a mapfile rather then loading it to RAM with
malloc()
. An easiest way to do that is to call
NSData initWithContentsOfMappedFile:
2. Avoid stacking autoreleased objects
When you instantiate objects like NSString with no explicit allocation they live until the release of your autorelease pool – typically until your app quits. Extensive usage of such techniques may lead to a lot of garbage in RAM. Use
NSString initWithContentsOfFile:
so you can later release it instead of
NSString stringWithContentsOfFile:
. The same rule applies to
UIImage imageNamed:
– this is not recommended to use for image loading.
3. Handle memory warnings
Unload unnecessary resources when handling memory warning. Even if you can’t unload any of your stuff call
[super didReceiveMemoryWarning]
in all your UIViewControllers. That will by default free some resources like UI controls on non-front views. Failing to handle this event may make iOS decide that your app deserves killing.
4. Consider limited usage of animated view transitions
Animations like flip transition are noticed to cause RAM usage spikes when executed. This feature is very neat and should be used in many cases but it may trigger memory warnings in a heavily loaded multitasking environment. In particular we strongly recommend to avoid animating OpenGL views.
5. Test your memory footprint on device
Use instruments to test. The most useful tools are Allocations, Leaks and Activity Monitor. Testing on simulator is not relevant in most cases since its memory footprint tends to be completely different. Once you test you can figure out how much RAM each part of your app uses, where are the bottlenecks and how you can optimize.
From http://surgeworks.com/
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.
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.
I'm seeing my app being killed by iOS with an out of memory message, however, while tracing the progress of the app in the Allocations Instrument, I see lots of mallocs that seem to be occurring outside of the code I've written.
I'm not seeing any leaks being caught, so I assume these allocations are supposed to be there. Thing is, because I'm not sure about why they have been allocated, I'm not sure what I can do to optimize the app and prevent the OS from jettisoning my app.
Does anyone know why the memory is being allocated, or is there any way for me to find out?
Here are a couple of shots from Instruments showing the mallocs. In the second shot, all of the allocations have the same stack trace.
EDIT
I' displaying a single large image as the UIView background (1024x768), then overlaying a smaller (600px square) UIView with some custom drawing and a third UIView (550px square) over the top of those that contains two 550px square images overlayed.
I'm guessing that this is not appropriate, and there is probably a better way of achieving the composition of views I need for the app to work.
Should this be possible on the iPad?
I think there's not really much information to go on here - if you add a bit more information about what this view in your app is doing you might get some more informed suggestions.
From the screenshot, it would appears large blocks are being allocated to display an image.
Given that I'd hazard a guess that either you're trying to display some very large images, or you UIView is large, or you have more UIViews in memory that you need to display the current screen.
I guess the easiest way to track down exactly where they're coming from would be to disable the part of the application you suspect then run again and see if the allocations still occur.
EDIT
Are all the images the same size as you're displaying them? (ie. are you trying to display a 5M photo as the 1024x768 background?) If not you probably need to scale them down to the size you are display them, or at least closer.
If you're not needing transparency, make sure to make all the views opaque.
I figured out the source of the problem - I was using
[UIImage imageNamed:#'Someimage']
to load in my images. This, as I'm sure many people are aware, caches the image data. I had enough images of sufficient size to cause my app to be jettisoned.
The problem was apparent not because of the size of the image but because of both the size and number of images I was using. The lesson here is be careful with [UIImage imageNamed:].
Thanks for all of the help, chaps!
Mallocs can occur inside of other API's that your app calls (such as loading images, views, playing long sounds, etc.) You can try changing the size of your images, views, sounds and other objects by various amounts as a test, and see if the size of the malloc'd memory changes track one of the changes that you've made.
So I've seen this question asked before and in fact I asked it last night but I thought I'd give it another go just to see if I could get any other unique views on the problem.
The Problem — I have an app with a large number of uiimageviews (with image downloaded to disk) in a scrollview which of course has two large problems facing it: Memory use, and performance. In my app memory use isn't so much a problem because I am employing techniques such as dequeuing and reusing imageviews and such. But performance is another thing entirely. Right now, as a memory saving procedure, I only store image filepaths in memory because it would be ridiculous to store images in memory. But the problem with this is that reading from the disk takes more time than from memory and slows down scrolling on the scrollview immensely.
So, what kind of techniques do any of you suggest for something like this? I've seen three20 but don't want to use it because I need high customizability in my view and that just won't do. Image files are not large, but just thumbnail size so there is no scaling or excess size. There's got to be an intuitive way to handle this. The built in photos app handles up to thousands of photos perfectly with low memory and slick and smooth scrolling performance.
Fundamentally, the problem is that you're probably doing a bunch of disk I/O on your UI thread, which is basically guaranteed to cause performance problems.
You should consider loading your images on a background thread and updating the image views on the main thread when the images are loaded. Depending on your use case you can get more or less clever about how far you preload in advance, etc, so you can have images ready. (There might be some usable source code or even Apple sample code out there that does something like this, but I don't know of it off the top of my head.)
You may notice that some applications (not sure about the Photos app) have an intermediate stage where they load a very small thumb size image for all images, and scale it up to the render size, which acts as a placeholder until the full size version is loaded-- if the user scrolls past that image before the full size is loaded, the visible effect is nearly the same as if the image was there all along.
I am able to load over 200 UIImage objects into a NSMutableDictionary without any memorry warning issues.
When I start displaying them on the screen (after about showing 10-20 images) I get low memory warnings and an eventual crash.
Only about 8 images are displayed at anyone time.
Does it take additional memory to actually draw a UIImage on the screen?
No memory leaks are showing up and i've reviewed code for leaks many many times.
Its probable that you initially create a link to the image, the only data that is actually read at this time are dimensions and image type (in short), the rest of the data is usually not needed until requested usually from a background process i.e. displayed on screen. When it is displayed the actual image data is downloaded from the filepath and decoded according to its image type, it is then cached so it doesn't have to be downloaded again, the caching takes a lot of memory plus if your using double/triple buffering there's extra memory required for the off screen drawing.
Try disposing of all image data before loading new images.
The documentation says that having a UIImage doesn't necessarily imply that the image is actually stored in memory, because it could be purged from the image cache. But it does say that if you try to draw it, it will be pulled back into memory. Maybe it starts purging from its image cache before it warns you about the low memory condition. That explains everything you're seeing.