Android Virtual Machine detailed

The virtual machine used before android5.0 is the Dalvik virtual machine, which is optimized on the basis of the JVM. After android5.0, Android adopted a new virtual machine art, this article mainly compares the Dalvik, the JVM, the art.

A. Dalvik Virtual machine

1. The concept

The Dalvik virtual machine is a virtual machine for Android, and is the basis for running Java programs in Android. Its instruction set is based on register architecture, and executes its special file format--dex bytecode to accomplish object lifecycle management, stack management, thread management, security exception management, garbage collection and other important functions. Its core content is the implementation of the Library (libdvm.so), largely by the C language implementation. Relies on a subset of the functionality of the Linux kernel-threading mechanism, memory management mechanism, efficient use of memory and high performance on a low-speed CPU. Each Android application has a separate Dalvik virtual machine instance at the bottom, and its code is executed with the virtual machine interpretation.

There is a special virtual machine process zygote, and he is the incubator for virtual machine instances. It will be generated when the system is started, it will complete the initialization of the virtual machine, library loading, prefabricated class libraries and initialization operations. If the system needs a new virtual machine instance, it will quickly replicate itself to provide the system with the fastest suit. For some read-only system libraries, all virtual machine instances share an area of memory with Zygote.

2. Compared to the JVM

1. The most notable difference between a Dalvik virtual machine and a Java virtual machine is that they have different class file formats and instruction sets respectively. The Dalvik virtual machine uses the Dalvik executable format class file, and the Java Virtual machine uses class files in class format. A Dex file can contain several classes, while a class file includes only one. Because a Dex file can contain several classes, it can save space by saving duplicate strings and other constant numbers in each class, which is ideal for mobile systems with limited memory and processor speed. In general, an uncompressed Dex file containing the same class is slightly less than a compressed jar file.

2. The instructions used by the Dalvik virtual machine are based on registers, while the instruction set used by the Java virtual Machines is based on the stack. In fact, the contention between registers and stack-based instruction sets, such as the contention between reduced instruction sets (RISC) and complex instruction sets (CISC), is not conclusive as to who is superior or inferior.

3. Collect multiple class files into the same Dex file to save space;

4. Load DEX files using read-only memory mapping so that you can share Dex files and save program loading time;

5. Adjust the byte sequence (byte order) and Word alignment (word alignment) in advance, make them more suitable for the local machine, in order to improve the speed of instruction execution;

6. As far as possible in advance byte code verification (bytecode verification), improve the loading speed of the program;

7. The optimizations needed to rewrite bytecode are done in advance.

8. Different memory management

The memory of the Dalvik virtual machine can be roughly divided into Java Object Heap, Bitmap memory, and native Heap three kinds.

Java object Heap is used to allocate Java objects, which means that the objects we have in code new are located on the Java object heap. When the Dalvik virtual machine is started, the-XMS and-XMX options are available to specify the minimum and maximum values for Java Object heap. To prevent the Dalvik virtual machine from adjusting the size of the Java Object Heap while it is running, we can set its minimum and maximum values to equal by the-XMS and-XMX options.

The minimum and maximum defaults for Java object heap are 2M and 16M, but when the phone is shipped out, the manufacturer adjusts it according to the configuration of the phone, for example, G1, Droid, Nexus One, and Xoom the Java object heap are the maximum value of 16M , 24M, 32M, and 48M. We can get the maximum value of the Java Object Heap of the Dalvik virtual machine by Activitymanager the member function Getmemoryclass of the class.

The maximum value of this Java Object heap is the maximum memory that we would normally call the Android application process to use. It must be noted here that the maximum memory that the Android application process can use is the heap that can be used to allocate Java object.

Bitmap Memory is also known as external Memory, which is used to process images. Before Honeycomb, Bitmap memory was allocated in native heap, but this part of memory is also counted in the Java Object Heap, that is, the memory consumed by Bitmap and Java The memory used by object cannot be combined to exceed the maximum value of the Java object heap. That's why we throw a OutOfMemoryError exception when we call the Bitmapfactory-related interface to handle a large image:

In honeycomb and later versions, Bitmap memory is allocated directly in the Java Object heap, so that it can be directly accepted for GC management.

