If my app uses less than 10MB do I have to bother to use those methods? I know that they are for caching low memory situations but this might occur only if you do not tested you app before releasing it. If you have tested your app, the app does not have leaks, have a small memory footprint, then why should anyone bother to use memory warning methods?
Your app is probably not the only thing running on the device. Other apps and processes are also taking up memory, and in some situations they may need it more than you. It's always a good idea to respond to memory warnings by releasing cached data that can easily be loaded again. That way the operating system has control over the memory usage, and it won't have to terminate your app.
Related
hi i just want to know this: When will iphone 3gs and iphone 4 send out memory warnings
i mean after how much memory our app uses does the both devices send warnings?
Thanks
You don't know when it will fire. You don't know how much memory is being used by other apps running in the background, Safari keeping webpages, etc. Pandora might be streaming in the background and it might be using a significant amount of memory. Don't count on any single amount of memory. Load lazily, and release uneeded allocations in didRecieveMemoryWarning.
If your app requires a lot of memory, some game developers tell their users to restart the device before playing to ensure the most memory for the app, and best performance.
It is not strictly defined but Apple suggests you don't use more than 24MB of graphical memory as overuse of graphical memory is typically why an application receives a low memory warning.
The only good way to manage critical low memory situations on the iPhone is to implement the didReceiveLowMemoryWarning delegate methods and release as much memory as possible at that point. This means for instance:
All non-visible images currently loaded in memory
All view controllers and their subviews if not in use
This can of course be done safely provided your application is able to reload that information at a later stage. didReceiveLowMemoryWarning is however a last resort situation for your application.
To avoid getting to that point it is recommended to only load resources lazily i.e. when and only when you need them, and release them when they are no longer needed (for instance implementing viewDidUnload on all your controllers).
I have an application under development that uses a large amount of memory for images and OpenGL textures.
I have noticed that occasionally, in fact frequently on some devices, SpringBoard, the application which manages the home screen for the iPhone and iPad can take up excessive amounts of memory, sometimes twice as much as normal.
When this happens, it sends my application in to memory warnings and even crashes. My images do get released as soon as possible, but I believe that due to the sheer volume, it simply isn't good enough and still results in crashing...
I can't find much in the Apple docs about SpringBoard, but it's pissing me off.
Any ideas or pointers on figuring out what causes SpringBoard to be so aggressive?
Your application shouldn't crash in these situations -- it should shut itself down gracefully when the OS tells it to quit. Apple won't document Springboard very much because there's not much they can tell you about it that should affect what you do as a programmer, which boils down to "use as little memory as possible; don't leak memory; quit as quickly as possible when told to quit".
In short, if you're spending any more time worrying about Springboard's behaviour, instead of fixing the crashes in your app, you're not using your time wisely.
The answer was that MKAnnotationViews, despite being autoreleased, were pooling up in the memory footprint of SpringBoard, as opposed to my own app, and were not manifesting themselves very clearly in Instruments.
This is a fairly deceptive thing on Apple's part, particularly in that they allow you to autorelease and never use an object, but it will never actually be released... therefore it is technically not a leak in the eyes of Instruments and static analysis, but can still easily lead to memory related crashes.
i have an application which takes "live bytes" up to 3mb. The application showing memory warnings and it will crash continously. when i use object allocation tool i can see the live bytes.im using imageWithContentsOfFile in many places. i can see NSConcreteData object is taking more momory.what is the reson for that? may i know how much memory is allowed to an application.
You can't really know how much memory you're allowed to use, but in general you're fine up to 20mb on iPhone/iPod devices. However, your app can be killed not only for using too much memory, but for failing to decrease memory usage when warnings are issued. So even if you're not using all that much memory, if the system detects that you don't release any memory when getting memory warnings, your app might be shut down. At least that's my experience, maybe others have more detailed knowledge about what's going on.
imageWithContentsOfFile: has a built-in caching mechanism, so if you're loading the same images over and over, there should be very little overhead.
EDIT: imageWithContentsOfFile: does not cache images. The method imageNames: does cache images, and it's the only image creation method that does.
If an application produces a lot of memory leaks, are they "just" an in-app problem or are they also in RAM after the termination of the application? So does the iPhone OS release the memory allocated for the sandboxed application?
Thank you
Memory leaks are blocks of memory allocated by the OS for your program to use while it is running, but not correctly returned as not in use when the program has finished with them. So this memory is 'lost'. Your program isn't using it, but the system doesn't yet know that it is free for other use.
When your application finishes running, all of the memory allocated to it by the OS, will be returned for re-use. Which answers your question.
However, memory leaks are a significant bug. On a low-memory device, like an iPhone, the less memory you consume the better, you don't want to be leaking memory as you run. If the device runs low on memory, your application may be terminated or crash, unexpectedly.
Memory leaks occur when you allocate any object and miss out to release that objects while running application , so do analyse in xcode which will help in checking memory leaks, and run profile mode in xcode will help to check leaks possible in application.
and use NSAutoReleasePool to release the autorelease objects which will be created when you just assign objects wothout allocating
hope it helps .
Memory leaks are an in-app problem, but can have side effects on the total available RAM.
They are blocks of memory that are marked in use when they actually are no more used. So they are lost to the app. If you have leaks, this will increase memory consuption. And bad memory usage will be noted by the system and the app might be jettisoned (killed) by the watchdog, jetsam.
So keep your memory leaks to a minimum ;-)
It has an effect on the overall OS, but negligible in consequences. Because your app is not killed when you tap the hole button, but rather "backgrounded", all the memory that's used by your app is still live and unavalaible to the system. Jetsam will first tell you that the memory is low and ask you to get rid of stuff you don't need. Of course you cannot free your leaks.
If you still use too much memory for the system, and it needs to allocate more memory for another process, your app will get killed. All the memory it used will be freed, leaks included.
Leaks are bad, use the static CLang analyzer in Build and analyze.
I am wondering is there a way to find out memory allocations that dont get deallocated on iphone application exit or it's termination .
I have been using instruments fixed most of leaks that I had in my application, but i am worried that there are still some allocation that i didnt release.
Thanks
In short, don't bother trying to find and fix leaks caused during application termination. It is quite likely -- almost guaranteed -- that neither Cocoa nor the iPhone frameworks try to release all memory on termination as doing so is entirely a waste of CPU cycles.
If you are going to hunt down leaks, do so through using your application as your users do, keeping an eye on the Object Alloc instrument's analysis.
What can be useful, though, is putting a hook in that is triggered before termination is an absolute. Stop there and make sure the app's object graph is as expected.
No need to worry about cleaning up memory on application exit. The operating system will wipe out any memory allocated to your application at that point.
but if you use opengl please clear out your buffers :P.