A Tutorial for Building Maple for ARM and Compiling C Codes
 
last updated: 2020-10-13
 
A General Guidance of Building Maple for ARM and Running C Examples
 
Here is a step by step tutorial for building the Maple for the ARM release and running real C examples, which will print some ASCII texts. We did this demo in the environment below:
 
    Operating System:       Ubuntu 18.04.5 LTS
    Kernel:                 4.15.0
    GCC:                    7.5.0
 
 
Clone the repository from the gitee to your local environment.
 
 git clone https://gitee.com/openarkcompiler-incubator/mapleall.git
 cd mapleall
 
 
Set up tools for testing.
 
 cd tools/
 ./setup_tools.sh
 
 
Initialize the environment for building the Maple for ARM with the release version.
 
 cd ..
 source envsetup.sh arm release
 
 
Now, can we make and install the Maple, and all maple excutables can be found in the $MAPLE_ROOT/bin directory. Let MAPLE_ROOT be the top directory of the mapleall repository
 
 make
 make install
 
 
Run the two examples for fun.
 
First, we will use ast2mpl as C Frontend to print the ASCII text.
 
 cd examples/C
 ./maple_with_ast2mpl.sh
 
The output is as below:
 
 cd /home/lin/mapleall/examples/C/use_ast2mp
 ========================================================================
 ================== Use ast2mpl as C Frontend ===========================
 ========================================================================
 INC=/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0
 /home/lin/mapleall/bin/ast2mpl printHuawei.c -I /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/include
 /home/lin/mapleall/bin/arm64-clang-release/maple -exe=me,mplcg -option="-O2 --quiet:-quiet" printHuawei.mpl
 /usr/bin/aarch64-linux-gnu-gcc -o printHuawei.out printHuawei.s -lm
 qemu-aarch64 -L /usr/aarch64-linux-gnu/ printHuawei.out

 HHHHHH         HHHHHH    HHHHHH         HHHHHH           HHHHH        HHHHHH        HHHHHH        HHHHHH       HHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH          HHHHHHH        HHHHHH      HHHHHHHH      HHHHHH       HHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH         HHHHHHHHH       HHHHHH      HHHHHHHH      HHHHHH      HHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH         HHHHHHHHH       HHHHHH     HHHHHHHHH      HHHHHH     HHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH        HHHHHHHHHHH       HHHHH     HHHHHHHHHH     HHHHH     HHHHHHH                HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH        HHHHHHHHHHH       HHHHHH    HHHHHHHHHH    HHHHHH     HHHHHH                 HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH       HHHHHH HHHHHH      HHHHHH   HHHHHHHHHHH    HHHHHH    HHHHHH                  HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH       HHHHHH HHHHHH       HHHHH   HHHHH HHHHHH   HHHHH     HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH      HHHHHH   HHHHHH      HHHHHH  HHHHH  HHHHH  HHHHHH     HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH      HHHHHH   HHHHHH      HHHHHH HHHHHH  HHHHHH HHHHH      HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH     HHHHHH     HHHHHH     HHHHHH HHHHH   HHHHHH HHHHH      HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH     HHHHHHHHHHHHHHHHH      HHHHH HHHHH    HHHHH HHHHH      HHHHHH                  HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH    HHHHHHHHHHHHHHHHHHH     HHHHHHHHHHH    HHHHHHHHHHH      HHHHHH                  HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH    HHHHHHHHHHHHHHHHHHH     HHHHHHHHHH      HHHHHHHHHH      HHHHHHH                 HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH   HHHHHHHHHHHHHHHHHHHHH     HHHHHHHHH      HHHHHHHHH        HHHHHH                 HHHHHH
 HHHHHH         HHHHHH     HHHHHH       HHHHHH    HHHHHH         HHHHHH     HHHHHHHHH      HHHHHHHHH        HHHHHHHH               HHHHHH
 HHHHHH         HHHHHH     HHHHHHHHHHHHHHHHHHH   HHHHHH           HHHHHH    HHHHHHHH        HHHHHHHH         HHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH      HHHHHHHHHHHHHHHHH    HHHHHH           HHHHHH    HHHHHHHH        HHHHHHHH          HHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH       HHHHHHHHHHHHHHH    HHHHHH             HHHHHH    HHHHHHH        HHHHHHH             HHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH         HHHHHHHHHHH      HHHHHH             HHHHHH    HHHHHH          HHHHHH               HHHHHHHHHHHH     HHHHHH
 
