最近这两天，部分型号的华为手机用户已经陆续收到了新的系统更新，该系统更新的日志中明确写到方舟编译器已经加入到了系统中。目前华为还在稳步推进各机型方舟编译器的适配工作，未来华为还会向更多的机型推送方舟编译器，而且方舟编译器将支持不少老机型。

从华为给 EMUI 更新方舟编译器的动作来看，方舟编译器确实不单单只是一个编译器，而是一个一整套的环境。编译器本身是面向应用开发者提供的，和普通用户没有什么太大的关系，普通用户之所以能够收到有关方舟编译器的更新，主要是因为华为需要预先向 EMUI 中整合方舟编译器的框架。

目前方舟编译器的源代码还没有放出，而华为更新至 EMUI 中的那一部分内容也并不是我们所能窥探到的，所以目前来说我们仍然不能从代码等层面来深入分析方舟编译器。

关于方舟编译器，网络上的言论是比较杂的，有不少外行人士基于华为对方舟编译器的描述对方舟编译器大吹特吹，也有一些网友在没有代码的情况下就抛出长篇大论来试图剖析方舟编译器的机理。

然而实际上，在方舟编译器正式开源前，我们能够了解到的只是方舟编译器很浅显的一面，我们所知道的基本上等于华为告诉我们的，现阶段我们还没有办法围绕方舟编译器建立我们自己的看法，所以本文将围绕华为已经告诉我们的东西来谈一谈方舟编译器到底强在哪。

很多媒体在华为推送方舟编译器更新的相关文章里都用上了「流畅度提升」这个词，而实际上方舟编译器的框架本身并不能给系统流畅度带来提升，它需要由方舟编译器编译出来的应用与其相配合才能起到对系统流畅度提升的作用。

目前由于方舟编译器还并没有向业界全面开放，所以所谓的「流畅度提升」最多大体也就只体现在系统应用上，第三方应用暂时是不会有提升的。

在 P30 发布会后，华为举行了一场媒体沙龙，媒体对这一活动的报道比较少，在这一次媒体沙龙上，华为透露了更多关于方舟编译器的信息。

方舟编译器和笔者之前预想的类似，是将 AOT 的过程搬到了开发机上，开发者可以直接将源代码静态编译成 .so 文件，直接在用户的手机上安装运行，用户机无需再对程序做任何的解释执行或动态编译。

从华为给出的 PPT 来看，方舟编译器的框架在系统内是独立于 ART 虚拟机的，方舟编译器编译出来的 App 将完全运行在华为自己造的体系里，和 Android 自己的那一套运行 App 的体系已经没有什么关系了。

一般来说，一个 APK 内除了虚拟机文件外，还会有一些 so 库，这些 so 库文件主要是由 C 语言代码编译过来的。根据华为的说法，市面上有不少来自大企业的 App 都有使用两种或两种以上的语言来编写 App，例如 Java 和 C 配合，其中 C 的那一部分就会被编译成 so 库作为 App 的一部分。

方舟编译器编译出来的应用则能够将这两个部分整合在一起，基于媒体沙龙上华为公开的消息，方舟编译器实际上能够将不同的语言转化为统一的程序表示，并进行联合优化，最终得到一个二进制文件。

这意味着华为方舟编译器能够对不同编程语言进行混编，编译到一个统一的 IR，再统一优化输出 Native Code，也就是所谓的「机器码」。这样的思路和现有的其他技术架构存在一定的类似性，华为做的不是「创新」，而是「工程」。

这样的混合编译消除了 Android 在 ART 虚拟机下需要通过 JNI 来调用 C/C++机器码的开销，这是它在性能提升上的一个点。

华为做的是将这一套东西用在 Android 上，用到实际应用场景上。对于 Android 来说，这可能是某种程度上的所谓「革命」，但是对于整个行业来说，方舟编译器可能没有那么强大。

