Zygote (Dalvik VM Launcher)
Zygote is a daemon whose only goal is to launch Apps. It is started by app_process. Here is the sequence used to start such special process
Lets see the init.rc file for the start of Zygote:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-servermain socket zygote stream root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd
When app_process launches Zygote, it creates the first 'Dalvik VM' and calls Zygote’s main () method. Once Zygote starts, it preloads all necessary Java classes and resources, starts System Server (system_server) as mentioned in the previous section and opens a socket '/dev/socket/zygote' to listen for requests for starting applications. System Server is a complete detached process from it’s parent.
How a New App is started?
Zygote receives a request to launch an App through '/dev/socket/zygote'. Zygote then trigger a fork() creating a clone of it self in another memory space. Now in the main Zygote all the initialization (Loading Dalvik and loading java classess) is done so this clone is effecient and fast. This makes the process of creating a VM and load resources pretty efficiently. Actually during the fork or clone call linux implements Copy on Write principle. So in reality no different memory is actually copied to the other memory space. The memory is shared and marked Copy on Write. When there is a write request to the memory only then the memory is copied. So this process is fast. Now can you see the benefit of using Linux kernel? We get all these implements by default.
Zygote will launch an application when it is requested. Like when we tap an application then it launches it on the onClick() event. At this point the application launcher contacts the Activity Manager. This is done through a Remote Procedure Call (RPC) mechanism called 'Binder' and calles startActivity(). On request for startActivity() the Activity Manager request the Zygote to fork itself and start the new VM as we discussed in the last section. This is done via startViaZygote() method which will open a connection to the Zygote socket (/dev/socket/zygote).
Apart from this activity manager is responsible for other tasks as intent broadcasting, launching the "Application Not Responding" message box.
To know more about the activity manager you can refer the code.
Now that we know briefly about the android internals we will talk about the important aspect of android. This is the Dalvik VM.
Dalvik is Android’s Java virtual machine. It allows Android to run the byte-code generated from Java-based apps and exports android components and jni hooks to native libraries and the rest of the native user-space. Dalvik was design for embedded systems. Those systems would have a small amount of RAM, slow CPU and run an OS without swap space and limited battery. As we discussed earlier Dalvik translates the 'class' files to 'dex' files and executes. These 'dex' files can be upto half the size of the corresponding jar files.
There is also difference in the internal structure of the dalvik vm from the JVM. JVM is a stakc based VM but Dalvik is a register based VM. Memory footprint in Dalvik is saved via few techniques as minimal repetition, implicit typing and implicit labeling. The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management. As of android 2.2 Dalvik also has a Just in Time compiler.