Much of the recent conversation around Huawei has revolved around the company’s unfortunate political situation because of a US executive order that restricted many companies from conducting business with Huawei. The repercussions of such a pivotal decision are far too enormous to not pay attention. But in an alternate reality where this executive order does not exist, Huawei would have been in the limelight for its recently revealed Ark Compiler, the latest innovation that claims to bridge the app performance gap between Android and iOS.
Before diving into what Ark Compiler is, we need to take a step back and understand what a compiler is and the purpose it serves in the Android system.
Brief History of Compilers and Interpreters on Android
A compiler is a computer program that translates code from one language into another language, often being native machine language. This can then either be executed directly by the computer or be executed through another program (interpreter). This translation is necessary because we write code in human-readable programming languages (like Java and Kotlin), while the computer only understands native machine language (binary code in the form of 1’s and 0’s). The compiler thus serves as a bridge between the instructions that a human writes and the machine’s ability to understand and then execute those instructions. How quickly and efficiently this conversion and subsequent interpretation take place defines the efficiency of the compiler, thus introducing a direct correlation between the efficiency of the compiler to the performance and efficiency of code, and by extension, apps.
Dalvik VM
In the early days of Android, the OS utilized what was called the Dalvik VM (the interpreter) along with a JIT (just-in-time) compiler. This older video from XDA TV’s Android Basics 101 series touches upon the Dalvik VM and the JIT setup, both of which served the needs of early Android systems where memory constraints were abundant. The Dalvik VM took Java bytecode and converted it into machine code as and when the code needed to be executed (hence Just-In-Time). This was necessary as storage space in phones was a real constraint back then, so this approach allowed apps to work with smaller file sizes in the system.
Compiling and interpreting apps at runtime had the drawback of overall slower app performance as the compilation would take place alongside when the user is using the app.
Dalvik also had limitations with its Garbage Collection mechanism. Dalvik kept track of each memory allocation collectively. Once Dalvik determines that a piece of memory is no longer being used by the program, it frees this memory back to the heap without any intervention from the programmer. This process is called Garbage Collection (GC), and it aims to find memory objects in a program that isn’t accessed anymore and then reclaim the resources used by those objects for freeing up memory. The system determines when a GC is needed on a collective basis, so app developers do not get to choose when GC events occur [even in ART]. So if a GC event occurred in the middle of any intensive processing activity on the foreground app, the system would pause the execution of the process and begin GC, thereby increasing processing time and introducing a noticeable “jank” to the users.
These and other constraints pushed Google to explore alternative approaches for faster performance.
Android Runtime
With Android 4.4 KitKat, Google introduced ART (Android Runtime) in preview form with an AOT (Ahead-Of-Time) compiler, and with Android 5.0 Lollipop, Google dropped Dalvik in favor of ART as the only interpreter available. ART with AOT converted code into machine language at the time of installation of the app, rather than waiting to do such conversion when the app is in use. This approach thus sped up app launch times but also introduced drawbacks in the form of slower installation times and increased disk space usage. To balance it all out, Google adopted a combination of AOT, JIT, and profile-guided compilation with ART on Android 7.0 Nougat, to ensure that no single factor is affected drastically.
Android’s ART Implementation
ART also worked on making Garbage Collection less obtrusive. The GC process was optimized to be quicker overall with fewer pauses (single short pause versus Dalvik’s two pauses), less fragmentation, and less memory usage. Google’s presentation at Google I/O 2014 goes into better detail explaining the limitations of Dalvik’s GC and ART’s improvements on that end.
Even with these changes over the years, the basic premise of Google’s approach involved interpreting code during execution while varying the timing of the compiling (translation) element. Garbage Collection also continues to be a pain point for app developers because of its inherent interruptive and collective nature. Arguably, Android’s app performance suffers as a result as there continue to be overheads involved.
Ark Compiler by Huawei
Huawei has been working towards developing a more efficient solution and has consequently hired hundreds of experts in the field. The result of this effort is the Ark Compiler, which Huawei claims is the first-ever static compiler that allows for direct translation into machine language, completely removing the need for an interpreter. Ark Compiler was also developed with the goal of maximizing running efficiency for Java and C, so one should theoretically see the best results with these languages.
Graphic by Huawei. Text translated by XDA user MyKeyVans.
Huawei presents some key features of the Ark Compiler as below:
- Compilation techniques such as AOT and JIT can convert some programs into machine code and run them directly on the CPU, but these techniques are unable to completely untether themselves from the interpreter and limitations attached therewith. The Ark Compiler utilizes static compilation, which lets it untether itself from the dynamic interpreter, opening the possibility of boosting app performance by “leaps and bounds.“
- Static compilation has a potential downside of being too rigid and being unable to make adjustments that a dynamic compiler can make during execution. Huawei claims that the Ark Compiler’s static compilation resolves this “by seamlessly translating the dynamic features in the programming language into machine code.“
- Existing compilation processes take place during or after installation of the app package on the mobile device. Ark Compiler is designed for deployment during software development, which we presume helps to remove time overheads during installation and execution. We presume that app developers would be able to directly compile different languages into native machine code during the app development process, and the resultant APK could thus not need interaction with an interpreter or a virtual machine to function. This would theoretically reduce the overheads related to JNI, for instance.
- Ark Compiler also changes the collective nature of Garbage Collection. It allows for GC events to occur separately for different Java threads. This compartmentalized approach claims to offer less jank on foreground apps.
As a result of these changes, Ark Compiler can seemingly improve Android system operation fluency by up to 24%, response speed by up to 44%, and the smoothness of the third-party applications by up to 60%, claiming to bring Android app performance at the same level as that on iOS.
The Ark Compiler is currently compiled and optimized for ARM chip architecture. Huawei hopes that in the future, collaborative hardware and software design will work towards maximizing Kirin chip capabilities.
The Ark Compiler supports standard Java usage, allowing for the direct compilation of third-party apps without needing the app developer to make any code modification. Ark Compiler also allows for “adjustments to the code structure” for further improvements to performance and memory. Huawei has chosen to make Ark Compiler an open source system, which would allow third-party developers to adopt and adapt the technology for their needs, furthering its adoption with app developers and mobile phone manufacturers.
While Huawei does not mention any cons to the Ark Compiler, one can expect large app sizes at the very least, but this should not pose any problems on current generation devices which come with ample storage. We also expect that Ark Compiler will not be available for all CPU architectures, as Google’s compatibility woes are not Huawei’s headache. Ark Compiler is designed to be used during development and not during installation; this presents an indication that Huawei may have possibly modified how apps are deployed and installed on Android devices, and also may have worked on their own APK design. If correct, this could pose a major compatibility problem in the ecosystem, and it would be a long while before this would become a standard Android feature, if ever.
Not compiling on a user’s device also raises a big question on optimization. ART currently optimizes on a per-micro-architecture basis, meaning that the resulting binary would be different for a Snapdragon device versus an Exynos device, or even for a Snapdragon 845 versus a Snapdragon 625. This approach makes sense for manufacturers who have full control of the SoC, like Apple and Huawei. However, with the rest of the Android world using many different SoCs, forcing a generic optimization to be used across devices will be a roadblock for the standardization of the Ark Compiler, again. Consequently, do not expect Ark Compiler to arrive on your favorite custom ROM anytime soon.
For clarification, the Ark Compiler is developed to work with Android, and Huawei has mentioned nothing in relation to its alleged homebrew OS and its compatibility with Ark Compiler, so we make no presumptions on this end.
Huawei plans to hold two major conferences dedicated to developers and the larger ecosystem. These are the Huawei Device China Developers Conference and the Green Alliance China Developers Conference. Both events will address specific open source issues related to Huawei’s Ark Compiler, in an effort to make the benefits of this technology as widely accessible as possible.
Special thanks to XDA Senior Recognized Contributor Dees_Troy and Recognized Developer arter97 for their assistance and inputs.
Note: Huawei/Honor have stopped providing official bootloader unlock codes for its devices. Therefore, the bootloaders of their devices cannot be unlocked, which means that users cannot root or install custom ROMs.
The post Ark Compiler Explained: How Huawei’s App Compiler May Improve Android App Performance appeared first on xda-developers.
0 comments:
Post a Comment