华为“方舟编译器”到底是啥？TA如何让手机性能再突破

"

虽然方舟编译器还没开放源码，但是大家对此还挺有兴趣的。最近和小伙伴讨论了下方舟编译器，并且讨论了下我提出的一个猜测，关于编译器执行代码的一个可行方案。

ART - Android Runtime

4.4提出，与Dalvik共存，5.0替换Dalvik

7.0更改方案为AOT与JIT混合

7.0的混合模式的意思就是第一次运行时编译成机器码，然后利用保存下来的机器码，去掉无用的，再存起来，供下次使用。

显而易见，以下便是缺点：

第一，在将字节码编译成机器码也是需要时间的，就算是直接进入堆栈(内存)，那也是有延迟的。尽管那几毫秒对于人类来说可以忽略。更何况，CPU还是傻傻地，编译好后会返回ART，等待ART的执行指示，等到执行指示，然后执行好后，依旧得经过ART堆栈，最后才能呈现于前台。

第二，就算不在使用时利用保存下来的数据进行编译，那么在你不用的时候编译，那就造成了耗电。

那，咱们说说华为的方舟编译器。

在开发的时候直接编译成机器码。

尽管我们不知道他是单个编译器直接编译成机器码还是先让JDK/AAPT编译成字节码后，才转换成机器码，但是这个我们都可以忽略，因为这跟用户并没有什么关系。

当然，咱们讲讲手机端他到底是怎么个回事。

我们预测方舟的方案是应该是在打包的时间插入了一个架构在ART的运行时，暂时叫他方舟运行时。执行代码由方舟运行时直接调用机器码，交于CPU执行，在返回ART或者方舟呈现。

为什么预测是在ART架构了一个运行时？

ART并不知道你编译的二进制是可执行的，换句话来说，ART只看得懂字节码，而看不懂二进制，那么方舟就能直接调用二进制，绕过ART的编译。除此之外，华为的想法是其他设备都能使用。由于安卓限权，包括根目录读写限制等等，直接在ART架构一个运行时是最靠谱，并且最合理的。

Java本身就有native方法，那为什么不直接使用native方法？

Java本身的native方法，最终还是会经过JVM，并且Android的图像处理/音视频都是魔改过了，更何况，他们全部方法都会经过native，然后才反馈于ART展示。而经过Java native前后都是需要进行编译，这样就造成了时间上的问题。

60%的流畅度提升是否真实？

我们猜测有可能。

正常来说，现在所有软件，包括PC，移动设备等等，为了降低软件的大小，编译所使用的都是动态编译，目的是将系统本身动态库与软件分开，从而降低软件大小，并且缩短编译时间，软件运行的时候再调用动态库链接编译。这就造成了时间延迟。

不过，除了动态编译，咱们还有静态编译。

静态编译的方法跟动态编译相反，在编译的时候，将所有所需要的动态库内容，直接载入软件内，那么就降低了运行时链接动态库的时间。

但是！60%应该只是实验室的测试，要求的是极端测试环境，例如CPU完全没事干，内存空闲，没用毒瘤在后台跳等等极端环境下，才有机会实现。在日常使用上，我预测应该只有30~50%的提升。

并且，华为自己的设备完全可以在系统直接插入一个方舟运行环境，抑或是一定的配置，遇到有方舟编译出来的应用，直接跑机器码，直接无视ART/JVM，利用自己本身的运行时呈现。

这是在没有源码的情况下根据多设备都能运行的原则，并且使用官方的说法，而预测的可能性。

在源码公布的时候才能知道是否如此。

那么，在8月9日源码公布的时候，我会尽快让大家知道，方舟底层到底是怎么运作的。

"

文章来源: https://www.toutiao.com/group/6718658170618642947/