Android Understanding Heap Sizes

Android Understanding Heap Sizes

When you set the VM budget on your emulator/device, what you are doing is telling the heap the maximum size it is allowed to be. At runtime, the heap grows dynamically in size as the Dalvik VM requests system memory from the operating system. The Dalvik VM typically starts by allocating a relatively small heap. Then after each GC run it checks to see how much free heap memory there is. If the ratio of free heap to total heap is too small, the Dalvik VM will then add more memory to the heap (up to the maximum configured heap size).

That being said, the reason why you are not seeing "24 mb" on your DDMS screen is because the heap hasn't grown to its maximum size. This allows Android to make good use of the already small amount of memory that is available on handheld devices.

As for why your application is crashing on the emulator and not your phone, that does seem odd (are you sure the numbers are correct?). You should keep in mind, however, that memory is managed dynamically and that total memory utilization is determined based on a number of external factors (the speed/frequency at which garbage collection is performed, etc.).

Finally, for the reasons I mentioned above, it would be difficult to say for sure how well your application manages memory based on the single line of information you provided above. We'd really need to see some of your code. OutOfMemoryErrors are definitely worth worrying about, however, so I'd definitely look into your application's memory usage. One thing you might consider is to sample your bitmap images at runtime with calls to inSampleSize using the BitmapFactory class. This can help reduce the amount of memory required to load your drawable bitmaps. Either that or you could reduce the resolution of your drawables (although 20 kb each sounds fine to me).

Android heap size on different phones/devices and OS versions

Does anyone know if the heap size on Android phones is a constant value according to what is set in the OS version or if this is a setting which the phone producers can decide on?

Technically, it is a setting which the phone producers can decide on. Android is open source. I do not recall the Compatibility Definition Document spelling out heap size requirements, though I haven't looked recently.

Is the heap size proportional to the amount of RAM on the phone?

No, it tends to be based more on screen resolution, as higher-resolution screens tend to want to manipulate larger bitmaps, so Google makes heap size recommendations that, hopefully, device manufacturers will abide by.

I've only found articles where people say that the heap size of an application is 16M.

Searching StackOverflow on [android] "heap size" turns up this answer.

How to increase heap size of an android application?

You can use android:largeHeap="true" to request a larger heap size, but this will not work on any pre Honeycomb devices. On pre 2.3 devices, you can use the VMRuntime class, but this will not work on Gingerbread and above.

The only way to have as large a limit as possible is to do memory intensive tasks via the NDK, as the NDK does not impose memory limits like the SDK.

Alternatively, you could only load the part of the model that is currently in view, and load the rest as you need it, while removing the unused parts from memory. However, this may not be possible, depending on your app.

What does heap mean in Android?

The heap is what the memory manager uses to keep track of the memory. It consists of one or more unused memory areas, and all blocks of used memory.

When the heap gets too low, it means that there is not enough free memory as the application is trying to use more memory than there is available. There can be several specific reasons for this, for example:

  • Your application is using too much memory.

  • Other applications are using much memory, leaving less for your application.

  • Your application is allocating large blocks of memory, but the free memory is fragmented into smaller blocks so it can't be used.

Try to reduce the memory usage, and make sure that you release memory properly that you are not using any more.

Detect application heap size in Android

There are two ways to think about your phrase "application heap size available":

  1. How much heap can my app use before a hard error is triggered? And

  2. How much heap should my app use, given the constraints of the Android OS version and hardware of the user's device?

There is a different method for determining each of the above.

For item 1 above: maxMemory()