Then, we can use opencc/whirl2mpl as C Frontend to print the same text.
 
 ./maple_with_whirl2mpl.sh
 
Here is the output:
 
 cd /home/lin/mapleall/examples/C/use_whirl2mpl
 ========================================================================
 ============= Use opencc/whirl2mpl as C Frontend =======================
 ========================================================================
 /home/lin/mapleall/tools/open64ark/bin/opencc -O0 -fe -keep -show -std=gnu99 printHuawei.c
 /home/lin/mapleall/tools/open64ark/bin/whirl2mpl printHuawei.B
 /home/lin/mapleall/bin/arm64-clang-release/maple -exe=me,mplcg -option="-O2 --quiet:-quiet" printHuawei.mpl
 /usr/bin/aarch64-linux-gnu-gcc -o printHuawei.out printHuawei.s -lm
 qemu-aarch64 -L /usr/aarch64-linux-gnu/ printHuawei.out

 HHHHHH         HHHHHH    HHHHHH         HHHHHH           HHHHH        HHHHHH        HHHHHH        HHHHHH       HHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH          HHHHHHH        HHHHHH      HHHHHHHH      HHHHHH       HHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH         HHHHHHHHH       HHHHHH      HHHHHHHH      HHHHHH      HHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH         HHHHHHHHH       HHHHHH     HHHHHHHHH      HHHHHH     HHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH        HHHHHHHHHHH       HHHHH     HHHHHHHHHH     HHHHH     HHHHHHH                HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH        HHHHHHHHHHH       HHHHHH    HHHHHHHHHH    HHHHHH     HHHHHH                 HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH       HHHHHH HHHHHH      HHHHHH   HHHHHHHHHHH    HHHHHH    HHHHHH                  HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH       HHHHHH HHHHHH       HHHHH   HHHHH HHHHHH   HHHHH     HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH      HHHHHH   HHHHHH      HHHHHH  HHHHH  HHHHH  HHHHHH     HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH      HHHHHH   HHHHHH      HHHHHH HHHHHH  HHHHHH HHHHH      HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHHHHHHHHHHHHHHHHH    HHHHHH         HHHHHH     HHHHHH     HHHHHH     HHHHHH HHHHH   HHHHHH HHHHH      HHHHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH     HHHHHHHHHHHHHHHHH      HHHHH HHHHH    HHHHH HHHHH      HHHHHH                  HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH    HHHHHHHHHHHHHHHHHHH     HHHHHHHHHHH    HHHHHHHHHHH      HHHHHH                  HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH    HHHHHHHHHHHHHHHHHHH     HHHHHHHHHH      HHHHHHHHHH      HHHHHHH                 HHHHHH
 HHHHHH         HHHHHH    HHHHHH         HHHHHH   HHHHHHHHHHHHHHHHHHHHH     HHHHHHHHH      HHHHHHHHH        HHHHHH                 HHHHHH
 HHHHHH         HHHHHH     HHHHHH       HHHHHH    HHHHHH         HHHHHH     HHHHHHHHH      HHHHHHHHH        HHHHHHHH               HHHHHH
 HHHHHH         HHHHHH     HHHHHHHHHHHHHHHHHHH   HHHHHH           HHHHHH    HHHHHHHH        HHHHHHHH         HHHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH      HHHHHHHHHHHHHHHHH    HHHHHH           HHHHHH    HHHHHHHH        HHHHHHHH          HHHHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH       HHHHHHHHHHHHHHH    HHHHHH             HHHHHH    HHHHHHH        HHHHHHH             HHHHHHHHHHHHHH     HHHHHH
 HHHHHH         HHHHHH         HHHHHHHHHHH      HHHHHH             HHHHHH    HHHHHH          HHHHHH               HHHHHHHHHHHH     HHHHHH
 
 
 
