近日，华为在上海举行了P30系列的国内发布会，除了揭晓了这款产品的相关信息之外，这场发布会还有一个极可能会造成深远影响的新技术——方舟编译器。根据华为公布的信息显示，方舟编译器通过架构级优化，将显著提升APP的运行效率，尤其是全程执行机器码，能够更为高效的运行应用，彻底解决安卓应用“边解释边执行”所造成的低效率。

华为造了一个“方舟”

余承东在发布会上表示，方舟编译器可让系统操作流畅度提升24%，系统响应速度提升44%，第三方应用重新编译后流畅度可提升60%。并且此次推出的方舟编译器将面向业界开源，希望App开发厂商能够尽快使用。

从目前社交媒体上出现的一段华为P30Pro与三星GalaxyS10+，使用方舟编译的微博APP预加载速度对比视频中，我们不难看出，采用麒麟980主控的华为P30Pro在微博图片加载速度上，完成了对三星GalaxyS10+的碾压。

想要明白“方舟编译器”到底是什么东西，首先需要明确几个概念。无论是手机、PC，还是其他设备都是负责执行已经被计算机语言编好的程序，而程序则是计算机要执行的指令的集合。目前，计算机语言分为程序员用来编程的高级语言(人类使用)、由于0和1组成的二进制机器语言(机器使用)，以及根据机器硬件编译成人能看懂的汇编语言。

编译器的作用就是将JAVA、C++，或者汇编语言翻译成机器语言，将程序员写的源代码(SourceCode)转换成CPU能够直接处理的机器码(NativeCode)，简而言之，就是在人与机器之间搭建一座桥梁，或者充当人和机器之外的翻译。编译器技术作为计算机科学的明珠，它的开发门槛可以说是相当之高，要懂得x86、x64、ARM架构，以及它们的指令集MIPS、RCIS等众多知识才行。

Android编译器的发展历程

很明显，华为的方舟编译器就是一个高水准的“翻译工具”，但是编译器在Android系统中到底起了什么样的作用，就要从Android的发展历程中寻找答案。2008年9月，谷歌正式发布了Android1.0，但大家都知道的是，Android是基于Linux内核的操作系统，底层是Linux用于硬件驱动和资源调配，在中间加上了Java虚拟机，其表面层是Android运行库。

在Android2.2之前，Android的Java虚拟机是Dalvik。Dalvik支持转换为.dex格式的Java应用程序，每次运行程序的时候，Dalvik负责将dex文件翻译为机器码交由系统调用，但Dalvik的劣势，就是这是一种适合内存与处理器速度有限系统的解决方案。在这一阶段中，Android被iOS以及塞班完全碾压，差不多就只剩下了开源这一个优点。

到了Android2.2，由于Android系统的低效率，谷歌拿出了即时编译技术JIT(JustInTimeCompiler)。使得在App运行时，每当遇到一个新类，JIT编译器就会对这个类进行编译，而经过编译后的代码，会被优化成相当精简的原生型指令码(即nativecode)，这样在下次执行到相同逻辑的时候速度就会更快，而这其实就是余承东所说的“边解释边执行”模式。

但很遗憾的是，即便JIT让Dalvik的性能提升了300%以上，但是由于JITD的策略是dex文件翻译成本地机器码，都需要发生在应用程序的运行过程中，并且应用程序每一次重新运行时，都要做重做这个翻译工作。也使得JIT+Dalvik的组合还是与高效无缘，依然被iOS吊打。

有鉴于此，在Android4.4时谷歌推出了新的虚拟机ART(AndroidRuntime)，来解决之前的Java代码执行效率太低的问题。ART使用的编译器被称为AOT(AheadOfTime)，也就是预编译策略，指的是App在第一次安装时，Java代码就会被预先编译成机器码，使其成为真正的本地应用。但问题就是完全的AOT模式，让App安装和系统升级之后的优化非常耗时，同时被优化的App会占用额外的存储空间。但在这一时期中，Android的流畅度则有了一定的提升。