In addition, in honeycomb and later versions, we can add an android with a value equal to "true" in the Androidmanifest.xml application tag: Largeheap property to notify the Dalvik virtual machine application that a larger Java Object Heap is required. In fact, on a memory-constrained phone, even if we set the Android:largeheap property of an application to "true", it does not increase the size of the Java object heap available to it, even though the Java object can be augmented by this property The size of the heap should not be used in general. To improve the overall experience of the system, we need to focus on reducing the memory requirements of the application, rather than increasing the size of the application's Java Object heap, after all, the total amount of memory available to the system is fixed, and one application is much more, meaning that other applications are less used.

9. JNI and NDK

JNI is the Java call C/s + + layer, both JVM and Dalvik have this capability. The difference is that in order to make it easier for developers to develop applications using the C + + language, the Android official provides NDK. With NDK, we can use the JNI mechanism to call the C + + function in a Java function. However, the official Android is not advocating the use of NDK to develop applications, which from its support for NDK far less than the SDK support can be seen.

Two. Art Virtual machine

1. The concept

2. Compare with Dalvik

Dalvik is the implementation of the Compile + run, installation faster, open the application is relatively slow, the use of space small art is installed when the compile, the implementation of the time directly can be run, installation slow, open application fast, occupy a large space using a metaphor is, riding a bicycle Dalvik It is a bicycle that has been folded up, and a bicycle must be assembled to ride it every time. Art is a bicycle that has already been assembled and can be taken off the bus every time you ride it.

To understand the difference between art and Dalvik, first of all to clear the composition of apk file, APK package In addition to a lot of resources, There is also an important file Classes.dex, which is packaged in Java bytecode optimization, in Dalvik, each time the application is opened, Dalvik reads the Classes.dex and interprets the execution (the actual case, it may be converted to the Odex file, which is ignored), and in the art environment, when When you install APK, this Classes.dex file will be converted to the cost of machine code-suffix of the oat file, later open the application directly read the oat file execution.

A less-than-appropriate example: the current International Paper language is English (equivalent to Java byte code), and you as a Chinese only Chinese (equivalent to the ARM architecture of the Android phone), while the other Japanese only Japanese (equivalent to the x86 architecture of the Android phone), Now give you a bunch of English information, Dalvik's approach is to file the data, wait for the information you need to find out from the bookshelf to find the necessary parts, and then translated into Chinese reading, and art's practice is to first of all the data translation into Chinese alone, and so you need to directly find Chinese information on it.

So, the advantage of art is that it greatly improves the efficiency of execution, but it is also obvious that the installation takes longer and consumes more disk space.

Art has an improved GC (garbage collection) mechanism: Fewer pauses for GC, concurrent processing at GC, less time to collector, less memory, and less background memory footprint.

First, the process of Dalvik GC is introduced. There are four main processes:

1 when the GC is triggered, it will look for all active objects, at which point the entire program hangs with all the threads inside the virtual machine, so that the object is found in a smaller stack. It should be noted that the Recycle action is executed concurrently with the application (not concurrency).

2) GC to mark objects that meet the criteria

3) GC to recycle tagged objects

4 Restore all threads to the execution site continue to run

The advantage of Dalvik is that the GC is bound to be pretty fast when the pause is done. But if the GC is frequent and the memory crunch is bound to cause the UI to get stuck, drop the frame. Operation is not smooth, etc.

Later on, art improved the GC (and also wanted to contribute to UI fluency, of course, for UI fluency, more than 5.0 of new parallel UI threads), and the main improvement point was to change its non concurrency process into partial concurrency. And then there's the reallocation of memory management

When the art GC occurs:

1 GC will lock the Java heap, scan and mark

2) Mark complete release of the Java heap lock, and suspend all threads

3) GC to recycle tagged objects

4 Restore all threads to the execution site continue to run

5) Repeat 2-4 until the end

It can be seen that the whole process is partially concurrent to shorten the time. According to official test data, GC is twice times more efficient.

Three. More information

1.Dalvik Virtual Machine Brief introduction and Learning Plan:

http://blog.csdn.net/luoshengyang/article/details/8852432