FAQ and Errors
 
 
The make complains the clang package as below:
 
 /bin/sh: 1: clang: not found
 ninja: build stopped: subcommand failed
 
[Solution]
 
 sudo apt install -y clang
 
 
if the system misses the elf library, you will get error below:
 
 /usr/bin/ld: cannot find -lelf
 clang: error: linker command failed with exit code 1 (use -v to see invocation)
 
[Solution]
 
 sudo apt install -y libelf-dev libssl-dev
 
 
The build lools for aarch64-linux-gnu-gcc which requires the ARM cross compiling toolchain.
 
 ./maple_with_ast2mpl.sh: line 44: /usr/bin/aarch64-linux-gnu-gcc: No such file or directory
 
[Solution]
 
 sudo apt install -y gcc-7-aarch64-linux-gnu
 sudo ln -s /usr/bin/aarch64-linux-gnu-gcc-7 /usr/bin/aarch64-linux-gnu-gcc
 
 
If the execution of example complains the missing command qemu-aarch64 as below, we need install the QEMU for ARM.
 
 ./maple_with_ast2mpl.sh: line 48: qemu-aarch64: command not found
 
[Solution]
 
 sudo apt install -y qemu-system-arm qemu-efi-aarch64 qemu-utils qemu-user
 
 
If the execution complains any one of the following errors, please check the content of the file printHuawei.out:
 
 Error while loading printHuawei.out: Exec format error
 Error while loading printHuawei.out: Permission denied
 
[Suggested Diagnosis]
 
 less printHuawei.out
 ls /usr/bin/aarch64-linux-gnu-gcc -l
 
[Possible Cause]
 
The /usr/bin/aarch64-linux-gnu-gcc could be linked to a wrong compiler, such as /usr/bin/aarch64-linux-gnu-cpp-7. The correct compiler could be any of gcc compiler in your system, such as /usr/bin/aarch64-linux-gnu-gcc-7
 
[Solution]
 
 sudo ln -s /usr/bin/aarch64-linux-gnu-gcc-7 /usr/bin/aarch64-linux-gnu-gcc
 
 
Repository
 
https://gitee.com/openarkcompiler-incubator/mapleall

 

 
华为继去年推出黑科技 GPU Turbo 之后，今年再次扔出了一枚重磅炸弹， 安卓性能革命，华为方舟编译器，号称解决安卓程序 “边解释边执行” 的低效，全程执行机器码高效运行程序。架构级优化，显著提升性能。系统操作流畅度提升 24%，系统响应提升 44%，三方应用操作流畅度提升 60%，并承诺向业界开源。敢于开源的话，这个数据应该没有水分。大家在网上应该也看到了 P30 Pro 吊打 S10 的视频。
 
解决安卓程序 “边解释边执行” 的低效，什么是边解释边执行？也就是说，Android 是如何执行 Apk 中的代码的？这得从机器码说起。
 
机器码
 
不论是低级语言，如汇编，还是如今广泛使用的各种高级语言，Java，C++ 等，对于 CPU 来说，全部都是天书。它能认识的只有二进制的机器码。当然，机器码对你来说，也是天书。那你应该如何指挥 CPU 运行你的程序呢？这个时候，你们之间就需要一个翻译，将你的代码翻译成机器码给 CPU，它就知道该如何执行了。面对不同的终端，翻译内容也不一样，你一个只知道 x86 指令集的去翻译 arm 的，肯定翻译不出来，就好似拿着本英语字典去翻译日语。翻译也有工具，下面说说几种常见的翻译工具：
 
汇编器
 
