华为方舟编译器 Runtime 已经开源，从技术角度如何评价其架构和实现？ 第1页

方舟目前已有的组件，包含孵化器（一个毫无感情的记录机器）：

• 前端
• C
• Java，两个实现：1) jbc2mpl，Java字节码前端；2) dex2mpl，dalvik字节码前端
• Open64的WHIRL IR
• JS（未开源，可能working in progress）
• 优化：常规优化都有了，地方太小写不下
• 后端：
• AArch64
• ARM32（未开源）
• RISC-V
• MapleEngine，提供Maple IR的Interpreter
• 调试器
• 基于GDB的扩展
• 支持调试C
• 支持调试Java
• JS待支持
• Runtime(这个比较难分类了)
• Java
• Android（AArch64）
• OpenJDK

Sorry这么久才来填坑。

开源出来的方舟目前已经可以实现基于libcore或者OpenJDK运行静态化编译后的Java程序了，不过因为缺少apk编译的程序、魔改后的zygote（mygote）以及可能涉及的Android Runtime相关的修改，目前不能自己编译运行安卓程序。不过如我之前的分析一样，方舟已经可以编译部分第三方应用了，只是华为扣扣嗖嗖一直不全部开源出来（开源的东西是基于Maple的Java静态化，不涉及Android相关的修改）。如果可以的话，华为完全可以把这些实现捐献给AOSP的。

方舟在安卓上的实现，目前应该是比较成熟了，但估计确实存在很多问题（例如代码膨胀、热更新方案、兼容性等等）。不过方舟的目的并不是替换整个安卓运行时（我查了当时的宣发，如果我没理解错的话，当时说的是替换ART），而是将Java静态化编译，消除JNI，并且将内存管理方式替换为RC为主、Tracing GC为辐，以此解决卡顿等问题。

虽然我还没理清赵俊民大大说的五层架构，但是在我理解里，方舟的简易版架构差不多是上图这样的（原谅我对架构设计不熟悉）。

• 首先是上面的部分，将libcore/OpenJDK、HarmonyOS Framework以及Android Framework用方舟编译器静态化编译为动态库.so，这个过程中，方舟Runtime里好像对于一些JNI方法进行了重新实现；这个.so里就是编译为机器码的Java类，不过其对象结构不同；需要注意的是，原本Framework依赖的底层动态库，静态化编译之后也还是会依赖的，不过不是直接体现在.so的依赖中，而是通过libandroidmpl-rt.so这个方舟运行时库进行加载，而且在libmaplecore-all.so中，可以找到如下的和native调用相关的符号：

• 然后是图中下面的应用部分，同样通过方舟编译器编译为.so，和上述Framework编译没有区别；
• 最后是执行部分：
• 对于单纯的Java程序，提供了一个叫mplsh的程序用于启动、加载类、运行。这个也是目前开源提供的东西；
• 而对于Android和HarmonyOS，则是通过魔改的zygote（叫mygote）进行加载、运行。

