华为EMUI的方舟编译器，安卓软件生态的转折点？

日前上海发布会上，华为推出的方舟编译器可谓是意外的惊喜。根据华为的介绍，方舟编译器能够从程序编译与运行机制上提升安卓系统的流畅度，不仅引来科技粉关注，许多小白也很关心，这款编译器究竟能够给安卓带来什么变化。

毕竟，天下苦安卓卡顿久矣，从测试版到现在，已经进入Android 10.0版本，虽然流畅度一代一代有所提高，但是相比隔壁的iOS，安卓体验弱的不是一点半点。发布会上余承东表示方舟编译器可让操作系统流畅度提升24%，给安卓党带来许多期待。

就连谷歌一直都未能搞的太定的事，方舟编译器怎么样实现？想要了解其中具体的逻辑，我们先从什么编译器说起。

啥是编译器？

简单的理解，不管编程怎么变，最终编程得到的可执行二进制程序都是给CPU运行的。使用二进制直接编程非常不现实，因此计算机领域诞生了汇编语言（用一个符号来代替一串二进制），接着诞生C语言，C语言之上还有更高级语言，譬如：C++、Java、C#、bash等等。

简单讲，编译器就是将“一种语言（通常为高级语言）”翻译为“另一种语言（通常为低级语言）”的程序。

其中，高级计算机语言便于人编写，阅读交流，维护；现在大多数程序员都不需要复杂的计算机知识，掌握一门或多门高级计算机语言就可以进行编程就是这个道理。机器语言是计算机能直接解读、运行的。编译器是将汇编或高级计算机语言源程序（Source program）作为输入，翻译成目标语言（Target language）机器代码的等价程序。

简单的理解，编译器就是承上启下的中间层，连接着高级语言和机器语言，应用程序是否能够直接编译，决定了流畅度和稳定性，这就是Android 平台与iOS平台在体验上巨大差异的关键。

作为基于Linux的自由及开放源代码的操作系统，Android 平台的绝大多数应用是使用Java语言写的，由于Java语言独特的虚拟机机制（简称JVM），CPU不能直接理解汇编指令。早期Android运行程序过程中，每运行一行Java语言的虚拟机指令都需要即时编译为CPU识别的机器码，这就是安卓卡顿的根源；在安卓历代的版本，围绕这一问题提出很多解决方案（后面会详解），却都很难彻底解决。

反过来看，iOS从诞生之初就采用LLVM（Low Level Virtual Machine）编译器，LLVM是构架编译器(compiler)的框架系统，以C++编写而成，是一个模块化和可重复使用的编译器和工具技术的集合。应用程序（Swift语言编写）能够直接编译成机器码，无需像Android需要一个中间层过渡，程序可在手机CPU上直接运行。

你明白了JVM与LLVM的工作机制，就知道为何同样的手机内存，为何iOS的流畅度甩掉Android几条街。在用户的日常使用中，内存只有2G的iPhone，其流畅度往往远超4G、6G的Android手机。

安卓系统想要实现同iOS一样的高效，就要解决JVM，解决程序直接编译成机器码的痛点，方舟编译器最大的亮点，就是围绕这一问题进行优解（后面会详解）。

历代安卓的努力

我们都知道Android系统是以Linux系统为底层构建的，Android系统是开源(源代码公开)，因此这涉及到对不同硬件配置设备的适配问题，而iOS的闭环特性则不存在这一问题。谷歌为了降低应用开发难度就在Linux底层之上，构筑了一个基于JIT的Dalvik编译器。

也就是说，在早期的安卓系统上每次运行应用时都需要虚拟机的一次编译，每次执行应用的时候虚拟机都会将程序的语言由高级语言编译为机器语言，这样设备才能够运行这一应用，相比iOS的机制，多个中间层使其执行效率大大下降。

后来受Oracle起诉侵权影响，以及谷歌对提效安卓系统的内在推动，开始着手开发Dalvik的替代品。

2014年谷歌在android 5.0版本中使用了ART来正式替换Davlik。相比于运行一行应用就要进行编码的Davlik，ART是一个AOT编译器，所谓AOT (Ahead of Time)是指在运行以前就把字节码静态编译成二进制机器码，摆脱了每次运行应用都要虚拟机即时编译的冗余过程，相比JIT 能够提高执行效率。

但是，问题依然存在，替换Davlik的ART编译器虽然实现了Java字节码的静态编译，受Java语言本身的限制，特别是类的动态加载相关的特性，仍然依赖JVM在运行时进行解释执行或编译执行的能力。

也就说，Android演变为包含了解释执行+JIT+AOT的混合模式，虽然流畅度有所提升，但相比iOS仍有不小的差距，卡顿问题依然存在。

除此之外，安卓的GC（Garbage Collection，垃圾回收机制）同样也为系统带来卡顿难题。当安卓系统上需要分配的内存空间不再使用的时候，Java虚拟机将调用GC来回收内存空间，而GC本身是个全局暂停事件，当GC进行时所有的应用线程都会停止，直到回收操作完成，这是安卓用户经常遭遇莫名卡顿的原因之一。

方舟编译器做了什么？

从公开的信息分析，华为的方舟编译器也基于AOT，不过方舟编译器采用的可能是创造性地静态编译了动态语义，就是把所有的字节码都被提前编译为二进制代码，也就是说完全消除虚拟机的影响，让JVM消失，程序完整的在手机CPU上直接运行，就能比肩iOS一样的高效。

此外，方舟编译器还通过编译优化算法，将代码编译出的机器指令最优化，以此来提升代码执行效率，当然这个是加分项，最关键的还是程序在手机CPU直接运行。

从上图的实现机制中我们能够看到，方舟编译器缩短安卓上应用运行的路径，在安卓生态上实现类似iOS的LLVM（Low Level Virtual Machine）编译器的机制，相比android ART编译器实现对流畅度的提升。

方舟采用了引用计数法（RC，Reference Counting）来进行内存的回收，来避免GC集中式的回收带来的系统卡顿。

这个算法就是给对象增加一个引用计数，每当对象被引用时，就将该对象的引用计数加一。所以当一个对象的引用计数为0的话，那么就可以认为这个对象是可以回收的。并采用消除环算法（消除对象互相引用带来的无法回收问题）来配合RC，以实现内存的实时回收。将集中式的处理，变为分布时间打扫，避免出现全局暂停事件。

市场上虽然很多厂商强调对安卓深度定制，但有能力，并且有魄力对安卓底层机制改动的企业并不多，尤其是像华为这样在编译器层面实现整体的优化。华为能够推出方舟编译器，一方面，得益于华为深厚的技术和人才积累，自EMUI 5.0以来便力图通过底层优化提升系统性能；另一方面，得益于华为一直聚焦用技术创新提升用户的使用体验，从F2FS文件系统、GPU Turbo到方舟编译器，层层深入对安卓系统的优化。

另外，华为已表示方舟编译器将面向业界全面开源，提供完整的编程框架和应用开发工具链，并开放给第三方伙伴构造开发者生态，意味着未来将有更多开发者可参与到方舟编译器的开发、使用，对于提升整个安卓生态的体验带来很大的可能性。

不过，最终安卓系统能否追赶上iOS，还有等待市场的进一步验证。笔者作为资深的安卓党，期待方舟为安卓带来流畅度的提升，当安卓用户不再去羡慕iOS的流畅，在中高端市场安卓手机们才能更好的同iPhone竞争。

大家可以添加 luochaozhuli 进群。