方舟目前已有的组件,包含孵化器(一个毫无感情的记录机器):
Sorry这么久才来填坑。
开源出来的方舟目前已经可以实现基于libcore或者OpenJDK运行静态化编译后的Java程序了,不过因为缺少apk编译的程序、魔改后的zygote(mygote)以及可能涉及的Android Runtime相关的修改,目前不能自己编译运行安卓程序。不过如我之前的分析一样,方舟已经可以编译部分第三方应用了,只是华为扣扣嗖嗖一直不全部开源出来(开源的东西是基于Maple的Java静态化,不涉及Android相关的修改)。如果可以的话,华为完全可以把这些实现捐献给AOSP的。
方舟在安卓上的实现,目前应该是比较成熟了,但估计确实存在很多问题(例如代码膨胀、热更新方案、兼容性等等)。不过方舟的目的并不是替换整个安卓运行时(我查了当时的宣发,如果我没理解错的话,当时说的是替换ART),而是将Java静态化编译,消除JNI,并且将内存管理方式替换为RC为主、Tracing GC为辐,以此解决卡顿等问题。
虽然我还没理清赵俊民大大说的五层架构,但是在我理解里,方舟的简易版架构差不多是上图这样的(原谅我对架构设计不熟悉)。
上述提到了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
与上面的图对应:
安卓的System Services的maple化是很早以前就完成了的,单独拿这点来说,确实是个壮举。但是,这些东西都是closed world的,对于这些程序的代码,有很大的修改、定制空间,方舟编译器和这些代码可以互相成全。但是面对第三方应用时,情况就不同了,因为你没法限制这些应用使用的SDK版本、Java特性、热更新方案,也不能要求人家放弃某些动态特性,只能尽全力去兼容、兼容、兼容,然后就是性能和兼容性的trade-off。支持方舟编译器的安卓第三方应用有了,但是并没有大规模使用,估计就是这个原因。
而对于HarmonyOS,情况可以好很多,因为Android已经踩过很多坑了,历史兼容性问题也没有很多,可以尽可能发挥方舟的效用。以热更新为例,Android系统有特别多的方案,但在HarmonyOS,系统层面已经提供了热更新的方案(HarmonyOS 文档中心-HotFixClassLoader):
所以在安卓方向上的方舟不是重点也很正常。
以上说的都是Java的编译,而对于JS的编译,从多方消息来看,华为内部正在做,这个可能才是重点。
非代码讨论到此为止。
内容太多了,以后有空我会写文章来具体分析,下面就大致讲一下大概的内容吧。
// get a thread related env virtual JNIEnv* GetJniEnv() const = 0;
// 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
// 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