Android Open Handset Developers Community

Hi guys,
I believe it could be usefull to link in this forum section some of the most interesting speechs from Google I/O 2008, in order to comment
them also going into the details of specific arguments addressed during the video.

Looking forward to listening you, bye.

Dalvik — the virtual machine with the unusual name — runs your code on Android. Join us to learn about the motivation for its design and get some details about how it works. You'll also walk away with a few tips for how to write code that works well with the platform. Be prepared for a deep dive into technical details.

In the attached screenshot you can look some figures concerning the memory arrangement of Dalvik.

As clarified during the Q&A session, the Android platform expects to have (at least) 64 MB RAM available by design choice: if the HW platform offers more, it means you have more space for user applications.

Also the most important (IMHO) feature of Dalvink was remarked: each application runs on separate address space and this is a key aspect for the security model of the Android platform: if a bad written process have a problem, it does not affect the rest of the system and all the other applications keep running safe.

Some words were also spent concerning the RAM available after the system's boot and the activation of high-level services: 20 MB can look not too much, but the speaker remarked that it should be also considered that a very large library (20 MB) is available to perform all the general tasks needed when the device acts as a phone (call dialing, SMS, contacts, etc.).

For sure, this information will be very useful to all the developers!

The Dalvik Virtual Machine Internals presentation was very intersting also for having details on the structure of the DEX files.
On this respect, one slide reports how a DEX file maps to the equivalent JAR: it was claimed that the new DEX format is more space efficient with rescpet to JAR.

Moreover, it was revealed that at install time the system verify the integrity and the conformity of the DEX file, for the sake of security, and then some optimization tasks are also performed.

During the Q&A session, it was asked if the back conversion from DEX to Java is expected to be harder than the same one from CLASS files. The answer was that the new format was not designed with this goal in mind, also because the aims for Andorid are to have first of all well designed and useful open source applications. related to this point, it was also clarified that the java language was choosen due to the large open source community that support this language. As far as the chanches to have DEX compilers for other languages in the future, the answer was: "eventually, it can happen" .

bye

From the presentation it is also possible to achieve information on the topic you see in the post subject.
It was mentione that if your application spend time doing nothing, it consumes CPU time (and consequently milliwatt of energy power...) without any advantage.

Suggestions for optimizing power consumption are:

- design your application for spending most of the time sleeping but reacting quickly and decisevily to user and network inputs
- avoid unnecessary memory allocations (expecially for short-lived objects) because they require CPU time and trigger garbage collection actions
- avoid loop cycles relying on object creation and iterators

With respect the third advice, it was clarified in the Q&A session that in this version of the Andoird platform all the memory allocations are done on the heap, not on the stack: keep in mind !