将汇编代码直接翻译成机器码。由于汇编代码一般和机器码都是一一对应的，所以它的速度非常快。只是汇编语言，你懂的，可读性差，
 
用起来难，用来写大型程序对于普通开发者基本是不现实的。
 
编译器
 
编译器将我们平常开发用的高级语言，例如 Java/C++ 等，翻译成机器码供 CPU 使用。这种编译很慢，但是执行起来会很快。
 
解释器
 
程序不需要编译，程序在运行时才翻译成机器语言，每执行一次都要翻译一次。因此效率比较低。可以想象这种运行方式就慢了很多。
 
典型的解释型语言，php/js/python 等。
 
JAVA 代码是如何执行的 ？
 
Java 程序的执行依赖于 Java 虚拟机(JVM)，JVM 能直接识别的叫做字节码。Java 代码经过编译会生成 Class 文件，即字节码文件，再交由 JVM 处理。而 JVM 又是怎么执行 Class 文件的呢？这里以
 
HotSpot 为例，Class 文件被虚拟机加载后会存放在方法区，实际运行时，虚拟机会执行方法区中的代码。
 
将字节码翻译成机器码的工作自然就由 JVM 来承担了。在 HotSpot 中，有几种翻译形式。
 
解释执行
 
逐条将字节码翻译成机器码并执行
 
即时编译(Just-in-time ，JIT)
 
将一个方法中包含的所有字节码编译成机器码后再执行。
 
前者的优势在于无需等待编译，而后者的优势在于实际运行速度更快。HotSpot 默认采用混合模式，综合了解释执行和即时编译两
 
者的优点。它会先解释执行字节码，而后将其中反复执行的热点代码，以方法为单位进行即时编译。
 
Android 代码是如何执行的 ？
 
开发 Android 目前用的最多的还是 Java，即使不是 Java，也是 JVM 语言。Android 工程中的 java 源文件经过编译也是生成
 
Class 文件，最后被打包成 DEX 字节码文件，负责将 DEX 字节码翻译成机器码的是 Dalvik 或者 Art。
 
在 Android 5.0 之前，还是 Dalvik 的天下。Dalvik 是解释执行加上 JIT，每次app运行的时候，它动态的将一部分 Dalvik 字节码
 
解释为机器码。随着 App 的运行，更多的字节码被编译和缓存。因为 JIT 只编译了一部分代码，它具有更小的内存占用和更少的设备物理空间占用。但是，边解释边执行，效率低下，这也是后来 Dalvik 遭到抛弃的原因。
 
从 Android 4.4 开始，Android 引入了 Art，到 Android 5.0，Art 正式代替了 Dalvik。Art 使用的是 AOT(Ahead of Time)的编译方式，即在应用的安装过程中，就将所有的 Dex 字节码翻译成机器码存储在设备空间中，完全抛弃了 JIT，带来的好处是显而易见的。
 
Apps 运行的更快，因为 DEX 字节码的解释在安装过程中已经完成，直接运行机器码
 
减少了应用的启动时间，因为本地代码可以直接执行。
 
节省电量消耗，不需要再去一行一行的解释字节码。
 
增强了垃圾回收。
 
增强了开发者工具。
 
直接运行机器码，恩，等等，这不就是方舟编译器做的事情吗？答案肯定是否定的，否则它因为完全没有存在的必要了。事实上，这种完全基于 AOT 的模式也已经被 Android 抛弃了。如果你用过 5.0 或者 6.0 的安卓机，你一定不会忘记安装应用带来的漫长等待。由于需要在安装期间翻译字节码，所以安装过程会很长，尤其对
 
一些大型应用来说。另外，安装过程中翻译出来的机器码也占用了更大的机身存储空间。
 