which can be invoked (e.g., in your main activity's onCreate() method) as follows:

Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
Log.v("onCreate", "maxMemory:" + Long.toString(maxMemory));

This method tells you how many total bytes of heap your app is allowed to use.

For item 2 above: getMemoryClass()

which can be invoked as follows:

ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
int memoryClass = am.getMemoryClass();
Log.v("onCreate", "memoryClass:" + Integer.toString(memoryClass));

This method tells you approximately how many megabytes of heap your app should use if it wants to be properly respectful of the limits of the present device, and of the rights of other apps to run without being repeatedly forced into the onStop() / onResume() cycle as they are rudely flushed out of memory while your elephantine app takes a bath in the Android jacuzzi.

This distinction is not clearly documented, so far as I know, but I have tested this hypothesis on five different Android devices (see below) and have confirmed to my own satisfaction that this is a correct interpretation.

For a stock version of Android, maxMemory() will typically return about the same number of megabytes as are indicated in getMemoryClass() (i.e., approximately a million times the latter value).

The only situation (of which I am aware) for which the two methods can diverge is on a rooted device running an Android version such as CyanogenMod, which allows the user to manually select how large a heap size should be allowed for each app. In CM, for example, this option appears under "CyanogenMod settings" / "Performance" / "VM heap size".

NOTE: BE AWARE THAT SETTING THIS VALUE MANUALLY CAN MESS UP YOUR SYSTEM, ESPECIALLY if you select a smaller value than is normal for your device.

Here are my test results showing the values returned by maxMemory() and getMemoryClass() for four different devices running CyanogenMod, using two different (manually-set) heap values for each:

  • G1:

    • With VM Heap Size set to 16MB:

      • maxMemory: 16777216
      • getMemoryClass: 16
    • With VM Heap Size set to 24MB:

      • maxMemory: 25165824
      • getMemoryClass: 16
  • Moto Droid:

    • With VM Heap Size set to 24MB:

      • maxMemory: 25165824
      • getMemoryClass: 24
    • With VM Heap Size set to 16MB:

      • maxMemory: 16777216
      • getMemoryClass: 24
  • Nexus One:

    • With VM Heap size set to 32MB:

      • maxMemory: 33554432
      • getMemoryClass: 32
    • With VM Heap size set to 24MB:

      • maxMemory: 25165824
      • getMemoryClass: 32
  • Viewsonic GTab:

    • With VM Heap Size set to 32:

      • maxMemory: 33554432
      • getMemoryClass: 32
    • With VM Heap Size set to 64:

      • maxMemory: 67108864
      • getMemoryClass: 32

In addition to the above, I tested on a Novo7 Paladin tablet running Ice Cream Sandwich.
This was essentially a stock version of ICS, except that I've rooted the tablet through a simple process that does not replace the entire OS, and in particular does not provide an interface that would allow the heap size to be manually adjusted.

For that device, here are the results:

  • Novo7

    • maxMemory: 62914560
    • getMemoryClass: 60

Also (per Kishore in a comment below):

  • HTC One X

    • maxMemory: 67108864
    • getMemoryClass: 64

And (per akauppi's comment):

  • Samsung Galaxy Core Plus

    • maxMemory: (Not specified in comment)
    • getMemoryClass: 48
    • largeMemoryClass: 128

Per a comment from cmcromance:

  • Galaxy S3 (Jelly Bean) large heap

    • maxMemory: 268435456
    • getMemoryClass: 64

And (per tencent's comments):

  • LG Nexus 5 (4.4.3) normal

    • maxMemory: 201326592
    • getMemoryClass: 192
  • LG Nexus 5 (4.4.3) large heap

    • maxMemory: 536870912
    • getMemoryClass: 192
  • Galaxy Nexus (4.3) normal

    • maxMemory: 100663296
    • getMemoryClass: 96
  • Galaxy Nexus (4.3) large heap

    • maxMemory: 268435456
    • getMemoryClass: 96
  • Galaxy S4 Play Store Edition (4.4.2) normal

    • maxMemory: 201326592
    • getMemoryClass: 192
  • Galaxy S4 Play Store Edition (4.4.2) large heap

    • maxMemory: 536870912
    • getMemoryClass: 192

Other Devices

  • Huawei Nexus 6P (6.0.1) normal

    • maxMemory: 201326592
    • getMemoryClass: 192

I haven't tested these two methods using the special android:largeHeap="true" manifest option available since Honeycomb, but thanks to cmcromance and tencent we do have some sample largeHeap values, as reported above.

My expectation (which seems to be supported by the largeHeap numbers above) would be that this option would have an effect similar to setting the heap manually via a rooted OS - i.e., it would raise the value of maxMemory() while leaving getMemoryClass() alone. There is another method, getLargeMemoryClass(), that indicates how much memory is allowable for an app using the largeHeap setting. The documentation for getLargeMemoryClass() states, "most applications should not need this amount of memory, and should instead stay with the getMemoryClass() limit."

If I've guessed correctly, then using that option would have the same benefits (and perils) as would using the space made available by a user who has upped the heap via a rooted OS (i.e., if your app uses the additional memory, it probably will not play as nicely with whatever other apps the user is running at the same time).

Note that the memory class apparently need not be a multiple of 8MB.

We can see from the above that the getMemoryClass() result is unchanging for a given device/OS configuration, while the maxMemory() value changes when the heap is set differently by the user.

My own practical experience is that on the G1 (which has a memory class of 16), if I manually select 24MB as the heap size, I can run without erroring even when my memory usage is allowed to drift up toward 20MB (presumably it could go as high as 24MB, although I haven't tried this). But other similarly large-ish apps may get flushed from memory as a result of my own app's pigginess. And, conversely, my app may get flushed from memory if these other high-maintenance apps are brought to the foreground by the user.

So, you cannot go over the amount of memory specified by maxMemory(). And, you should try to stay within the limits specified by getMemoryClass(). One way to do that, if all else fails, might be to limit functionality for such devices in a way that conserves memory.

Finally, if you do plan to go over the number of megabytes specified in getMemoryClass(), my advice would be to work long and hard on the saving and restoring of your app's state, so that the user's experience is virtually uninterrupted if an onStop() / onResume() cycle occurs.

In my case, for reasons of performance I'm limiting my app to devices running 2.2 and above, and that means that almost all devices running my app will have a memoryClass of 24 or higher. So I can design to occupy up to 20MB of heap and feel pretty confident that my app will play nice with the other apps the user may be running at the same time.

But there will always be a few rooted users who have loaded a 2.2 or above version of Android onto an older device (e.g., a G1). When you encounter such a configuration, ideally, you ought to pare down your memory use, even if maxMemory() is telling you that you can go much higher than the 16MB that getMemoryClass() is telling you that you should be targeting. And if you cannot reliably ensure that your app will live within that budget, then at least make sure that onStop() / onResume() works seamlessly.

getMemoryClass(), as indicated by Diane Hackborn (hackbod) above, is only available back to API level 5 (Android 2.0), and so, as she advises, you can assume that the physical hardware of any device running an earlier version of the OS is designed to optimally support apps occupying a heap space of no more than 16MB.

By contrast, maxMemory(), according to the documentation, is available all the way back to API level 1. maxMemory(), on a pre-2.0 version, will probably return a 16MB value, but I do see that in my (much later) CyanogenMod versions the user can select a heap value as low as 12MB, which would presumably result in a lower heap limit, and so I would suggest that you continue to test the maxMemory() value, even for versions of the OS prior to 2.0. You might even have to refuse to run in the unlikely event that this value is set even lower than 16MB, if you need to have more than maxMemory() indicates is allowed.

Is there a minimal heap size for Android versions?

ok, i've finally found the answer (thanks to this post) :

the bare minimal for all versions of android (including 5) , is 16MB.

the requirements for each of the android versions can be read about here:

http://source.android.com/compatibility/downloads.html

you can read about them by opening the CDD files and searching for "Runtime Compatibility" (or "Virtual Machine Compatibility" for old versions). also, you can find the minimal RAM requirement by searching for "Memory and Storage", but i think it's only the requirement for the system itself.

so, for example, on 4.0.3 - 5 the minimal heap size is:

  • 16MB: small/normal with ldpi/mdpi, or large with ldpi
  • 32MB: small/normal with tvhdpi/hdpi, or large with mdpi
  • 64MB: small/normal with xhdpi, or large with tvdpi/hdpi, or xlarge with mdpi.
  • 96MB: small/normal with 400dpi, or xlarge with tvhdpi/hdpi
  • 128MB: small/normal with xxhdpi, or large with xhdpi
  • 192MB: small/normal with 560dpi, or large with 400dpi, or xlarge with xhdpi .
  • 256MB: small/normal with xxxhdpi, or large with xxhdpi
  • 288MB: xlarge with 400dpi
  • 384MB: large with 560dpi, or xlarge with xxhdpi
  • 512MB: large with xxxhdpi
  • 576MB: xlarge with 560dpi
  • 768MB: xlarge with xxxhdpi

I can't find the minimal heap size for versions 3.x but it's probably the same as 4.0.3 .

for 2.1 - 2.3 , the minimal heap size is :

Device implementations with screens classified as medium- or
low-density MUST configure Dalvik to allocate at least 16MB of memory
to each application. Device implementations with screens classified as
high-density or extra-high-density MUST configure Dalvik to allocate
at least 24MB of memory to each application. Note that device
implementations MAY allocate more memory than these figures.

meaning:

  • medium screen or ldpi - 16MB
  • hdpi or xhdpi - 24MB

i can't find the minimal heap size for version 1.6 , but it's probably the same as 2.1 .

also, i can't find out what should the large-heap flag do for each of the android versions (since 3.0) .

Android Studio - How to increase Allocated Heap Size

I looked at my Environment Variables and had a System Variable called _JAVA_OPTIONS with the value -Xms256m -Xmx512m, after changing this to -Xms256m -Xmx1024m the max heap size increased accordingly.



Related Topics



Leave a reply



Submit