华为造方舟,安卓的性能革命或将拉开帷幕

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

  • 华为造了一个“方舟”

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

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

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

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

  • Android编译器的发展历程

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

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

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

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

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

到了Android 7.0之后,谷歌重新引入了JIT编译技术,形成了AOT+JIT+解释执行共存的模式。也免除了单独使用某一种解决方案带来的缺陷,解释执行是为了辅助优化AOT结果,避免进行无脑的全量编译,而JIT则是为了对ART进行代码分析,使其能够在运行时动态优化。并且在Android Q上,谷歌结合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已经不是一个新闻了,因此推出一套属于自己的底层开发标准,也并不是不能理解。

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

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

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

【本文图片来自网络】

推荐阅读:

虽非首发,但国行版华为P30系列却有更多干货

昨天在国内发布的P30系列机型,华为依旧带来了不少干货。

“挖矿”即将凉凉,这回可能真的是币圈末日了

虚拟货币再次迎来噩耗,但区块链技术却无需担心。

(0)

相关推荐