Android 7.0，Android 又加入了 JIT，一个具备代码分析功能的即时 (JIT) 编译器。事实上，根据二八定律，经常运行的热点代码可能只占 20%，甚至更少，我们没有必要通过 AOT 提前将所有字节码都翻译成机器码。安装过程中放弃 AOT，加快安装速度，所以初次使用时得解释执行。当你在使用应用时，JIT 就开始分析代码了，在合适的时候将字节码翻译成机器码，在 Android 应用运行时持续提高其性能。另外，设备空闲的时候，AOT 就发挥作用了，它会将热点代码翻译成机器码并保存下来，进一步提高运行效率。这么看下来，现在的 Android 是 解释执行 、JIT、AOT 同时存在的。下面这张官网的图片很好的说明了Art 下的 JIT 架构.
 

 
关于解释器，高版本中的 Android 实现也不再那么孱弱了，根据官网相关介绍：
 
通过引入 Mterp(一种解释器，具有以汇编语言编写的核心提取/解码/解释机制)，Android 7.0 版本中的解释器性能得以显著提升。Mterp 模仿了快速 Dalvik 解释器，并支持 arm、arm64、x86、x86_64、mips 和 mips64。对于计算代码而言，ART 的 Mterp 大致相当于 Dalvik 的快速解释器。
 
不过，有时候，它的速度可能会显著变慢，甚至急剧变慢：
 
调用性能。
 
字符串操作和 Dalvik 中其他被视为内嵌函数的高频用户方法。
 
堆栈内存使用量较高。
 
Android 8.0 解决了这些问题。
 
说了这么多，无非是安装速度，空间占用，运行速度的平衡，目前 Android 应该已经做得很好了,但仍然存在不少诟病。
 
现在可以确定的是，方舟编译器绝对不可能是 完全 AOT。PPT 中最后一句话是 “希望 APP 厂商尽快使用” ，并不是手机厂商，所以不排除方舟编译器可以直接将 Apk ，或者说 Apk 中的 DEX 打包成机器码格式。但由于机器码并不是平台兼容的，所以并不能确定方舟编译器是否必须要绑定 EMUI。其实说到底，这一切都应该是为了华为的新手机系统作铺垫。华为的野心之大，以及其极其超前的技术储备，相信一个完整华为生态已经离我们不远了。
 
编译器叫方舟，新系统干脆就叫 诺亚 吧！
 
文章首发于微信公众号： 秉心说 ， 专注 Java 、 Android 原创知识分享，LeetCode 题解，欢迎扫码关注！
 

 
 
本文同步发表于我的微信公众号，扫一扫文章底部的二维码或在微信搜索 郭霖 即可关注，每个工作日都有文章更新。
 
 
8月31日，早上9点，华为方舟编译器官网就这么悄然上线了。网上甚至没有大面积的新闻报道，我是隔天才知道的这个消息。
 
在今年4月份华为P30系列的发布会上，华为首次对外公开了正在自主研发一款开源的统一编程平台，可以大幅提升Android应用程序在手机上的运行效率，称之为方舟编译器，随即在业内引起了轰动。当初华为给出的预计时间是，方舟编译器将会在今年8月份开源编译框架代码，11月份开源完整的方舟编译器，那么终于在8月份的最后一天，华为完成了自己的承诺，上线了方舟编译器的官网。
 

 
 
至于方舟编译器的用途是什么？以及为什么可以大幅提升Android应用程序的运行效率？华为也在P30发布会之后的技术沙龙会议上进行了具体的解释。从方舟编译器的工作原理上来看，虽然确实是可行的，但是技术难度非常高，如果华为真的能按照自己当初的设计方案来完成方舟编译器，或许真有可能会在Android开发界掀起一场变革。
 
那么我是一名开发者，我的公众号的读者朋友们也都是开发者，因此这里我就站在一个开发者的角度上写一篇科普文章，让每一位看完本篇文章的读者朋友们都能更加清楚地了解方舟编译器。
 
首先由于历史遗留问题，Android的开发与编译环境并不是完美无缺。可能是考虑到当初编程语言排行榜霸主的因素，也有可能是因为能够更加符合Android开放式合作操作系统的定位，总之Google就是采用了Java语言来作为Android应用程序开发的首选语言。
 
