How to measure class memory size on Dalvik JVM?

Question

After reading the 'Managing You App's Memory' article, I started investigating memory implications by writing "clean code". With this i mean e.g small classes that have one responsibility, programming towards Interfaces, methods that do one thing etc.

However Im not sure how to get actual readings of how much space a binary representation of a class or interface actually will take in the Dalvik JVM. I am currently looking at the byte size of the compiled classes in the intermediates folder. Here I can see that instead of having one large method doing 3 things, 3 different methods actually adds about 100 bytes. Question: Is this measure valid?

I'm guessing that some optimization is happening either when the dex is created, or by proguard when building a release, or by the classloader, however Im fairly new to this subject.

Any good links to literature explaining the Dalvik memory model is much appreciated

Answer 1

Every class has a fixed amount of overhead for the class definition, plus a few bytes for every method and field, and some storage for the static fields. You can see the structure in the Dalvik sources (struct ClassObject).

You do pay a small cost for every class, field, and method, so if you wrote your entire program in a single gigantic method you would save some space. This is not a good idea. (Some code optimizer / obfuscator programs will do something like this, generating large complex switch statements.)

The overhead is difficult for the app to measure because, in Dalvik, much of the overhead lives on the native heap or in the "linear alloc" area (a limit to which Facebook had to hack around). The size of the intermediate .class file is not at all representative. The size of the .dex file isn't terribly useful either because much of that lives in memory-mapped RAM, which is less of a burden to the system than "dirty" RAM (see hackbod's post about memory usage).

The best advice I can offer is to write code that is easy to maintain and not worry overmuch about the details. You could run into trouble if you put every line of code in its own class, but if you go to that sort of extreme the code becomes difficult to maintain anyway.

Most of the memory cost in modern apps is related to graphics, because displays keep getting larger and denser, not because of coding style or quantity. The hack that Facebook did to get their very large app working was to increase a VM buffer size from 5MB to 8MB on gingerbread devices, which is tiny compared to the rest of the app's demands.