Menu
I am new to Objective-C (coming from Java) and I think I am getting a pretty good understanding of memory management. But when my app loads, I get a extremely small memory leak, that only occurs when the game is loading (we are talking about 32 to about 512 bytes).
It's random when it leaks, and it doesn't seem like it's the user that triggers the leak. Normally it is detected after about 20sec to 1min.
The information I get from the debugger is never the same. Sometime it's UIApplication thats "responsible frame", sometimes it's [UIWindow makeKeyAndVisible] and sometimes it's [UNibDecoder].
Is this bellow a "accepted" limit, or should the app not leak at ALL? This is my first "big" app. I have done a minor flipsideview app, and there where no leaks what so ever..
On the other hand, what is the best way to identify leaks?
200
Xcode's Memory Graph Debugger If you haven't used this yet, it's easy to access while developing. Tapping on the icon will pause your application and generate a graph of the objects with their references to other objects. If there's leaked memory detected, you will see purple icons on the left pane of Xcode.
Memory leaks are a common error in programming, especially when using languages that have no built in automatic garbage collection, such as C and C++. Typically, a memory leak occurs because dynamically allocated memory has become unreachable.
If you suspect you are running into a temporal leak, a good way to check is to use Android Studio's memory profiler. Once you start a session within the profiler, take the steps to reproduce the leak, but wait for a longer period of time before dumping the heap and inspecting. The leak may be gone after the extra time.
If a program runs continually, the smallest leak will eventually and inevitably lead to a program or system crash because more and more resources get locked up until they are exhausted. A memory leak starts when a program requests a chunk of memory from the operating system for itself and its data.
It's not great, but it won't get your app rejected unless it causes a crash in front of a reviewer. The size is less important than how often it occurs. If it only occurs once every time the app is run, that's not a big deal. If it happens every time the user does something, then that's more of a problem.
LLVM's static analyser can find some of these problems for you. Clean your build, then select Build and Analyze from the Build menu. There's also a Leaks template in Instruments.
It's probably a good idea for you to track down these bugs and fix them, because Objective C memory management is quite different compared to Java, and it's good to get some practice in with smaller stuff before you're stuck trying to debug a huge problem with a deadline looming.
156
Too much total live memory use is what will cause your app to crash and/or get rejected. If you leak memory inside a loop or repeating method, the leaks will eventually add up, and your app will crash.
But if there is a leak, but not in a loop or repeating process, and the total amount is less than typical memory usage for an app, then it might be impolite and inelegant, but there's really no way to tell, and there's very little operational downside.
I often stress test my apps by purposely "leaking" several megabytes during app launch, and making sure the apps still run OK. Some of these apps have gone on to be approved for App store distribution with this leaking test code still accidentally left enabled (mia culpa!). But that shows that even a few MB of leaks is not a problem for app approval (unless that's enough to make your app crash during low memory testing).
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