虽然在Android 1.5系统之后Google又引入了NDK功能来允许Java去调用一些由C/C++代码开发的so库，但是Java的正统地位却从来没有被撼动过（Kotlin也是基于Java虚拟器的编程语言，因此对于方舟编译器而言Kotlin和Java没有区别，故不在本篇文章的讨论范围内）。
 
熟悉Java的朋友应该都清楚，它是一种预编译解释型语言，每执行一行代码，会由解释器将这行代码先解释成CPU看得懂的机器码，然后再去执行。解释型语言的好处是可以实现一次编译随处运行的便利性，因为对于不同平台而言只需要换用不同的解释器即可，但是坏处也很明显，就是运行效率低下。
 
很多用户都抱怨过Android应用不同iOS应用流畅，当然原因可能有很多种，但是上述原因绝对是重要的原因之一。
 

 
 
在基于Java（Kotlin）编程语言的总战略思想不可动摇的前提下，Google为了提升Android应用程序的运行效率可谓是煞费苦心。在最开始的时候，Android系统中内置了一个Dalvik虚拟机，其实也就是Google自己编写的一个Java虚拟器，然后使用边解释边执行的方式来运行Java代码，这种模式运行效率极其低下，因此很快Google就引入了JIT模式来改善这种情况。
 
JIT（Just In Time）是即时编译的意思，当用户在使用App时，会将经常使用的功能编译成机器码，这样当再次使用这个功能时就可以直接运行机器码，而不用每次都一行行翻译了。
 
然而JIT的机制仍然不够完美，在Android 5.0系统的时候Google进行了一次大变更，废弃了Dalvik虚拟机，引入了全新开发的ART虚拟机，并使用AOT（Ahead Of Time）的方式来提升运行效率。AOT就是在应用安装的时候预先将代码都编译成机器码，这样在应用运行的时候就不用再做解释工作了，直接就可以运行。
 
那一年的Google I/O大会真的是慷慨激昂，Google认为自己找到了最完美的方式，Android应用的运行效率终于可以和iOS应用相媲美了。
 

 
 
然而最终用户实际的反馈却并不怎么好，AOT机制使得安装应用变得太慢了，而且预先编译机器码还会占用额外的手机空间。
 
于是在Android 7.0系统中，Google又进行了调整，这次重新引入了JIT模式。应用安装的时候不会进行编译操作，以保证安装速度。在设备空闲的时候，将一些常用的代码使用AOT的方式进行编译，如果执行到还没来得及编译的代码，那么就使用JIT+解释执行的方式来顶住。这也算是Google在安装速度和运行速度之间进行的一种平衡吧。
 
之后的每个系统版本虽然仍然有一些改变，但基本都是在AOT+JIT+解释执行之间进行动态调整，以找到一个更好的平衡点。可是制约Android运行效率最关键的虚拟机这个点，Google却一直都无法解决。
 
而方舟编译器生来就是为了干掉虚拟机的。
 
根据华为在P30发布会上所公开的资料，方舟编译器所采用的机制是将Java代码转换成机器码的这个过程提前到了编译打包的时候，这样生成的安装文件所包含的代码本身就已经是机器码了，因此即便是应用程序安装后首次运行，速度也会非常流畅。
 
这种方案确实可行，但是会存在一个问题。在方舟编译器这种工作原理下打出来的安装包改变了Android原生的apk格式规则，有可能会变成华为自主定义的一套hpk格式的安装包。而这种安装包肯定是不被Android原生系统支持的，因此使用方舟编译器所生成的安装包大概率只能安装到华为自己的手机上，当然也不排除未来国内其他手机厂商对华为这种格式进行兼容的可能。
 
上述的内容都是我当初在基于现有公开资料的基础上进行的推测，然而随着方舟编译器官网的正式上线，也证实了我之前的推测是错误的。
 
方舟编译器的官网有一个代码演示功能，我尝试将它网上的Java代码示例编译并运行，结果发现输出的却是一个so库。
 

 
 
