2

I have some general questions about what happens to app memory.

  1. What happens to memory when the app enters the background or suspended. I'm asking this because my app has some memory leaks that are, from my research, bugs in Apple's framework and not due to my coding. The leaks are fairly small, (~100bytes), so they should not disrupt performance. However, I was wondering what happens to these leaks when the user stops using the app? Do they go away or do they just stay forever in the phone's memory?

  2. Also, another very similar question, except with retain cycles. Do retain cycles get resolved when a user quits an app, assuming they are not a big of a problem to crash the app while in use?

So, in short, when a user quits an app, do allocations and memory get reset to 0, is what I'm trying to ask.

Thanks for your help!

B Wu.
  • 83
  • 7

2 Answers2

4

The answer is complicated.

An app can be in a variety of states:

Active
Inactive
Running in the background

Suspended 

Not running

In all but the "not running" state, the app is in memory and your memory leaks continue to accumulate.

Normally, when your user presses the home button, the app quickly transitions through inactive (still running in the foreground but no user interaction) to background (still running but another app has focus) and to suspended (in memory, but not getting any processor time. Your code isn't being called at all in this state.) You get a notification as the app moves to inactive and to the background state, before it goes to the suspended state.

You're expected to save whatever information you need to save in response to the applicationDidEnterBackground message.

Once the app is in the suspended state it can be terminated without any further warning. If you haven't saved your information to a file at that point, it's lost.

If the app stays in the suspended state and then gets woken up to one of the running states, all of your in-memory objects are still around, and your memory leaks are still accumulating.

As @blobbfuesch says, memory leaks cause your app to use up more and more of the device's RAM. If your memory use gets to be too much, the system will issue you one or more memory warnings, and if you don't free up enough memory, it will terminate you.

Because leaked memory is lost, you CAN'T free it up. Even small leaks add up. If the user keeps your active long enough, they accumulate and can cause your app to be terminated, which looks like a crash to the user.

If the app is terminated while in the suspended state, it gets unloaded from memory and has to be relaunched the next time it's run. in that case the previously leaked memory gets recovered, but then it starts leaking again.

Duncan C
  • 128,072
  • 22
  • 173
  • 272
  • Thanks for your answer. To the best of my knowledge, the small memory leaks I was referring to do not happen very often, and there is nothing i can do about them as they are bugs with Apple (WKWebview and UIAlertView). I am focusing on finding retain cycles at this point. Do you have any suggestions on finding retain cycles? I don't think they are shown in the Leaks Instrument – B Wu. Sep 12 '15 at 02:27
  • I'm pretty sure that the leaks instrument DOES flag retain cycles. Did you find the other leaks you are talking about in the simulator or on a device? Over the years I've seen several cases of memory leaks in system frameworks that only show up in the simulator. (Presumably caused by bugs in the simulated implementation of system frameworks.) – Duncan C Sep 12 '15 at 02:33
  • I found the other leaks on a device. When I try to use instruments on the simulator, it freezes/lags my Mac-mini a lot (I'm not sure why), but it doesn't lag my device nearly as bad – B Wu. Sep 12 '15 at 02:38
2
  1. If your app enters background, iOS will not change your apps memory but tell your app to release memory as new memory is needed by sending memory warnings. Most of Apples frameworks which you use in your app like UIKit and MapKit will also release memory in this case.

    All memory which was allocated by an app gets released when the app terminates. This includes retain cycles and memory leaks. Retain cycles are bad because they lead to a bigger memory consumption of your app. Apps running in background get terminated earlier, if they use more memory. If an app uses too much memory in the foreground, iOS will also terminate your app so you should always break retain cycles in your app by using weak references to prevent iOS from terminating your app too early.

  2. As all memory is deallocated when the app is terminated, retain cycles are resolved when the app quits. however if you start it again and the same code is executed, your app will create the same retain cycle again.
Palle
  • 11,511
  • 2
  • 40
  • 61
  • Thanks for your answer. How would you recommend finding retain cycles? I believe they are not shown in the Leaks Instrument. – B Wu. Sep 12 '15 at 02:04
  • 1. The first sentence is not true. An app in the background or suspended does not have any of its memory released. That only happens when the app process is fully terminated. – rmaddy Sep 12 '15 at 02:53
  • @rmaddy I observed that an app I made releasing more and more ressources in the background without being terminated. This process does not happen immediately but it will happen as more memory is needed by foreground applications. – Palle Sep 12 '15 at 03:54
  • In such cases it is probably certain code responding to memory warnings. Memory won't be released unless parts of the app are specifically written to do so. – rmaddy Sep 12 '15 at 03:56
  • @BWu. the leaks instrument should find retain cycles. Also you can check for leaks and retain cycles with the allocations instrument, repeating actions and using the "Mark Generation" tool after each repetition. If your app allocates but not releases memory over multiple generations, you may find a retain cycle or memory leak in your app. you can identify it by looking into the allocations of each generation. – Palle Sep 12 '15 at 04:11
  • Ok thanks for the suggestion. I'm using the allocations Instrument right now. The "Persistent Bytes" number for "All Heap and Anonymous VM" is significantly higher than the memory usage displayed by Xcode when running the app normally (shown under Debug navigator, 6th tab from right in Xcode left panel). I'm confused as to which number is the actual memory usage of the app? – B Wu. Sep 15 '15 at 20:37
  • Instruments displays the memory usage of your app while the memory usage shown by xcode shows the memory the system assigned to your app. So you should stick to the memory usage shown in Instruments. Anonymous VM also includes mapped files and memory allocated by malloc, which includes the backing store of Views and Layers. Your objects are found in the heap space so you should concentrate on it for finding retain cycles in your own code but you can also find hints for leaks in anonymous VM. – Palle Sep 15 '15 at 21:31