Hey, now when I finally got to test my app on a device it eats 40mb memory at the beginning which is a huge amount. Is there any good way to determine where exactly things went wrong?
Yes, use the memory allocations and leaks profilers that are part of the Instruments application.
You'll probably want to profile it using the Instruments app that comes with Xcode.
Related
I'm working on a Mac app. Initially monitoring Xcode's memory report while I ran my app showed showed the memory was just ramping up crazy. I used Instruments and profiled my app for allocations and leaks. Turned out there wasn't much leaked memory as you would expect due to strong reference cycles etc. However there was a lot of abandoned memory. By following the stack trace that lead to my code I have fixed by 70% using autorelease pools etc. Still the remaining 30% of abandoned memory seems to point system calls.
Now I have two questions based on that I have two questions
1) I want to fix the remaining 30%. How can I get rid of abandoned memory? I have already used Instruments and know exactly where those system calls are spawned but still dont know what to do to have that memory be cleaned up. (using ARC no manual retain/ release and autorelease doesn't seem to make a diff.)
2) After I know whatever my application was doing has completed and there is no need for any memory to be there (just like the application first started) I want to get rid of all memory that my app has used up. This I plan to use as a brute force approach to clean up all memory just like the system would if the user closes the app or turns off the system.
Basically if I know where my apps memory is in the file system I'll just programmatically call purge command on that or something similar. Because at this point I'm 100% sure nothing needs to be in memory for the app except for the first screen that you would expect the first time you launch the app.
I read this, this, this and this but they weren't helpful.
I'm trying to debug a mysterious app crash that happens after running the app for a few hours.
My hunch is that this may be memory related, as I've not done any memory optimization since starting to build my app.
I'm looking at my application with the "allocations" instrument and I see these numbers:
All allocations 4.70mb
Living 51072
Transitory 357280
Overall Bytes 100.23mb
Overall 408000
Which is the important number here? Does my app take 4.7 Mb of memory or 100 Mb? At which point should I be concerned about my app being killed for memory reasons? I want to avoid premature optimization :)
Since I'm using ARC and TabBarController, most of the controller related memory seems to be out of my hands, unless I find out how to create a tab and lazily init a controller when that tab is first touched.
Thank you!
I have a problem right now. I develop game application for iPad with cocos2d. In my application, I use background music. When I use cocos2d music method SimpleAudioEngine, i got leak. However, my bos don't want have a leak in our application. Any other way to play background music except using SimpleAudioEngine and not get a leak?
Thanx before. Regards.
How do you know that you have a leak? Often times what is reported as a leak truly isn't a leak, or a leak in your own code. In particular the static analyzer only makes suggestions but is quite often wrong about his assumptions.
You may also want to contact the library author Steve Oldmeadow, he can be found on the cocos2d forum. At least he may be able to confirm a bug, or explain why it's not a leak.
Secondly, I wouldn't put too much weight on the leaks. Let's assume you're leaking 16 Bytes every time you start a music. You would have to start the music 16.000 times to have leaked 16 KB. How likely is this in your app, and how badly do you "need" those 16 KB?
Third, tell your boss you fixed the leak. If he doesn't want leaks in the app, he's obviously not a (good) programmer. I know it's a lie, and I know there's going to be programmers who'll hate me. But really before you spend hours or even days to find a "better" way of playing music (possibly with other side effects) rather than using what's tried and true in hundreds of iPhone apps, such a white lie is going to save your boss a bunch of money.
I think that too many people think that leaking memory equals an app that crashes often. Such is not the case, unless the leaks are significant, resulting in out of memory errors or in some scenarios memory fragmentation.
You can use SoundMaster engine instead of CocosDension Sound Engine. ARC support, memory management (NO LEAKS) and many other features like fade in/out, relative volumes for effects or cross-fades.
Hey how can I analyze my apps memory usage more detailed in Xcode 4 like what things eat memory, as it seems my app takes god damn 40mb memory something is seriously wrong here. Any tools I can analyze my code with?
Choose Product / Profile or CMD-I. It runs your app in Instruments. Choose Leaks or Allocations to see how you memory is being used as the app runs.
My app crashes after playing for more than 30 min on some screen due to low memory will my app get reject due to this?
actually i tried a lot to solve but it shows no trace in instrument i even did all permutation combination of code by commenting checking what causing the problem but i was not successful to solve it yet.
its an ipad application 3.2 sdk
I have notice many app which crash due to low memory and they are happily on app store
Any clues,suggestion ,advice will be appreciated.
Thanks in advance
Bill Bumgarner recently wrote up a blog post on using Heapshot Analysis to catch memory growth when some of the more traditional techniques fail. Although his write up is in the context of a Mac OS application, the technique should be equally applicable to iOS. Bill walks you through using the Allocations Instrument to do Heapshot Analysis and track down your leak.
Perhaps this technique will help you track down your memory issues.
See bbum's weblog-o-mat » Blog Archive » When is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth