ART and Dalvik
Dalvik virtual machine – before Android5.0
1. The Virtual machine in Android is Dalvik/ART 2. Each application should have a separate Dalvik VM instance. 3. The Dalvik VIRTUAL machine is actually a Java virtual machine, but instead of executing a class file, it executes a dex file. 4. The Jvm’s instruction set is stack-based. The instruction set of Dalvik is basic register
Stack-based virtual machine-JVM
For stack-based virtual machines, each run time thread has a separate stack.
The stack records the history of method calls, and each time a method call is made, an additional stack frame is added to the stack.
The top stack frame is called the current stack frame and represents the currently executing method.
A stack-based VM performs all operations on the operand stack.
The execution process of what see JVMS – deep parsing
Register-based virtual machine – Dalvik
Register: High – speed memory in the CPU.
Register virtual machine: in effect, the local variable table on the stack frame is combined with the operand stack, eliminating the frequent in and out of the operand stack.
There is no operand stack in a regist-based virtual machine, but there are many virtual registers. Just like the operand stack, these registers are stored in the runtime stack, which is essentially an array. Similar to the JVM, in the Dalvik VM each thread has its own PC and call stack, and the activity of method calls is recorded in frames on the call stack.
I’m just going to do it directly
The first step
The second step
Advantages: significantly fewer instructions compared to the JVM, less data movement (no more frequent pushes and exits in the operand stack)
ART virtual machine – after Android5.0
The ART vm is an updated version of the Dalvik vm. After Android5.0, the default is the ART vm.
The Dalvik VM executes dex bytecode and interprets the execution. Starting with Android version 2.2, JIT compilation is supported Just In Time. Select hot code (frequently executed code) to compile or optimize while the program is running.
The ART virtual machine executes local machine code. Android4.4 introduced, 5.0 as default
Interpretation execution (Dalvik) versus compilation execution (ART) : 
Explanation execution :(while executing translation) fast start, small memory, but slow running
Translation execution :(first full translation, then execution) starts slowly, consumes a lot of memory, but runs fast
Android before N — ART precompile Mechanism (AOT)
ART is introduced into theAhead Of TimeAt installation, ART uses the device’s own Dex2OAT tool to compile the application,The bytecode in dex will be compiled to local machine code.
— So installing APK on An Android 5-6 machine obviously felt slower, then changed, so it’s faster again
After the Android N
Before Android N, ART used a precompile mechanism (AOT), which was compiled at install time, so APK installation was slow. But after Android N, ART uses a combination of AOT compilation, interpretation, and just-in-time compilation (JIT). No precompile (AOT) at installation, interpreted execution at runtime, just-in-time (JIT) compilation of frequently run code and saving the results to a Profile, precompile when the phone is idle (charging) (AOT)
ClassLoader
ClassLoader Is responsible for loading class code into the JVM for execution
ClassLoader is an abstract class. Two important subclasses of ClassLoader are BootClassLoader and PathClassLoader
BootClassLoader: used to load system classes, ArrayList,String,Map, etc. PathClassLoader: used to load Android’s own and custom classes.
Parent delegation mechanism
Look directly at the source code and load a class.
- First look at the PathClassLoader(used to load custom classes)
2. Nothing, so look at the superclass
The superclass ClassLoader has a loadClass, which is the loading class
- The loadClass steps
This is the parent delegate mechanism. When you load a new class, you go to parent to load it. If the parent fails to fetch it, you go to BootClassLoader to load it. In the end, they didn’t use their own loading
Parent delegate mechanism: 1. Avoid repeated loading, when the parent class has already been loaded, directly from the parent class cache. Calling parent-loadClass takes the first step of the parent class findLoadedClass(name). 2. Security, which can prevent system API from being tampered with. If you define a String class with the same package name, you will still use the system String(BootClassLoader).
Parent: the constructor is passed in by itself. If not, the default is BootClassLoader
- Call yourself c.finclass (name) if you don’t find it
To express in pictures and pictures:
Hot repair
ClassLoader loads a custom class by converting the dex file into an array of DexElements and then removing the Dexfiles one by one through a for loop. And compares the class name by loadClassBinaryName (). So the hot fix is that we can generate our own differential package,.dex file, and then put it in the APK array, and use reflection to put it in the first position of the dexElement array, so that when we look for the class, we will look for our generated first. Dex file.