Hello guys,
I am very curious about something but I hope it is not a stupid question!
I mean, local variables get destroyed ((under director for instance) when switch scene (and of course when you exit the app) but what about global variables? I will think they stick around since the app can be resume later. Should I worry if do not cleaned up at app exit? Ie: memory leaks…
Just curious.
Mo [import]uid: 100814 topic_id: 33550 reply_id: 333550[/import]
I believe global variables are destroyed too, upon complete app shutdown (not sleep). The OS is effectively shutting down the entire application and everything with it. Global just means, as you know, that they can be accessed among modules.
If you need to save the “state” of an app without the user actually commanding that save, you can read about one method here:
http://www.coronalabs.com/blog/2012/07/17/using-system-events-to-save-app-state/
This would be useful to save a user’s progress automatically if the app is shut down from “sleep” state by the OS to free up memory for more recently accessed apps.
Brent [import]uid: 200026 topic_id: 33550 reply_id: 133327[/import]
Brent is of course correct – all of your apps memory based data is destroyed on an app terminate…
Regarding your question about cleaning up globals (suspend vs. terminate differences)… fortunately for all of us no, you don’t need to clean up on a terminate – or even on a suspend… (which is different than the issue brent mentioned regarding saving state on an actual terminate)…
If it’s an application terminate, the OS wipes the memory (ideally – any modern OS will) and then reallocates it for another app. You would need to save variables to bring your app back to the same state when it is re-launched (as Brent pointed out). But as a user, I like the capability to close an app instead of suspend it – I sometimes want to totally stop/reset my app.
If it’s an application suspend, the OS stores all of your variables (and more), and restores them on resume. Whether they are stored securely in non-volatile memory, or in regular memory (using modern access permissions controls) is up to the device/OS. But everything is “magically” restored just as it was (texture memory, register settings, stacks, CPU program counter/registers, open file handles, and all)… It’s a remarkable technical feat of the OS (both droid and iOS), but it’s the kind of thing that, if you think about it, capitalism/competition forces OS makers to do…
You could have 100 apps that when “running” use far more texture memory than the device has, far more main memory the device has… and they are all managed perfectly… And when they wake from suspend, they all push and shove each other around just right so the one in the foreground works, and the others are all saved ready to go, The competition to do this kind of feature didn’t start with just iOS and Android though… i recall the competition to do this kind of thing starting way back in the vax VMX days (probably even before that), and fortunately, capitalism/competition in computing has vigorously continued ever since.
[import]uid: 79933 topic_id: 33550 reply_id: 133329[/import]
@mpappas FANTASTIC explanation! Yes modern OS are amazing in term of resources management.
THANK YOU,
Mo [import]uid: 100814 topic_id: 33550 reply_id: 133331[/import]
I believe global variables are destroyed too, upon complete app shutdown (not sleep). The OS is effectively shutting down the entire application and everything with it. Global just means, as you know, that they can be accessed among modules.
If you need to save the “state” of an app without the user actually commanding that save, you can read about one method here:
http://www.coronalabs.com/blog/2012/07/17/using-system-events-to-save-app-state/
This would be useful to save a user’s progress automatically if the app is shut down from “sleep” state by the OS to free up memory for more recently accessed apps.
Brent [import]uid: 200026 topic_id: 33550 reply_id: 133327[/import]
Brent is of course correct – all of your apps memory based data is destroyed on an app terminate…
Regarding your question about cleaning up globals (suspend vs. terminate differences)… fortunately for all of us no, you don’t need to clean up on a terminate – or even on a suspend… (which is different than the issue brent mentioned regarding saving state on an actual terminate)…
If it’s an application terminate, the OS wipes the memory (ideally – any modern OS will) and then reallocates it for another app. You would need to save variables to bring your app back to the same state when it is re-launched (as Brent pointed out). But as a user, I like the capability to close an app instead of suspend it – I sometimes want to totally stop/reset my app.
If it’s an application suspend, the OS stores all of your variables (and more), and restores them on resume. Whether they are stored securely in non-volatile memory, or in regular memory (using modern access permissions controls) is up to the device/OS. But everything is “magically” restored just as it was (texture memory, register settings, stacks, CPU program counter/registers, open file handles, and all)… It’s a remarkable technical feat of the OS (both droid and iOS), but it’s the kind of thing that, if you think about it, capitalism/competition forces OS makers to do…
You could have 100 apps that when “running” use far more texture memory than the device has, far more main memory the device has… and they are all managed perfectly… And when they wake from suspend, they all push and shove each other around just right so the one in the foreground works, and the others are all saved ready to go, The competition to do this kind of feature didn’t start with just iOS and Android though… i recall the competition to do this kind of thing starting way back in the vax VMX days (probably even before that), and fortunately, capitalism/competition in computing has vigorously continued ever since.
[import]uid: 79933 topic_id: 33550 reply_id: 133329[/import]
@mpappas FANTASTIC explanation! Yes modern OS are amazing in term of resources management.
THANK YOU,
Mo [import]uid: 100814 topic_id: 33550 reply_id: 133331[/import]