Android Source Analysis (10) Dalvik Virtual machine creation process

I. INTRODUCTION Dalvik

The operation of the 1.java requires the JVM (which is covered in a large number of pages), as well as the Java language used in Android, and requires a VM. A VM launched for the lack of hardware resources, such as phone processors and memory, provides an environment for Android to run, called a DVM.

2.Dalvik virtual machines allow multiple instance to exist. Virtually every app in Android is running in its own VM instance (sandbox). Each VM instance is a separate process in Linux, so it can be considered the same concept. Running in their own DVM process, different apps don't interfere with each other and do not cause all app processes to crash because of a DVM crash. In this case, theAndroid DVM process is similar to the process concept of the Linux process, the application.

3. Differences from the JVM:

　　　　1. Schema-based differences. The JVM is a stack-based architecture, and the DVM is based on the register schema.

2.JVM runs a bytecode file, and the DVM runs its own defined Dex file format.

　　　　　　JVM Compilation Process Java->class->jar
DVM Compilation Process Java->class->dex

Summarize the differences between DVM and JVM:　　　　　

Difference One: The DVM executes a. dex format file The JVM executes a. class file After the Android program compiles the. class file, the Dex tool processes the. class file into a. dex file, and then packages the resource file and the. dex file into an. apk file. APK is the meaning of Android package. The JVM executes a. class file.

Difference Two: The DVM is a register-based virtual machine and the JVM executes the virtual machine based on the virtual stack. Register access speed is much faster than the stack, DVM can be based on hardware to achieve maximum optimization, more suitable for mobile devices.

The difference is that there is a lot of redundancy in the. class file, and the Dex tool removes redundant information and consolidates all the. class files into a. dex file. Reduced I/O operations and improved class lookup speed

　　　　

A picture of what the DVM does primarily:

　　　　

Ref: 47682797

Two. Dalvik startup process

　　

//AndroidRuntime.cppintANDROIDRUNTIME::STARTVM (javavm** PJAVAVM, jnienv** penv,BOOLzygote)    {Javavminitargs Initargs; CharPropbuf[property_value_max]; Charstacktracefilebuf[sizeof("-xstacktracefile:")-1+Property_value_max]; Charjnioptsbuf[sizeof("-xjniopts:")-1+Property_value_max]; Charheapstartsizeoptsbuf[sizeof("-xms")-1+Property_value_max]; Charheapsizeoptsbuf[sizeof("-xmx")-1+Property_value_max]; Charheapgrowthlimitoptsbuf[sizeof("-xx:heapgrowthlimit=")-1+Property_value_max]; Charheapminfreeoptsbuf[sizeof("-xx:heapminfree=")-1+Property_value_max]; Charheapmaxfreeoptsbuf[sizeof("-xx:heapmaxfree=")-1+Property_value_max]; Charusejitoptsbuf[sizeof("-xusejit:")-1+Property_value_max]; Charjitmaxsizeoptsbuf[sizeof("-xjitmaxsize:")-1+Property_value_max]; Charjitinitialsizeoptsbuf[sizeof("-xjitinitialsize:")-1+Property_value_max]; Charjitthresholdoptsbuf[sizeof("-xjitthreshold:")-1+Property_value_max]; Charusejitprofilesoptsbuf[sizeof("-xjitsaveprofilinginfo:")-1+Property_value_max]; Charjitprithreadweightoptbuf[sizeof("-xjitprithreadweight:")-1+Property_value_max]; Charjittransitionweightoptbuf[sizeof("-xjittransitionweight:")-1+Property_value_max]; Chargctypeoptsbuf[sizeof("-XGC:")-1+Property_value_max]; Charbackgroundgcoptsbuf[sizeof("-xx:backgroundgc=")-1+Property_value_max]; Charheaptargetutilizationoptsbuf[sizeof("-xx:heaptargetutilization=")-1+Property_value_max]; Charcacheprunebuf[sizeof("-xzygote-max-boot-retry=")-1+Property_value_max]; Chardex2oatxmsimageflagsbuf[sizeof("-xms")-1+Property_value_max]; Chardex2oatxmximageflagsbuf[sizeof("-xmx")-1+Property_value_max]; Chardex2oatxmsflagsbuf[sizeof("-xms")-1+Property_value_max]; Chardex2oatxmxflagsbuf[sizeof("-xmx")-1+Property_value_max]; Chardex2oatcompilerfilterbuf[sizeof("--compiler-filter=")-1+Property_value_max]; Chardex2oatimagecompilerfilterbuf[sizeof("--compiler-filter=")-1+Property_value_max]; Chardex2oatthreadsbuf[sizeof("-j")-1+Property_value_max]; Chardex2oatthreadsimagebuf[sizeof("-j")-1+Property_value_max]; CharDex2oat_isa_variant_key[property_key_max]; Chardex2oat_isa_variant[sizeof("--instruction-set-variant=") -1+Property_value_max]; CharDex2oat_isa_features_key[property_key_max]; Chardex2oat_isa_features[sizeof("--instruction-set-features=") -1+Property_value_max]; CharDex2oatflagsbuf[property_value_max]; CharDex2oatimageflagsbuf[property_value_max]; CharExtraoptsbuf[property_value_max]; CharVolddecryptbuf[property_value_max]; ...        /** Initialize the VM.     * * The javavm* is essentially per-process, and the jnienv* is per-thread.     * If This call succeeds, the VMs are ready, and we can start issuing * JNI calls. */    if(JNI_CREATEJAVAVM (PJAVAVM, penv, &initargs) <0) {Aloge ("JNI_CREATEJAVAVM failed\n"); return-1; }    return 0;}voidAndroidruntime::start (Const Char* ClassName,Constvector<string8>& options,BOOLzygote) {        /*start the virtual machine*/jniinvocation jni_invocation; Jni_invocation.    Init (NULL); JNIEnv*env; if(STARTVM (&AMP;MJAVAVM, &env, zygote)! =0) {        return;    } onvmcreated (env); /** Register Android functions. */    if(Startreg (ENV) <0) {Aloge ("Unable to register all Android natives\n"); return; }}

Dalvik the startup process of the virtual machine in the zygote process, this startup process mainly completes the following four things:
1. A Dalvik virtual machine instance was created;
2. The Java core classes and their JNI methods are loaded;
3. A JNI environment is set up for the main thread;
4. Registered the JNI method of the Android core class.

Zygote Start Dalvik Effect:

1. The zygote process prepares an Dalvik virtual machine instance for the Android system, and the zygote process can then copy its own Dalvik virtual machine instance into the newly created Android application process when the Android application process is created. This speeds up the process of booting the Android application process.

The 2.Java core class and the Android core class (in the Dex file), and their JNI methods (in the so file), are read in memory-mapped ways, so the zygote process, when creating the Android application process, In addition to replicating your own Dalvik virtual machine instances to the newly created Android application process, you can also share the Java core classes and Android core classes with the newly created Android application process, along with their JNI methods, thus saving memory consumption.

The 3.Zygote process has sacrificed its boot speed in order to speed up the process of Android applications, because it needs to load a large number of Java core classes and register a large number of the Android core class JNI methods. Dalvik virtual machines also need to be validated and optimized when loading Java core classes, which are often time-consuming. Because the zygote process is initiated by the INIT process, which means that the zygote process starts at boot time, the sacrifice of the zygote process is relatively large. But after all, when we play on the phone, it is seldom shut down, that is, rarely turned on, so the boot speed of sacrificing zygote process is worthwhile, in exchange for a quick start of Android applications.

Android Source Analysis (10) Dalvik Virtual machine creation process