抱歉,你查看的文章不存在

什么?华为方舟编译器竟然这么牛逼~

本文作者weishu&&懒虫,非鱼哥原创,内容授权请联系原作者,内容来源知乎https://www.zhihu.com/question/319688167

华为在P30发布会上,本来是发布手机产品的,顺带提了下,即将开源的方舟编译器,大家反而对这个方舟编译器的兴趣大于了P30手机。小编今天带大家来唠嗑下方舟编译器。

安卓性能革命,提升操作系统流畅度和系统响应。到底有多流畅,看下测试视频:

方舟编译器,应该是取自诺亚方舟。华为还有一个部门叫“2012实验室”,在华为内部有着非常高的地位。海思就是2012实验室底下的二级部门之一。看得出来华为具有非常强烈的危机意识。方舟编译器的战略地位应该跟麒麟芯片差不多吧,二者可以类比一下。华为海思的麒麟芯片,从十来年前就开始开发,早期完全是赔本在做,拿钱换经验。在友商喜滋滋地用着高通和MTK芯片占据市场份额时,华为推出的早期手机芯片表现非常差,被用户和网友骂了个狗血淋头。但是华为依然在坚持着设计并使用自己的CPU(2014年推出麒麟芯片开始),哪怕差也不妥协用高通。

直到近几年,华为终于尝到了自研芯片的甜头。在友商们为了个骁龙855首发争个不停的时候,华为已经在一边自己玩去了(不止是手机CPU,其它如WIFI芯片,华为也在逐步用海思芯片替换国外公司的产品)。至此,硬件方面的诺亚方舟可以说基本建成,虽然还需要国外的桅杆、船桨等配件,但基本的船身和发动机已经替换成自己的东西,未来即使国外禁售,小破船也能继续开下去。软件方面安卓系统离不开谷歌,虽然目前安卓还是开源系统,谷歌还不对手机厂商收费。但万一收费了呢?个人估计方舟编译器就是华为在手机软件层面打造的诺亚方舟。通过提升编译效率,体现在系统流畅度上,吸引更多的安卓手机厂商来使用方舟编译器,逐渐撬松谷歌对于安卓系统的掌控力度。如果哪一天,谷歌在安卓系统上直接卡住手机厂商的脖子,那么华为就会呼吁大家去他那儿。虽然华为这船不比谷歌大,但好歹不会淹死,再集众人之力,打造一个新的开源手机生态。(来源知乎:懒虫,出处:https://www.zhihu.com/people/dqdong)

Android 平台的绝大多数应用是使用 Java 语言写的,CPU 只能理解汇编指令,无法直接识别 Java 语言的虚拟机指令;为了让 CPU 能运行 Java 语言编写的程序,一般有两种办法:

1、「计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决」 引入一个中间层,这个中间层负责 Java代码的执行,然后这个中间层本身编译为 CPU 能理解的汇编指令,也就是 CPU -> 中间层 -> Java 代码。如果这个中间层采用 Java 语言直接作为输入,理解一句 Java 语句就把Java语言翻译一下让CPU 执行一段,我们一般称这种模式为「解释执行」。毋庸置疑这种方式效率是相当低效的。

2、直接把 Java 语言翻译成 CPU 能理解的机器语言。这里又有两种方式: 在程序运行之前直接把 Java 代码编译为机器语言。这种模式我们称之为 AOT (Ahead of time)编译。

在程序运行起来之后,实时地把 Java 语言编译为机器语言然后执行。这种模式称之为 JIT(Just in time) 编译。

背景介绍完了回到 Android 平台上面,Android 平台分为几个阶段:

1、在 Android 5.0 正式采用 ART 之前,Android 采用的是 解释执行 + 辣鸡 JIT 的方式执行 Java代码。在这个阶段是货真价实的「边解释边执行」的模式,代码效率相当低下,再加上那时候同样辣鸡的 GC (垃圾回收),Android 用起来真是惨不忍睹。

2、Android 5.0 ~ Android 6.0 。Google 推出了 ART (Android Runtime)来解决之前的 Java 代码执行效率问题。这个阶段采用的是完全 AOT 模式;Android 应用在安装的时候,系统会把所有Java代码提前编译为机器码。这种模式有两个缺点不能忍:

  • 安装速度巨慢。即使是现在吊炸天的 855 采用 AOT 模式编译一下安装包比较大的应用(如支付宝)可能就要一分钟。那个时候的 CPU 可不如现在,安装一个应用都让你等得头皮发麻。更要命的时候,系统 OTA 开机会对所有的应用执行 AOT 操作,这时候你的开机速度可能要半个小时。。。
  • 占用磁盘空间,Java 代码编译为机器码之后体积会急剧膨胀。

3、Android 7.0 ~ 现在。Google做了很大的改进,基于这样一个事实:我们使用一个应用的时候,基本每个人只使用它一小部分功能,为什么要把所有代码全编译呢?只编译你经常用的那部分代码不就 OK 了,这样安装的时候啥也不干速度飞快,等你用的时候系统就能知道哪部分代码经常被执行,把这部分代码编译为机器码,运行起来速度也快。于是 Google 又引入了 JIT,这时候的执行模式是 AOT + JIT + 解释执行。

  • 应用安装的时候不执行 AOT 编译,安装速度飞快。初次使用应用的时候没有机器码,因此只能解释执行。
  • 应用运行起来之后,系统收集经常被运行的代码的信息,做两件事:1)在必要的时候在运行时直接把 Java 代码编译为机器码 (JIT),然后使用机器码执行提高运行效率。2)把这个「经常被运行的代码信息保存起来」
  • 设备空闲的时候,系统拿出应用运行时候保存的「热点代码信息」直接把这些代码编译为机器码 (AOT)

