3 replies to this topic

[Wilhelm van Huyssteen]

Hi

Im new to android development. As far as I understand theres a set limit to the amount of system memory that an android app can use. But what about video memory? Does it depend on the device? or is all memory shared and the total video+system memory must not exeed the limit.

[SimonForsman]

Hi

Im new to android development. As far as I understand theres a set limit to the amount of system memory that an android app can use. But what about video memory? Does it depend on the device? or is all memory shared and the total video+system memory must not exeed the limit.

All memory is normally shared on embedded devices (allthough it doesn't have to be and Android can run on a normal PC aswell), each JVM instance can use 16MB RAM in the older versions (pre 3.0), newer Android versions allow apps to enable large-heap and use up to 48MB (device dependant, you could get less than 48MB on some devices).

memory allocated through the native interface, OpenGL, or native bitmaps does not count towards this limit, (These are only limited by the amount of available memory on the device (Which can be quite alot more, 2GB on the Galaxy S3 for example), you will however usually load the data into the JVM heap before pushing it to nativly allocated RAM so if you are loading large amounts of data you might have to manually trigger the GC to clean things up during the loading process), native bitmaps are cleaned up automatically when the bitmap object gets garbage collected, OpenGL and nativly allocated memory has to be managed manually (glDeleteTextures, etc) (it is cleaned up when the app closes, but for games you might swap textures between levels etc and it is a really good idea to clean out the ones you're no longer going to use)

Edited by SimonForsman, 17 September 2012 - 10:00 AM.

[Wilhelm van Huyssteen]

Thnx!

[undead]

Just a few additions. Certain apps like live wallpapers can have TWO instances running at the same time. This happens when you have your live wallpaper set and user decides to change settings. In order to do it he has to go into live wallpapers menu and select the wallpaper.
When he does it another instance of your app is created when the preview starts, effectively creating a second instances before user can press "settings".
This happens because the "engine-generator" in a live wallpaper is unique (technically it is the wallpaper service) so multiple instances are generated sharing the same heap space.

In situations like that if you have a decent screen res and you are loading multiple images you can have problems (a single 1200x800*32-bit image is 3.5-4mb). In such cases you might want to give a try to Bitmap.recycle() to quickly free heap space before loading another image...