到了Android7.0之后，谷歌重新引入了JIT编译技术，形成了AOT+JIT+解释执行共存的模式。也免除了单独使用某一种解决方案带来的缺陷，解释执行是为了辅助优化AOT结果，避免进行无脑的全量编译，而JIT则是为了对ART进行代码分析，使其能够在运行时动态优化。并且在AndroidQ上，谷歌结合AI技术提供了系统预测感知功能，使得App在安装时，系统就能知道常用代码会被提前编译。

在“三剑合璧”的模式之下，如今的Android已经比4.X、5.X时代要高效很多。但是即便是这样的Android，在iOS面前依然是略逊一筹。使用C语言开发的iOS是不需要虚拟机的，再搭配专用的开发工具Xcode，以及编译效率超高的LLVM编译器，实现了只要APP运行就能够自动将整个程序编译，然后转换为机器码的静态编译。当然，这也造成了同一款APP，iOS端包体要明显大于Android端的情况。

简而言之，Android不改变以虚拟机为中心的运行模式，其实很难从根源上解决卡顿的问题。

方舟会是扇动Android生态的蝴蝶吗?

回到方舟编译器上，由于目前华为还没有开源代码，关于其到底是如何实现系统操作流畅度提升24%，系统响应速度提升44%的效果，暂时还无法明确。不过，华为可能采用的路径差不多有三条，其一，是继续在目前Android这套AOT+JIT+解释执行的基础上进行优化，继续在应用安装后，后台静默编译成机器码的路子上前进，只不过华为工程师实力出色，让方舟编译器成为了一个“顶级翻译”。

其二，是学习iOS采用的LLVM编译器的模式，将App在开发阶段就通过服务器完成，让服务端或者云端完成本来需要手机本地的工作。使得App变成可安装的APK文件时，直接就把Java代码编译为了机器码。

其三，是方舟编译器虽然是叫着编译器的名字，但实质上是将编译器和Runtime(指将数据类型的确定，由编译时推迟到了运行时)全部替换成华为自己的解决方案。

由于Android需要更高的兼容性，因此在现有Android策略的基础上提升效率的意义其实并不大，并且第一种可能就代表着华为这次的宣传只是微创新。

其他两种猜测的可能性则相对较高，而第二种也就是打包APK的时候，就直接变成机器码的策略，因为ARM架构的不同世代之间与不同厂商魔改会产生兼容性问题，进而削弱App的跨平台能力，与Android本身的高兼容性南辕北辙。但是，华为也在发布会上强调，需要“在华为自己的应用商店下载App”，换句话来说是可能会选择牺牲兼容性，来提升流畅度。

如果第三种猜测属实，替换Runtime基本上则代表了华为这次是实实在在的“分裂Android”。根据谷歌在2012年修改的Android开发协议的新条款显示，“你同意将不会采取任何可能造成Android分裂的行为，包括但不限于：发布、参与创建，或者以任何方式从SDK派生其他的软件开发工具。”

考虑到P30系列的海外发布会上并没有公布方舟编译器，而是选择在国内首发，因此未尝就没有利用GMS服务没有进国内市场的空子。考虑到华为想要打造自家OS已经不是一个新闻了，因此推出一套属于自己的底层开发标准，也并不是不能理解。

但就像之前说的那样，一个操作系统想要成功，最主要是在底层之上的中间层、应用层上，搭建属于自己的各式接口和服务，需要说服尽可能多的开发者支持，完成操作系统的主流化，而之前WindowsMobile和BlackBerryOS的失败，也几乎都是死在这一步上。方舟编译器就相当于是在Android系统的基础上，实现“忒修斯之船”的操作，通过数年的过渡将.APK慢慢变成.HUAWEI。

至于说分裂Android的行为可能引来谷歌的制裁，其实并不是一个大问题。除了谷歌自己也开始准备全新的FuchsiaOS之外，去年才刚刚因为Android强制捆绑的GMS服务，吃了欧盟一张大罚单，被迫改变了Android的商业模式。因此谷歌用取消GMS服务来制裁华为，很难在除美国之外的地区获得支持，但华为手机又根本就不在美国市场销售。

当然，以上均为我们不负责任的猜测，至于方舟编译器的具体情况，则还有待华为方面将代码公布出来之后，才能见分晓了。