在Open harmony OS上运行Android APP有哪些方案?

Android

自Android诞生起，在其他系统上运行Android APP就一直是个热门需求。在此，我们来探讨一下各种相关方案，并且研究一下这些方案能否整合到Open harmony OS当中。首先是系统虚拟机方案，它通过模拟虚拟CPU来运行linux内核。在这个linux内核之上，要为虚拟机虚拟的外设适配Android HAL（硬件抽象层），然后启动Android操作系统。有这样的案例：系统虚拟机的CPU性能损耗非常低，低于5%，不过内存性能会有一些损失，具体表现为TLB（转换后备缓冲器）命中率下降，内存balloon（气球内存管理机制）频繁触发，GPU性能的损失则比较大。需要留意的是，普通ARM Soc（片上系统）的linux内核运行在EL1权限级别，而虚拟机管理器需要EL2权限级别。所以，除非Soc厂商同意，在Soc上运行的linux是无法使用硬件虚拟化的，这会对性能产生严重影响。对于虚拟机GPU的实现，有以下几种方案：从Google和微软的实践经验来看，Native Context在消费级GPU上构建虚拟机时是最佳的GPU方案。要是华为在EL2固件上支持虚拟化，那就能够利用Native Context实现近乎原生的性能。其次是容器方案。容器方案并不运行单独的VCPU（虚拟CPU）和linux内核，而是运用宿主系统的内核，并在此基础上构建隔离方案。考虑到目前HarmonyOS使用容器在AOSP（安卓开源项目）上运行Open harmony OS，那么与之相反的功能是能够实现的。但要注意，Open harmony OS 4.1的很多安全功能实际上是禁止这种用法的。最后是ART虚拟机级别兼容层方案。这是Google多次尝试但都失败了的方案，失败的原因都是无法为NDK（原生开发工具包）提供二进制ABI（应用二进制接口）兼容性。第一次尝试是ChromeOS的ARC（安卓运行环境），这个方案把Android的dalvik虚拟机编译到NaCl（本地客户端）上（类似于WebAssembly），使得不使用NDK的App能够运行。但是这个方案不支持NDK，所以非常不实用，很快Google就切换到基于容器的ARC++方案，随后又切换到基于虚拟机的ARCVM方案。第二次尝试是原本的Fuchsia支持Android的方案，该方案把Android的ART移植到Fuchsia上，并且将NDK移植到Fuchsia，为NDK程序提供了源码级别的兼容性。然而，没有开发者愿意为Fuchsia编译NDK动态库，所以这个方案被放弃，改为使用linux兼容层Starnix。综上所述，这个方案无法达成兼容现有App的目的。