Jump to content

  • Log In with Google      Sign In   
  • Create Account


android memory restrictions


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Wilhelm van Huyssteen   Members   -  Reputation: 953

Like
0Likes
Like

Posted 17 September 2012 - 09:40 AM

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.

Sponsor:

#2 SimonForsman   Crossbones+   -  Reputation: 6041

Like
3Likes
Like

Posted 17 September 2012 - 09:58 AM

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.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#3 Wilhelm van Huyssteen   Members   -  Reputation: 953

Like
0Likes
Like

Posted 17 September 2012 - 12:06 PM

Thnx!

#4 undead   Members   -  Reputation: 316

Like
0Likes
Like

Posted 19 September 2012 - 04:15 AM

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...

Posted Image




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS