I'm afraid I introduced a memory leak or something to version 1.2 of my iPhone app. When I use 1.2 version I notice that my battery drains a lot quicker then with 1.1 version. For comparison, with 1.1 version the battery would last whole day and still have plenty of juice in the evening but with 1.2 I find that I have to plug it in mid afternoon.
Would a memory leak (or a lot of them) cause an increased battery drainage, or do I have something else going on?
The only interesting thing my app uses is AVAudioPlayer class to play some caf audio files. Other than that it's just couple of views with a table view.
I do call AudioSessionSetAcvie(false) in my applicationWillTerminate method, so I don't think it's the audio session that's causing this. I don't have to have my app active for the battery to get drained. It's enough to use it for a while and then exit. So I'm pretty sure I'm leaving something behind, I'm just not sure what.
I tried playing with Instruments tool, but it looks like you can't used with the app running on the device (for some reason my app stopped working in the Simulator)
Any ideas on how to go about finding what's causing the battery to drain?
Memory leaks will not cause increased battery usage. However, if a memory leak persists, eventually you will get a memory warning, and if you can't clean up enough memory, your application will be killed.
Increased battery utilization usually means something is causing your code to continue running. The best way to tackle this problem is to run your application under Instruments (with Sampler probably) and let it sit there in the state that you're confident it usually runs the battery down. Inspect the results of Sampler, and if you have code running, you'll be able to see the stack trace for it.
Hopefully once you've located what code is running, it will become apparent how to stop it.
Memory leaks won't cause increased battery usage, as Nilobject says.
I would try commenting out various areas of functionality, one at a time, to try to narrow down the area that is causing the problem. In your case, the first thing to try is obviously to remove the audio. If, once you've done that, battery usage is back to normal, you know where to look more deeply.
(for some reason my app stopped working in the Simulator)
I would fix that and use instruments to fix the performance bug. It's never a good idea to fix the difficult defect and leave the easy one.
Related
I'm building an iOS puzzle game to become familiar with the platform and a few of my testers are noticing a severe lag issue that occurs intermittently about 15 to 30 minutes after playing it and the lag doesn't appear to be associated with any specific part of the game. I've tested the app using the Leaks instrument and havent found any leaks yet.
What are some things that would cause a game to instantly begin to lag after playing it for a while?
What are some methods/tools I could use to troubleshoot the lag?
Thanks so much for your wisdom!
UPDATE: As a new iOS developer, I was under the impression that the Leaks instrument would report at least most of my memory leaks, so I was very comfortable believing my app was managing memory properly when no leaks were reported. Not the case! After following a few of the suggestions posted here, I watched a few videos on how to use the Allocations instrument and found that my app was losing a TON of memory over time and, after spending about two hours walking through ALL my code and fixing memory-related code, my game is no longer lagging or reporting any lost memory or memory leaks. Thanks, all!
The main thing would probably be a memory warning, which would in turn cause a bunch of game assets possibly to be freed all at once...
Instead of leaks, the place to start is the ObjectAlloc tool. Leaks only shows you memory used your application already knows about. ObjectAlloc shows you the total memory used, and the real issue would be seeing the graph of memory used climb over time.
Lastly, I would try to get the game into that state while using the TimeProfiler instrument, so that you could see what kinds of operations took up a lot of time suddenly when the game slowed down. You have to do that on device, it will not tell you what is really going on using the simulator.
check to see if you are getting a memory warning. also, try using the heap shot tool in instruments, as something could be holding on to a reference, and stopping objects from deallocating, this doesnt show up as a standard leak.
i would definitely have a look at the object allocation tool, and keep an eye on objects still living.
if you haven't used instruments much, I think apple have some videos up on the dev site going through them.
Are you using leaks with the simulator or with an actual phone? I have found the simulator to have different results than a phone when running leaks. Based on your description it sounds like you have some leaks occurring.
I have had some similar feedbacks while battery runs low. So, you can check, does issue reproduce when device is powered, or not.
Also, do you use openGL in your game? I'm asking because i've observed some lags with first-time appeared textures drawing, although these textures were previously preloaded and cached.
And last question, what devices your testers are working with?
LEAKS are NOT the same as excessive memory allocation.
It sounds like you are just not releasing things that don't need to be around anymore and you're maxing out on memory and chunking.
Check your allocations and keep an eye on what keeps expanding when it shouldn't.
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 iOS 3.2 program running on the iPad that is document-centric. Sometimes, when closing a document, there is a memory spike in Instruments. I'm pretty sure I'm not leaking memory, since the allocations graph stays pretty steady between 5mb and 10mb, except when closing, where it spikes up by about 5mb or so (and the leaks tool is showing very small leaks, a few k total, nothing that I'd expect to cause crashing).
This seems to be leading to iOS getting fed up and jettisoning my app. The memory use never goes about about 12mb, but the error log report displays that it's using 19988 "Count resident pages", which is way, way higher than anything else.
My problem is that I have no idea where the spikes are happening or why. It's the same code, over and over, and sometimes a document will spike, other times it won't. There doesn't seem to be a way to use both the debugger to step through the code and Instruments to see what's going on at the same time, so I'm not sure how to track down this problem.
Is there a way to see the memory use in the debugger?
IIRC, Instruments should have an Allocations tool which would show you what is demanding all that memory. If you open up the right side bar, there'll be extra information which shows the code path it used for that allocation.
I am testing a particular use case for leaks. Sometimes, I get the leaks and other times I don't even if I go through the same usecase. Can you suggest whether it is because of the system frameworks or my code?
I have checked in my code and everthing looks perfect without any unreleased objects. Can you suggest a solution?
Thanks
It's extremely unlikely to be the framework. Don't forget that there are hundreds (thousands?) of developers out there using it so the chances of someone not noticing a bug there is rather slimmer than code that's only been reviewed by yourself.
The most likely source for an intermittent memory leak is autorelased objects. Autoreleased objects hang around until the autorelease pool to which they belong is drained. Depending on memory conditions, they may look like they're leaking during one run but then they don't the next run.
See Avoiding, finding and removing memory leaks in Cocoa to learn how to track down memory leaks.
Edit01:
You might get away with it but I wouldn't recommend it. If it leaks while Apple is testing it you stand a good chance of being rejected.
As a quality issue, it depends on how bad the leaks are and how long they can go on during real world use. Every app probably leaks a few bytes here and there. (For example, there are known leaks in some of the frameworks.) If the leaks are very small, they won't cause problems especially on an app that only runs for a short time. However, if the leaks are larger or the app is designed to run for a long time, then the leaks will eventually bring the app down.
For example, suppose you have a program like the weather app. As a quality issue, it really wouldn't matter if it leaked a bit because the weather app is used quickly. People open it, look at the weather and then close it. The leaks don't have time to accumulation. On the other hand, if you had an app like a web browser or a eReader which people leave open for long periods the leaks could accumulate and bring the app down.
In short, like all other programming task, tracking down leaks is a tradeoff between perceived quality versus development. It is very common to spend more resources tracking down a trivial but common bug than to track down a serious but very rare one.
I would reiterate that the memory leak detection methods in the leak above will eventually locate the leak. If you spend the time on it you will eventually find it.
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.