这让我大吃一惊！要知道，so库是C/C++代码通过cmake或者ndk-build编译之后生成的本地库，而方舟编译器竟然可以将Java代码直接转换成so库，不得不说华为的这套思路真的太敢想了。
 
使用so库不仅可以解决Android应用原来的低效解释运行模式，而且还能保证最终生成的安装包文件和原生的apk文件格式一致，因为so库本身就是被Android系统所支持的。这样我之前所推测的hpk格式的安装包就已经不成立了，方舟编译器的战略眼光也并没有仅仅只是放在华为自家的平台上面，而是放眼于全Android平台，因为使用方舟编译器编译出来的apk可以正常安装到所有Android手机上。
 
另外，Java语言还有一个非常重要的特性，与C++不同，Java是不用手动释放内存的，Java虚拟机将会不定期自动回收不再被使用的对象，这也是Java被广大程序员喜爱的一个重要原因。不过这种回收机制也造成了一个问题，当触发回收过程的时候，将会暂停所有正在运行的Java线程，虽然这个过程很短暂，但是在一些低配手机上可能就会造成了一种随机性卡顿的现象。
 
而方舟编译器的工作原理天然就可以解决这个问题，因为将Java代码全部转换成so库之后，Java虚拟机的自动回收机制也就无需工作了，这样随机性卡顿的问题自然不复存在。这个过程对于我们开发者而言是透明的，但是对于方舟编译器而言，这个过程真的很难很难，因为要将开发者的Java代码转换成so库，还要能自动检查并回收不再被使用的对象，在我看来根本就是不可能的事情。
 
方舟编译器的设计思想的确非常先进，并且相信华为也已经攻克了无数的技术难关。但是对于华为来说，现在最缺的应该还是时间。从这次方舟编译器官网的上线就可以看出，有点赶鸭子上架的感觉，开发者文档极其简单，只有一些简短的架构描述和环境搭建流程。
 

 
 
代码演示也是预先定义好的代码模板，不支持修改后重新运行，只能预览一下预定代码的执行结果。
 
另外编译器下载分为源代码包下载和二进制包下载两种，源代码我确实是看不懂，因为我选择下载了编译好的二进制包，但是解压之后发现只有4个编译好的二进制文件和一些sample样例，官网也并没有描述该如何使用。
 

 
 
这和我预想的并不一样，因为我本来以为方舟编译器会是一个类似于Android Studio那样的IDE开发工具。不过有朋友告诉我，华为的IDE工具还正在开发当中，这次开源的只是编译器框架部分源码，但这也更加印证了方舟编译器的官网是赶在8月这个时间节点上紧急上线的一个网站。
 
不管怎么说，方舟编译器的思想是超前且先进的，也非常希望看到在编译器这个领域里能有国产技术的出现，只是华为还需要更多的时间。
 
另外一定会有朋友关心，随着未来方舟编译器的推出和不断完善，Android开发工具会迎来一场大变革吗？Android Studio会被取代吗？这种未来的事情我其实也不可能预测的准，但是Google的官方开发工具Android Studio是专门用于开发Android应用程序的，而方舟编译器则是为支持多种编程语言、多种芯片平台的联合编译、运行而设计的统一编程平台。它们的定位并不完全相同，因此也未必会是这种只能二选一的竞争关系。Android系统毕竟还是Google家的，华为在这上面的话语权肯定不足，与其说方舟编译器是要为了和Android Studio抢市场，不如说华为这是提前在编译器的领域进行布局，倘若未来方舟编译器可以用于开发鸿蒙系统的App，这看起来就更像是一个梦幻组合了。
 
虽然中国的互联网技术已经进入了世界最顶尖的行列，移动支付的普及率和便捷性更是达到了国外无法想象的程度，但是在计算机行业最基本最底层的芯片、操作系统、编程语言、编译器等领域，中国和欧美国家还存在非常大的技术差距。而华为是国内少有的几家有这个资本且愿意涉足这几个领域的企业，给它足够多的时间吧。
 
 
 
 
关注我的技术公众号，每个工作日都有优质技术文章推送。
 
 
微信扫一扫下方二维码即可关注：
 
  

