After huawei launched the black technology GPU Turbo last year, this year again threw a bombshell, Android performance revolution, Huawei Ark compiler, so-called to solve the Inefficient Android program “interpretation and execution”, the entire implementation of machine code efficient running procedures. Architecture-level optimization to significantly improve performance. System operation fluency increases by 24%, system response increases by 44%, and three-party application operation fluency increases by 60%. We promise to open source to the industry. Dare to open source, this data should not moisture. You should have seen the video of the P30 Pro hitting the S10 online.

To solve the Inefficient android program “interpretation and execution”, what is interpretation and execution? That is, how does Android execute the code in Apk? It starts with machine code.

Machine code

Whether it is a low-level language, such as assembly, or today’s widely used various high-level languages, Java, C++, etc., for the CPU, all are a book of god. All it knows is binary machine code. Of course, machine code is a myth to you, too. So how do you direct the CPU to run your program? At this point, you need a translator between you to translate your code into machine code and give it to the CPU so it knows how to execute. In the face of different terminals, the translation content is also different, you only know the x86 instruction set to translate arm, certainly can not translate out, just like holding an English dictionary to translate Japanese. Translation also has tools. Here are several common translation tools:

The compiler

Translate assembly code directly into machine code. Assembly code is very fast because it generally corresponds to machine code one to one. It’s just assembly language, you know, it’s not readable, it’s difficult to use, and it’s basically impractical for the average developer to write large programs.

The compiler

Compilers translate the high-level languages we normally use for development, such as Java/C++, into machine code for the CPU to use. This compilation is slow, but the execution is fast.

The interpreter

The program does not need to be compiled. The program is translated into machine language at runtime, every time it is executed. Therefore, the efficiency is relatively low. You can imagine that this is a lot slower. Typical interpreted language, PHP/JS/Python, etc.

How does JAVA code execute?

The execution of Java programs depends on the Java Virtual Machine (JVM), which is directly recognized by the JVM as bytecode. Java code is compiled to generate Class files, or bytecode files, which are then processed by the JVM. How does the JVM execute Class files? Taking HotSpot as an example, Class files will be stored in the method area after being loaded by the virtual machine, and the virtual machine will execute the code in the method area during the actual run.

The job of translating bytecode into machine code falls naturally to the JVM. In HotSpot, there are several translation forms.

  • Explain to perform

Byte code is translated into machine code and executed, line by line

  • Just-in-time (JIT) compilation

All the bytecode contained in a method is compiled into machine code before execution.

The former has the advantage of not having to wait to compile, while the latter has the advantage of actually running faster. By default, HotSpot is in mixed mode, combining the best of both interpreted execution and just-in-time compilation. It first interprets the execution bytecode, and then compiles the hotspot code that is executed repeatedly, method by method, in real time.

How does Android code execute?

Java, if not Java, is the most commonly used language for Android development. Java source files in Android projects are also compiled to generate Class files, which are finally packaged into DEX bytecode files. Dalvik or Art is responsible for translating DEX bytecode into machine code.

Before Android 5.0, it was Dalvik. Dalvik is interpreted execution plus JIT. Each time the app is run, it dynamically interprets part of Dalvik bytecode into machine code. As the App runs, more bytecode is compiled and cached. Because the JIT compiles only part of the code, it has a smaller memory footprint and less device physical space footprint. However, execution while explaining is inefficient, which is also the reason why Dalvik was abandoned later.

Starting with Android 4.4, Android introduced Art, and with Android 5.0, Art officially replaced Dalvik. Art uses AOT (Ahead of Time) compilation method, that is, during the installation process of the application, all Dex bytecode is translated into machine code and stored in the device space, completely abandoning THE JIT, the benefits are obvious.

  • Apps run faster because DEX bytecode interpretation is done during installation and directly runs machine code

  • Application startup time is reduced because native code can be executed directly.

  • Save power consumption and don’t have to explain bytecode line by line.

  • Enhanced garbage collection.

  • Enhanced developer tools.

Running machine code directly, well, wait, isn’t that what the Ark compiler does? The answer must be no, otherwise there would be no need for it to exist. In fact, this completely AOT-BASED model has been abandoned by Android. If you’ve used Android 5.0 or 6.0, you’ll remember the long wait to install apps. Because bytecodes need to be translated during installation, the installation process can be lengthy, especially for larger applications. In addition, the machine code translated during installation also takes up more storage space on the fuselage.

With Android 7.0, Android has added JIT, a just-in-time (JIT) compiler with code analysis capabilities. In fact, according to the 80-20 law, the hot spot code that runs frequently may be 20% or less, and we don’t need to translate all the bytecode into machine code in advance through AOT. AOT was abandoned during the installation process to speed up the installation, so the first time you use it you have to explain the execution. As you use the application, the JIT starts analyzing the code, translating the bytecode into machine code where appropriate, and continuously improving the performance of the Android application as it runs. In addition, AOT comes into play when the device is idle, translating the hot code into machine code and saving it, further improving efficiency. In this sense, the current Android explanation execution, JIT, and AOT exist simultaneously. The following picture on the official website is a good illustration of the JIT architecture under Art.

As for the interpreter, the higher Version of Android implementation is no longer so weak, according to the website:

With the introduction of Mterp, an interpreter with a core extract/decode/interpret mechanism written in assembly language, the performance of the interpreter in Android 7.0 has been significantly improved. Mterp mimics the fast Dalvik interpreter and supports ARM, ARM64, x86, x86_64, MIPS, and MIPS64. For computational code, ART’s Mterp is roughly equivalent to Dalvik’s fast interpreter. Sometimes, though, it can slow down significantly, or even dramatically:

  • Call performance.
  • String operations and other high-frequency user methods in Dalvik that are considered inline functions.
  • Stack memory usage is high.

Android 8.0 addresses these issues.

Having said all that, it’s all about the balance between installation speed, space usage, and running speed. So far, Android has done a pretty good job, but there’s still a lot of criticism.

It is now clear that the Ark compiler is by no means fully AOT. The last sentence in the PPT is “hope the APP manufacturer can use it as soon as possible”, which is not a mobile phone manufacturer. Therefore, it is not ruled out that the Ark compiler can directly package Apk or DEX in Apk into machine code format. However, since machine code is not platform compatible, it is not clear whether the Ark compiler must be bound to EMUI. At the end of the day, it’s all about laying the groundwork for Huawei’s new phone system. Huawei’s ambition, and its extremely advanced technology reserves, we believe that a complete Huawei ecosystem is not far away.

The compiler is called Ark. The new system should be called Noah.

The article was first published in the wechat public number: Bingxinsaid, focus on Java, Android original knowledge sharing, LeetCode problem solution, welcome to scanning code attention!