I have an iPad app that is doing really well, zero crashed reported by Apple after 5 months and 3 releases.
However occasionally the OS kills the app, my guess is for shortage of free memory.
I am not doing anything right now in the warninglowmem event.
I would like to receive some solid recommendation of what I should do to improve the memory footprint. What tools and tricks I can start using to understand where I am right now and how further I can go with the improvements.
I'd suggest starting by reading about Instruments which will let you see what memory you're using and how much. In particular, the "Quick Start" and "Analysis Techniques" sections in that document should get you pointed in the right direction.
Using the "Allocations" instrument will help you watch your memory grow and tells you where it's being allocated.
You might also try using the "Leaks" instrument, which will point out if you're leaking memory (rather than just allocating too much).
There is an awesome instrumentation tool included with Xcode that lets you look for leaks. From the Run menu choose Run With Performance Tool -> Leaks and you can see where you might be leaking memory over time. That's a great place to start. Next you can look at the "Allocations" tool to see how you're utilizing memory over time. Start there and you'll learn a ton.
Related
I have run my app with instrument and i m getting a memory leak but i dont know at which point that memory leak is happening.
How will i know at which point memory is leaking.
Check out this article "Actually finding a memory management error with Instruments", from the big nerd ranch. Creating "heapshots" is a good way to start narrowing down the code parts that show no obvious memory management errors at first glance. But as ACB stated already, if a system library is leaking (rare case) there's not much you can do about it. But most of the time the memory issue is always in your apps' code somewhere! :-)
It says responsible library is quartzcore, and it is only 16 bytes. As long as it is not in the app and the OS is causing the same, you cant do much about this. I would recommend you to ignore this.
If you are facing issues, check the allocation tool -> Live bytes section and check if memory is shooting up when you are selecting a lot of images at the same time.
I can see from your screenshot that your app is already running in your device/simulator and you are trying to run it again with instrument, try to close your app completely from device and then start it again with instrument.
You can read more details about Xcode instrument from Apple.developer InstrumentsUserGuide
Also I have found another good tutorial about this in Raywenderlich blog
Another good documents is here
I am checking memory allocation in performance tool, i am getting more than 90 MB memory allocation while running an app for 30-40 mins.Can anyone tell me at which extent memory allocation can go or there is some specification of APPLE for memory allocation or what is criteria to upload it on an appstore or what .
Please hme next week app is going to upload on an appstore
Manjot Singh
Use Instruments to find memory leaks: in Xcode, chose the menu Run -> Run with Perfomance Tool -> Leaks. See for example this article or this article on how to find and fix memory leaks with Instruments.
I pretty sure that your app has tons of leaks, if you are saying that memory usage grows during time. This could be the reason why appstore can reject your app, so you'd better fix that.
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 ported one of my mac applications to the iphone. WOW!!! is it slow! At first I started thinking maybe I was doing a lot of disk access. But as I started looking I realized I simply do an offset read of a binary file. I only read in about 512 bytes of data. I also have an array that is huge. Maybe 2MB. But why would that be slow? It is perminatly located in memory.
I would love to hear some ideas from you all!
When you have major performance problems, the tool to pull out first is Instruments. Start with "Run With Performance Tool > CPU Sampler" and get a feel for where your app is spending its time. After that, check Object Allocations to see if you're hitting memory harder than you should. iPhone is a resource-constrained environment compared to the Mac. Things that you think of as fast can dramatically impact performance on iPhone. Disk access is much more expensive. Even allocating memory can be a significant impact (welcome to the world that server developers deal with every day). You only have one core, so things you stuck off on a background thread now compete with your main thread. It's a different world.
It's hard to debug the application over Stackoverflow, but there are many reasons why the iPhone app runs much slower: Your mac applications run on probably the latest CPUs with tons of memory, as for the iPhone it's very limited (3GS is rumored to have 600MHz CPU with 256MB RAM). Also, Mac applications are a bit more forgiving when it comes to memory usage; as for the iPhone it's important that only create the objects you need when you need them and release them when you no longer use them. Delaying object de-allocation results in some slowdown as well.
I recommend using Instruments performance profiling tool, that is bundled with XCode and the Developer tools. It'll give good tips on what the bottlenecks are.
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.