根据方舟官方文档，首先要把方舟编译器的源码，编译成可执行代码maple
 
1、操作系统环境：
 
目前我使用的是Ubuntu 16.04 虚拟机 而且官方推荐Ubuntu 16.04
 
 
 
2、安装支持包及库文件：
 
sudo apt-get -y install openjdk-8-jdk git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev
 libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils
 xsltproc unzip lib32z1-dev qemu g++-multilib gcc-multilib python3-paramiko python-paramiko python-jenkins 
 python-requests python-xlwt libglib2.0-dev libpixman-1-dev linux-libc-dev:i386

sudo apt-get -y install gcc-5-aarch64-linux-gnu g++-5-aarch64-linux-gnu
 
3  进入方舟编译器开源地址：
 
https://github.com/HarmonOS/OpenArkCompiler
 
下载相关代码并解压到相应目录下
 
我这里放在home 目录下 并修改目录名为 OpenArkCompiler
 
4、llvm和clang的下载及配置：
 
从LLVM Download Page 下载 LLVM8.0.0的Ubuntu 16.04 (.sig) 二进制包。解压之后，放到OpenArkCompiler/tools目录之下。
 
注意：这里要修改名字clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04 为clang_llvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04
 
加号+改为下划线_
 
5、下载和配置Ninja、GN：
 
从https://github.com/ninja-build/ninja/releases 下载Ninja v1.9.0，在tools下新建目录ninja_1.9.0，将ninja可执行文件放到ninja_1.9.0目录之下。
 
最好都使用chmod 777 ninja 处理一下。
 
从https://archive.softwareheritage.org/browse/content/sha1_git:2dc0d5b26caef44f467de8120b26f8aad8b878be/raw/?filename=gn 下载GN，在tools下新建目录gn，将gn可执行文件放到gn目录之下。
 
最好都使用chmod 777 gn 处理一下。
 
6、在OpenArkCompiler目录之下依次执行如下两个命令：
 
source build/envsetup.sh
make
 
经过以上操作后，系统就编译好了maple了。
 
要编译成功samples 下的helloworld.java  还需要做如下修改
 
7 修改 build/core/java2jar.mk 为如下代码。
 
$(APP_JAR): %.jar : %.java
        $(JAVA2JAR) $(APP_JAR)  "$(wildcard *.java)"
 
也就是将里面的 
 
${MAPLE_ROOT}/libjava-core/java-core.jar
 
 删除，让它不依赖于这个输入文件
 
8 修改 build/core/jbc2mpl.mk 为如下代码。
 
$(APP_MPL): %.mpl : %.jar $(JBC2MPL_BIN)
        $(JBC2MPL_BIN) -injar ${MAPLE_ROOT}/libjava-core/java-core.jar -injar $(APP_JAR) -out $(APP)

 
用java-core.jar 替换 libjava-core.mplt 也就是$(LIB_MPLT)
 
9  修改out/bin/java2jar 为如下代码
 
#!/bin/bash
OUTPUT=$1
CORE_ALL_JAR=$2
JAVA_FILE=$2
shift 2
javac -g -d . ${JAVA_FILE}
#javac -g -d . -bootclasspath ${CORE_ALL_JAR} $@
jar -cvf ${OUTPUT} *.class
 
10  最后需要下载我们一直在讨论的java-core.jar 库。
 
下载路径如下，并把相关库放到如下目录的libjava-core里面
 
  https://gitee.com/mirrors/java-core
 
 
进入samples/helloworld目录下
 
make 就可以了，
 
最后的结果如下图
 
 
 
 
没有报什么错误，并且在本目录下生成了一些必要的文件了。
 
 整个过程参考了如下大牛的讲解，https://zhuanlan.zhihu.com/p/81076176