I have an app that stacks quite a nice amount of views on top of each other.
At some point I receive a Memory warning level2 (which is kind of expected).
The thing is, when I run Instruments, I don't have any memory leaks and the app takes up something like 9-10MBs... which is not that much, I'd say?
Question is: how much memory can an app consume, a.k.a. how much RAM does the iPhone have?
I know that I can respond the the receivedMemoryWarning and free up some memory - but this would mean that I'd have to get rid of some of the views, which is not the solution I'm looking for...
The app didn't crash so far - but I'm concerned that it might crash on other user's iPhones...
An application can use 30-40 MB of real memory or greater then this and there will not be a problem. When you are getting a memory warning level-1, till then there is not a problem, but if you get memory warning level-2, then the app might or will crash after some time.
solution is, when you get memory warning level-2, inside your delegate method, release some memory which you are not using currently.
You app won't crash anyone's iPhone. The system will just kill your app. Anyway 3GS is rumored to have 256Mb while iPhone 4 has 512Mb. It still won't matter because when you receive a warning you better comply.
Try reducing the amount of views you have or unload the ones which the user can't see.
Related
I am implementing an iPhone application and when I ran this app initially it was showing memory size was 5.3MB
and after 10 min it was showing memory size was 185.3 MB.
I'm releasing objects manually and also analyzed my app, I have only one memory leak(that to return object in class method). What was the problem? is it harm to app while apple approve it?. Please help me. Thanks in advance.
No, you really shouldn't release it with this kind of a leak (or memory accretion). It will lead to crashes and that will cause data loss and upset users.
Heapshot analysis is designed to track down these kinds of problems. That is, use the Allocations Instrument to track memory growth over time iteratively and then eliminate the large memory consumers.
Apple will probably approve it as long as it is not crashing within the review time.
But no you should not release the app if you have a memory leak like this. Your app will have poor user experience and might crash if the users device memory runs full. You will get a low app store rating.
I would suggest you find out which object is taking up so much memory and fix it. If at all possible switch to ARC, this will take away some leaks.
I have same problem too. NSZombieEnabled flag work for me. I think this might be helpful to cope up with ARC. I have followed this link: How do I set up NSZombieEnabled in Xcode 4?
I've been surprised that iOS 5.1 does not manage memory quite as I expected. When the device is running a lot of apps, it appears that iOS does not kill memory hogging apps in the background, but sends memory warning to my own app as well.
For example showing a UIImagePicker crashed the app on two test devices. Double tapping the home key and killing some of the background apps prevents the app from receiving the memory warning and crashing.
I'm wandering if iOS would not free up memory for me, is it acceptable to show some sort of alert view notifying the user that the memory is low and some of the background tasks have to be killed?
I'm at a loss of how to deal with such events - does it take time for iOS to clean up some memory (while apps respond to memory warnings)?
iOS does a lot of stuff before bothering you with memory warnings, including killing backgrounded Apps. Since iOS 5, iOS is even going to annoy you as less as possible with memory warnings, meaning that you only get one if there really is a need for you to get rid of stuff that is using memory but not needed right now (and that you can safely recreate in the future without taking hours for it). If your App crashes without giving you a memory warning first, chances are that you allocated so much memory that the system can't tell you that its running out of memory before it decides to kill you, the reason for this is that the memory warning is scheduled on the runloop of the main thread and until you give the runloop time to do another iteration, you won't receive the warning.
Also, Apple doesn't like you to tell the user that there is a memory problem; Its your App that has to deal with it, not the user! So its very very likewise that your App gets rejected if a memory warning comes up while the review team is reviewing your app (rumor says that they send these warnings to test how your App reacts to them)
Soo, to sum it up: iOS does work like you expected by killing what it can and even shutting down other system daemons, only after this happening you will be notified that memory is low. The correct way to respond to these warnings is to free up as much memory as you can, start with the big stuff that can be easily recreated in the future (eg. if your app shows loads of pictures but not all are visible at a time, throw away the ones that aren't visible right now). Telling the user is the wrong way to deal with the problem and Apple doesn't like it, so try to solve the problem on your end.
This question is NOT about retain/release things in iphone memory management. I understand the routine quite well and there is no memory leak things in my app.
I pop up the question shown in the title, when I use Activity Instruments to monitor the overall memory activity of my app.
The instrument always shows that the amount of "real memory", which my app is using, keeps being between 21 MB and 30MB, never higher. I think this amount is relatively not big. However, sometimes, my app will give level 1 or 2 memory warning (never crash and I don't do anything for this warning in my code).
so I am wondering what's really behind iphone memory thing. I mean, does real memory the only things that triggers warnings? or there is anything else (such as virtual memory, as shown in the Instruments) inside the whole memory I should take care of?
Although my app never crash due to memory issues, this warning thing (especially level 2 warning) really annoys me and makes me fear of crashing once I release it to public in the future.
Any help?
Thanks
Memory warnings exist to tell your app you're nearing your limit. They are not necessarily a 'bad' thing - plenty of applications simply ignore them.
The actual implementation details about when a memory warning is triggered are not important, and in fact will vary considerably from device to device. An iPhone 4 might have 512MB of RAM to play with, but a 3GS will have half that.
That said, there are some things worth knowing about memory warnings:
A memory warning is triggered when the overall amount of available free memory reaches a certain level
These levels are undocumented. So you don't know what the difference is between a level 1 warning and a level 2 warning, other than the fact 2 is worse (more urgent) than 1
Memory warnings are not application specific. A memory warning is delivered to all applications currently running and not suspended. So you may not be directly responsible for triggering one.
When memory warnings are received the system will try and free up memory on your behalf
Again, the exact implementation details are undocumented, and you shouldn't need to care about them. A memory warning is an opportunity for you to help the system by freeing up any objects you don't need.
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.
According to Instruments 'Net Bytes' of my app are never more than 2MB yet sometimes I receive memory warning and the app crashes because some views on the stack are unloaded by force.
I'd like to know what is the typical memory footprint where system would not send you memory warning and unload the views ?
I have so far tried this on OS 3.1.2 on iphone 3GS and 3G and with 3G giving warning almost 80% of the time I test the app on it.
The problem isn't that you're using to much memory. It might be some other application that's using the memory and causing your app to receive a memory warning.
The problem probably is that your not setting your views to nil on viewDidUnload.