上述提到了HarmonyOS，因为我在最新的EMUI 11中看到了maple化的HarmonyOS Framework。在EMUI 11的/system/lib64下面可以找到的maple化的动态库有如下这些：

       /system $ find -iname *maple* ./lib64/libmapleandroid.hardware.light-V2.0-java.so ./lib64/libmapleandroid.hidl.base-V1.0-java.so ./lib64/libmapleandroid.hidl.manager-V1.0-java.so ./lib64/libmapleandroid.test.base.so ./lib64/libmapleandroid.test.mock.so ./lib64/libmapleandroid.test.runner.so ./lib64/libmapleapache-xml.so ./lib64/libmaplebouncycastle.so ./lib64/libmaplecaliper-api-target.so ./lib64/libmaplecom.android.location.provider.so ./lib64/libmaplecom.huawei.nb.sdk.so ./lib64/libmaplecom.huawei.nfc.so ./lib64/libmapleconscrypt.so ./lib64/libmaplecore-all.so ./lib64/libmapleethernet-service.so ./lib64/libmapleext.so ./lib64/libmaplefeaturelayer-widget.so ./lib64/libmapleframework.so ./lib64/libmaplehwEmui.so ./lib64/libmaplehwIAwareAL.so ./lib64/libmaplehwIms-common.so ./lib64/libmaplehwPartAirSharing.so ./lib64/libmaplehwPartBasicplatform.so ./lib64/libmaplehwPartBasicplatformServices.so ./lib64/libmaplehwPartCamera.so ./lib64/libmaplehwPartConnectivity.so ./lib64/libmaplehwPartDFR.so ./lib64/libmaplehwPartDFRServices.so ./lib64/libmaplehwPartDefaultDFR.so ./lib64/libmaplehwPartDefaultDFRServices.so ./lib64/libmaplehwPartDeviceVirtualization.so ./lib64/libmaplehwPartEyeProtectionOpt.so ./lib64/libmaplehwPartIaware.so ./lib64/libmaplehwPartIawareService.so ./lib64/libmaplehwPartMagicWindow.so ./lib64/libmaplehwPartMagicWindowServices.so ./lib64/libmaplehwPartMdm.so ./lib64/libmaplehwPartMdmServices.so ./lib64/libmaplehwPartMedia.so ./lib64/libmaplehwPartPickUpWakeScreenOpt.so ./lib64/libmaplehwPartPowerOffice.so ./lib64/libmaplehwPartPowerOfficeServices.so ./lib64/libmaplehwPartSecurity.so ./lib64/libmaplehwPartSecurityFaceId.so ./lib64/libmaplehwPartSecurityServices.so ./lib64/libmaplehwPartSingleHandServices.so ./lib64/libmaplehwPartTelephony.so ./lib64/libmaplehwPartTelephonyCust.so ./lib64/libmaplehwPartTelephonyFullnetworkOpt.so ./lib64/libmaplehwPartTelephonyOpt.so ./lib64/libmaplehwPartTelephonyTimezoneOpt.so ./lib64/libmaplehwPartTelephonyVSim.so ./lib64/libmaplehwPartVr.so ./lib64/libmaplehwPartVrService.so ./lib64/libmaplehwSelfCure.so ./lib64/libmaplehwServices.so ./lib64/libmaplehwSlaveWifi.so ./lib64/libmaplehwTelephony-common.so ./lib64/libmaplehwWifi-service.so ./lib64/libmaplehwWifiPro-service.so ./lib64/libmaplehw_mdm_framework.so ./lib64/libmaplehwcustEmui.so ./lib64/libmaplehwcustIms-common.so ./lib64/libmaplehwcustServices.so ./lib64/libmaplehwcustTelephony-common.so ./lib64/libmaplehwcustframework.so ./lib64/libmaplehwcustwifi-service.so ./lib64/libmaplehwframework.so ./lib64/libmaplehwperf.so ./lib64/libmapleims-common.so ./lib64/libmaplejacocoagent.so ./lib64/libmaplejsr305.so ./lib64/libmaplejunit.so ./lib64/libmapleokhttp.so ./lib64/libmapleorg.apache.http.legacy.so ./lib64/libmapleorg.ifaa.android.manager.so ./lib64/libmapleorg.simalliance.openmobileapi.so ./lib64/libmapleservicehost.so ./lib64/libmapleservices.so ./lib64/libmapletelephony-common.so ./lib64/libmapletelephony-separated.so ./lib64/libmapleupdatable-media.so ./lib64/libmaplevendor.huawei.hardware.tp-V1.0-java.so ./lib64/libmaplevoip-common.so ./lib64/libmaplewifi-service.so ./lib64/libmaplezframework.z.so     

与上面的图对应：

• Android Framework: libmapleframework.so
• HarmonyOS Framework: libmaplezframework.z.so
• Maple Runtime: libmaplecore-all.so, libcommon_bridge.so, libandroidmpl-rt.so
• 除此之外，还有例如apache-xml、com.huawei.nfc、android.hidl.base-V1.0-java等第三方Java库maple化后的动态库，也有hwEmui.so、wifi-service等系统服务的动态库。

安卓的System Services的maple化是很早以前就完成了的，单独拿这点来说，确实是个壮举。但是，这些东西都是closed world的，对于这些程序的代码，有很大的修改、定制空间，方舟编译器和这些代码可以互相成全。但是面对第三方应用时，情况就不同了，因为你没法限制这些应用使用的SDK版本、Java特性、热更新方案，也不能要求人家放弃某些动态特性，只能尽全力去兼容、兼容、兼容，然后就是性能和兼容性的trade-off。支持方舟编译器的安卓第三方应用有了，但是并没有大规模使用，估计就是这个原因。