由于 AOT 编译被转移到了开发机上，所以华为可以用一些更极端的优化算法，并对不同的应用针对性做不同的优化。

这份 PPT 的话其实比较虚，它并没有展示出方舟编译器在优化应用方面的细节，但是它证实了我们在方舟编译器刚刚发布时的猜测，即方舟编译器确实会利用开发机的力量来对应用做更多的优化。

在我们的猜测中，结合华为之前有关编译的专利，方舟编译器可能会对应用的某些部分，比如计算密集区域等加入一些标记，让系统能够提前得知应用要做什么，进而做出相应的调度来提升应用性能。这很可能是华为在这面 PPT 中提到的「不同优化」，这个优化需要和方舟编译器的框架配合才能实现。

需要注意的是，Android 设备和 iOS 设备有很大的不同，Android 设备之间的差异是很大的，而且架构上也有区别，粗糙一点分也有 ARM 和 x86 之分。一套机器码并不一定能够在所有的设备上稳定运行或高效运行，静态编译需要针对不同的目标平台编译适合目标平台的机器码。

目前华为并没有将这一步骤放在云上，和应用商店整合在一起，他们将这一事情交给了开发者。即使方舟编译器届时只能够在华为生态的设备上使用，开发者仍然还需要考虑到不同设备之间的差异，而个人开发者、小团队根本就没有足够数量的开发机去测试其稳定性，在这一方面，目前来看华为的考虑是有些欠妥的。

方舟编译器另一个提升性能的点是在 GC 上，实际上现有 Android 中 ART 的 GC 已经得到了很多的优化，方舟编译器的主要思路应该是通过引用计数来局部地优化 GC，做到内存随用随回收，并利用原先的 GC 机制来处理一些引用计数处理不了的情况。

这一套理念也并非是华为首创的，如果华为真的是通过引用计数的方法来局部优化 GC，那么华为做的仍然也只是「工程」而非「创新」，这样的思路也是业内早就有了的。

GC 方面的优化从理论上确实会对性能带来提升，但是具体能够提升多少不太明确。

目前华为仍然没有给出方舟编译器的任何代码，所以我们仍然并不能够评判方舟编译器的好坏和实际的作用。

华为会在今年 8 月开源方舟编译器框架代码，并在今年 11 月开源方舟编译器的所有代码，在开源之前华为关于方舟编译器的一切都还只停留于纸面上，我们并不能准确地去评估方舟编译器的到底能带来多大的提升，是否有华为说得那么好。其中对于华为开源的框架代码，由于华为对于「编译器」这一概念的混淆，目前笔者也没有办法确定这个「框架」指的是编译器的大体框架，还是系统需要整合的「Framework」部分。

如果是后者，那么这个框架内是否会包含关键的 Runtime 将会是一个重要看点，毕竟在前文中笔者有提到过，方舟编译器的性能提升和集成在系统中的框架是有关系的。

总体来看，笔者个人感觉全网对方舟编译器有一些吹得太过，目前华为还没有向开发者什么提供实际有用的信息，现在就给它下结论还是有一些太早。就目前而言，方舟编译器至少在编译器这一领域所做的更多是「工程」而不是「创新」，其创新主要是对于 Android 而言的，毕竟他们造了一个 Android 上原本不存在的东西，一套 Android 上原本不存在的模式。

值得一提的是，华为在媒体沙龙上有提到过方舟编译器对开发者来说学习和使用成本低，不知道届时他们面向开发者提供的工具是否会像他们所说的一样是简单易用的。

对于 Android，除了 Android 架构导致其运行速度慢外，还有一个点也会导致系统总体运行低效。当下有太多应用大面积运用 H5、React Native、weex 等，应用规模一大，它用起来就会有一些卡卡的，阿里系应用就是一个典型。这类应用的实际上也是一个性能瓶颈，如何提升这类应用的运行效率也是一个很值得思考的问题。

转载：https://www.vyg.net/13063.html