关于 Android 7.0 系统的演进可以参阅这里:http://s3.amazonaws.com/connect.linaro.org/las16/Presentations/Tuesday/LAS16-201%20-%20ART%20JIT%20in%20Android%20N.pdf

Android 8.0上改进了解释器,解释模式执行效率大幅提升;Android 10.0上提供了预先放置热点代码的方式,应用在安装的时候就能知道常用代码会被提前编译。可以看到,当前 Android 平台的执行模式在空间占用+安装速度+运行速度上已经达到了一个很好的平衡。

回到华为的这个方舟编译器上面,

1、现在的 Android 是边解释边执行的吗?可以说是,也可以说不是。上面我已经提到了,现在的 Android 是 解释执行 + 还算可以的JIT + AOT 的模式。并且,你也可以手动把应用的代码全部提前编译达到完全 AOT 的效果(很多答案里面提到的 AOT 就是说的这种);不过这属于开倒车,Google 肯定不会这么做。这样做效果有多大呢?这个我有发言权。之前在支付宝做性能优化的时候,我干过这么一回事:让应用在后台运行的时候请求系统直接采用 everything 模式编译支付宝,本地测试启动速度有爆炸性提升(30%~50%);但是灰度测试的时候效果不明显,为什么呢?其一是后台全编译运行成功率低,其二是系统的 JIT + 后台 AOT 不是吃素的;考虑到耗电/占空间的问题压根没上线。所以如果华为只是简单地用这种方式去避免所谓的「边解释边执行」那就相当滴 low,但是按照 GPU Turbo这种黑科技来看,我觉得不太可能是这个。

2、除了 Android 系统的这种 AOT 之外,难道没有别的办法了吗?我不负责任地猜测一下,方舟编译器是不是在Android 应用打包成APK的时候,直接把 Java 代码编译为了机器码?注意这个跟Android系统的那个 AOT 是不样的,系统是在应用安装或者系统空闲的时候做编译;这种方式你下载到的安装包就是编译好的了,不需要系统动手。(来源知乎:weisu,出处:https://www.zhihu.com/people/tian-weishu)

原文发布于微信公众号 - 何俊林(smartyuge)

原文发表时间:2019-04-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

编辑于

码农突围

0 篇文章93 人订阅

扫码关注云+社区

领取腾讯云代金券