Since the release of the first version of Android 1.0 on September 23, 2008, under the combined action of Moore’s Law and Andy Beer’s Law, Android system has been iterating at the rate of at least one major update every year (once a year since 2016). In the process of version iteration, The evolution of the Android VIRTUAL machine cannot be ignored.

The early days of Android

In the early stage of Android system, unlike Java platform, which used JVM to load bytecode files (.class), Dalvik acted as the virtual machine in Android system, and every time the program was run, Dalvik is responsible for loading the dex/ Odex file and parsing it into machine code for the system call.

Android 2.2 — JIT debut

In order to adapt to the improvement of hardware speed, the Android system is constantly updated, and the single Dalvik VIRTUAL machine has gradually met the requirements of the system. On May 20, 2010, Google released Android 2.2 (Froyo yogurt). In this version, Google added a JUST-in-time Compiler to the Android virtual.

Like most JVMS, Dalvik uses JIT for just-in-time compilation. With Java HotSpot VM, the JIT compiler can compile and optimize frequently executed dex/ Odex code. Dalvik Code (Smali instruction set) in DEX/Odex was translated into fairly simplified Native Code for execution, and the introduction of JIT improved the performance of Dalvik by 3~6 times.

But the disadvantages of the JIT model should not be ignored:

  • You need to recompile every time you start the application
  • It consumes more power when running, resulting in extra battery overhead

Andorid 4.4 — ART and AOT

On October 31, 2013, Google released Android 4.4 (Kitkat), bringing a preview of the new VIRTUAL machine RunTime environment ART (Android RunTime) and a new compilation strategy AHEAD-of-time (AOT). It should be noted that ART was co-existing with Dalvik at the time, and the user could choose between the two.

Android 5.0 — ART completely replaces Dalvik

On October 16, 2014, Google released Android 5.0 (Lollipop), and ART completely replaced Dalvik as the running environment of Android VIRTUAL machine. At this point, Dalvik withdrew from the historical stage, and AOT became the only compilation mode.

AOT differs from JIT in that JIT compiles at run time, dynamically compiles, and recompiles Odex each time a program is run. AOT, on the other hand, is statically compiled. When the application is installed, dex2OAT process will be started to precompile dex into ELF files. There is no need to recompile every time the program is run, which is a real local application.

In addition, compared with Dalvik, ART also improves the Garbage Collection (GC) process:

  1. Only one GC pause (Dalvik requires two)
  2. Parallel processing while the GC remains paused
  3. In the special case of cleaning up recently allocated short-duration objects, the collector’s total GC time is shorter
  4. Optimized garbage collection ergonomics for more timely parallel garbage collection, making GC_FOR_ALLOC events extremely rare in typical use cases
  5. Compress GC to reduce background memory usage and fragmentation

AOT mode solves the problems of app startup and running speed and power consumption, but also introduces two other problems:

  • Application optimization after application installation and system upgrade takes time
  • Optimized files take up additional storage space

This also foreshadows the future optimization of Android.

Android 7.0 — JIT is back

Those who have used Android phones should know that on Android 5.x and 6.x machines, there will be a process of application optimization when the system restarts after OTA upgrade. This process is the dex2OAT process mentioned just now, which is time-consuming and takes up extra storage space.

On August 22, 2016, Google released Android 7.0 (Nougat), and the JIT compiler is back, which forms AOT/JIT hybrid compilation mode. This hybrid compilation mode features:

  • Dex is not compiled when the application is installed
  • At runtime, the app’s dex file passes through the Interpreter and is executed directly (as it did before Android 2.2 to Android 4.4). At the same time, Hot codes are identified and JIT compiled and stored in the JIT Code cache and a profile is generated to record the Hot Code information.
  • When the phone enters the IDLE or Charging state, the system scans the profile file in the App directory and executes the AOT process to compile it.

As can be seen, the hybrid compilation mode integrates various advantages of AOT and JIT, making the application speed up while optimizing the running speed, storage space, power consumption and other indicators.

conclusion

Android system from the birth to now, experienced several important updates, the final choice of a compromise, so that the installation and operation of the system when the indicators have been optimized, so far, Android virtual machine development process comes to an end. However, with the continuous improvement of hardware performance, I believe that Google’s footsteps will not stop here, looking forward to Google in the future to continue to bring us surprises.

Refer to articles/videos

www.youtube.com/watch?v=TCJ…

Source.android.com/devices/tec…

www.jianshu.com/p/9a3a4eb32…

Zh.wikipedia.org/wiki/Androi…

If you have different opinions about the content of this article, please leave a comment and we will discuss it together.