而对于HarmonyOS，情况可以好很多，因为Android已经踩过很多坑了，历史兼容性问题也没有很多，可以尽可能发挥方舟的效用。以热更新为例，Android系统有特别多的方案，但在HarmonyOS，系统层面已经提供了热更新的方案（HarmonyOS 文档中心-HotFixClassLoader）：

所以在安卓方向上的方舟不是重点也很正常。

以上说的都是Java的编译，而对于JS的编译，从多方消息来看，华为内部正在做，这个可能才是重点。

非代码讨论到此为止。

内容太多了，以后有空我会写文章来具体分析，下面就大致讲一下大概的内容吧。

1. 对象结构

• 编译出来的.so的正式名称叫MFile，Runtime有自己的ClassLoader来从MFile加载类信息；
• 因为是Java的Runtime，目前其对象结构和Java有点类似，为了兼容JNI规范，这些结构都有重载的类型转换操作符转换为JNI里的结构：
• MObject，对象，对应JNI的jobject；
• MClass，类，MObject的子类，对应JNI的jclass；
• MMethod，类方法，MObject的子类，以及对应的MethodMeta保存方法的元信息；
• MField，属性，MObject的子类，以及对应的FieldMeta保存属性的元信息；
• MArray，数组，MObject的子类，对应JNI的jarray；
• MString，字符串，MObject的子类，对应JNI的jstring；
• 有java.lang.invoke.MethodHandle相关的东西，所以可能已经支持lambda等特性了；
• 反射信息从XXXMeta中获取；
• 有一个还挺复杂的name mangler；
• 每一个符号都有一个MUID，是基于MD5哈希生成的，这个用于虚表查找等地方；

2. JNI调用

• 如上所说，兼容了JNI调用规范，将Runtime相关的结构转化为了JNI的结构，虽然本质上，JNI的那些结构就是一个指针；实现了JNI所有相关的方法；
• JNI规定每一个JNIEnv是线程独有的，所以在方舟的Runtime的线程实现里，有一个获取JNIEnv的方法；

       // get a thread related  env virtual JNIEnv* GetJniEnv() const = 0;      

• 依赖libnativehelper这个third party来查找动态库；
• 在中端优化部分（src/mapleall/mpl2mpl/src/native_stub_func.cpp）中，会为native方法生成相关的stub方法；
• native方法stub默认是一个weak符号，实现是抛出UnsatisfiedLinkError；JNI调用会被缓存；有一些libcore里的native方法在libcore-static-binding-jni和src/mrt/codetricks/arch/arm64实现，因为stub是weak的，所以链接上之后，这部分的JNI调用是直接调用；

                // Now native binding have three mode: default mode, dynamic-only mode, static binding list mode          // default mode, it will generate a weak function, which can link in compile time          // dynamic only mode, it won't generate any weak function, it can't link in compile time          // static binding list mode, it will generate a weak function only in list             

• NativeCall分为Fast和Slow，实现在src/mrt/compiler-rt/src/arch/arm64/cc_native_method_stub_arm64.S；FastCall是直接通过x9寄存器保存函数地址一条br指令直接跳转；SlowCall也是使用x9寄存器，区别在于调用前会保存callee的现场，并且会进入safe region（不知道和JVM GC算法里的safe region是不是同一个东西）；
• SlowCall支持最多8个参数；

3. RC

• 这部分有点复杂，还没细看；
• 编译时对于创建对象的指令，生成RC相关的Intrinsics调用，然后代码生成时，lowering为MCC_XXX等RC相关的运行时实现；
• Runtime里有相关的内存分配的allocator实现，借鉴了部分Rust的设计；
• 有四种垃圾收集器实现：
• 没有垃圾回收……
• NaiveRC，NaiveRCCollector，单纯只用RC回收；
• MarkSweep，MarkSweepCollector，基于标记-清除的Tracing GC；
• NaiveRCMarkSweep，NaiveRCMarkSweepCollector，RC为主，Tracing GC为辅；
• 垃圾回收类型可以在运行时动态设置；

       // Record gcIsGCOnly symbol address in echo RC compiled maple so // If not found, no action is need. // 1. At load time, check collector type and update // 2. At fork time/collector create time, update all according to new collector type     

• 在HarmonyOS Framework中，有RC标记相关的注解（HarmonyOS 文档中心）：