TGFC Lifestyle - Powered by Discuz! Board

标题: [数码手机] 关于菊花那个方舟编译器 [打印本页]

作者: u571 时间: 2019-4-12 08:52 标题: 关于菊花那个方舟编译器

我就搞不懂了，ART不是早就是静态编译成本地机器码，怎么来的边编译边运行的说法？

难道是说可以把APP中的HTML5代码静态编译？这不是需要网站和开发者支持才行的吗？

作者: Sanguinius 时间: 2019-4-12 10:06

posted by wap, platform: Android
现在android不是你想的简单直接art那样。
华为这个敢开源，如果就是个art，这是准备送死吗？

转个知乎上应该有点水平的android开发者写的回答：

看到问题下许多答案有误导，忍不住出来解释一下。

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

「计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决」引入一个中间层，这个中间层负责 Java代码的执行，然后这个中间层本身编译为 CPU 能理解的汇编指令，也就是 CPU -> 中间层 -> Java 代码。如果这个中间层采用 Java 语言直接作为输入，理解一句 Java 语句就把Java语言翻译一下让CPU 执行一段，我们一般称这种模式为「解释执行」。毋庸置疑这种方式效率是相当低效的。
直接把 Java 语言翻译成 CPU 能理解的机器语言。这里又有两种方式：
在程序运行之前直接把 Java 代码编译为机器语言。这种模式我们称之为 AOT （Ahead of time）编译。
在程序运行起来之后，实时地把 Java 语言编译为机器语言然后执行。这种模式称之为 JIT（Just in time）编译。
背景介绍完了回到 Android 平台上面，Android 平台分为几个阶段：

在 Android 5.0 正式采用 ART 之前，Android 采用的是解释执行 + 辣鸡 JIT 的方式执行 Java代码。在这个阶段是货真价实的「边解释边执行」的模式，代码效率相当低下，再加上那时候同样辣鸡的 GC （垃圾回收），Android 用起来真是惨不忍睹。
Android 5.0 ～ Android 6.0 。Google 推出了 ART （Android Runtime）来解决之前的 Java 代码执行效率问题。这个阶段采用的是完全 AOT 模式；Android 应用在安装的时候，系统会把所有Java代码提前编译为机器码。这种模式有两个缺点不能忍：
安装速度巨慢。即使是现在吊炸天的 855 采用 AOT 模式编译一下安装包比较大的应用（如支付宝）可能就要一分钟。那个时候的 CPU 可不如现在，安装一个应用都让你等得头皮发麻。更要命的时候，系统 OTA 开机会对所有的应用执行 AOT 操作，这时候你的开机速度可能要半个小时。。。
占用磁盘空间，Java 代码编译为机器码之后体积会急剧膨胀。
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 平台的执行模式在空间占用+安装速度+运行速度上已经达到了一个很好的平衡。

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

现在的 Android 是边解释边执行的吗？可以说是，也可以说不是。上面我已经提到了，现在的 Android 是解释执行 + 还算可以的JIT + AOT 的模式。并且，你也可以手动把应用的代码全部提前编译达到完全 AOT 的效果（很多答案里面提到的 AOT 就是说的这种）；不过这属于开倒车，Google 肯定不会这么做。这样做效果有多大呢？这个我有发言权。之前在支付宝做性能优化的时候，我干过这么一回事：让应用在后台运行的时候请求系统直接采用 everything 模式编译支付宝，本地测试启动速度有爆炸性提升（30%~50%）；但是灰度测试的时候效果不明显，为什么呢？其一是后台全编译运行成功率低，其二是系统的 JIT + 后台 AOT 不是吃素的；考虑到耗电/占空间的问题压根没上线。所以如果华为只是简单地用这种方式去避免所谓的「边解释边执行」那就相当滴 low，但是按照 GPU Turbo这种黑科技来看，我觉得不太可能是这个。
除了 Android 系统的这种 AOT 之外，难道没有别的办法了吗？我不负责任地猜测一下，方舟编译器是不是在Android 应用打包成APK的时候，直接把 Java 代码编译为了机器码？注意这个跟Android系统的那个 AOT 是不样的，系统是在应用安装或者系统空闲的时候做编译；这种方式你下载到的安装包就是编译好的了，不需要系统动手。
如果是第一种，辣鸡华为。如果是第二种，吊炸天！！！当然还有别的可能，不管咋样，静待开源：）

作者: yfl2 时间: 2019-4-12 10:41

posted by wap, platform: Samsung
那是不是可以理解为，一个app在安卓上会越用越快？没感觉到啊……

作者: 卖哥 时间: 2019-4-12 10:43

posted by wap, platform: Meizu M9
需要开发者来用，很明显是直接编译成arm指令，毫无技术含量。

作者: wpxgod 时间: 2019-4-12 11:42

https://www.bilibili.com/video/av48998130
https://www.bilibili.com/video/av49040234
https://www.bilibili.com/video/av49029841

作者: wpxgod 时间: 2019-4-12 11:43

引用:

原帖由卖哥于 2019-4-12 10:43 发表
posted by wap, platform: Meizu M9
需要开发者来用，很明显是直接编译成arm指令，毫无技术含量。

效果这么明显却毫无技术含量为什么之前谷歌不搞呢？

作者: 卖哥 时间: 2019-4-12 11:45

posted by wap, platform: Meizu M9

引用:

原帖由 @wpxgod 于 2019-4-12 11:43 发表
效果这么明显却毫无技术含量为什么之前谷歌不搞呢？

谷歌搞了呀，安卓1.0就有的东西。

作者: 卖哥 时间: 2019-4-12 12:15

posted by wap, platform: Meizu M9
就是谷歌的ndk。

作者: matao 时间: 2019-4-12 12:18

posted by edfc, platform: iPhone 8 Plus

引用:

原帖由 @卖哥于 2019-4-12 12:15 发表
posted by wap, platform: Meizu M9
就是谷歌的ndk。

喷了，你懂技术么，在这胡乱说

作者: 默读忧伤 时间: 2019-4-12 12:35

微软.NET Ngen了解一下，2000年初就有的技术了，吹个屁啊

作者: 卖哥 时间: 2019-4-12 12:38

posted by wap, platform: Meizu M9

引用:

原帖由 @默读忧伤于 2019-4-12 12:35 发表
微软.NET Ngen了解一下，2000年初就有的技术了，吹个屁啊

是类似art的东西，方舟还要落后。

作者: tobewind 时间: 2019-4-12 12:39

posted by wap, platform: Android

引用:

原帖由 @matao 于 2019-4-12 12:18 发表
posted by edfc, platform: iPhone 8 Plus

喷了，你懂技术么，在这胡乱说

爱跑火车的卖哥常规操作

作者: Minstrelboy 时间: 2019-4-12 12:42

posted by wap, platform: Android
华为垃圾，纯粹靠洗脑

作者: 藕是张力 时间: 2019-4-12 16:08

posted by wap, platform: iPhone
iOS 是什么方式？

直接安装包就是机器码吧

作者: 卖哥 时间: 2019-4-12 16:13

posted by wap, platform: Meizu M9

引用:

原帖由 @藕是张力于 2019-4-12 16:08 发表
iOS 是什么方式？

直接安装包就是机器码吧

是的，iso应用发行的就直接是编译好的。

作者: yfl2 时间: 2019-4-12 16:18

posted by wap, platform: iPad

引用:

原帖由 @卖哥于 2019-4-12 16:13 发表
是的，iso应用发行的就直接是编译好的。

只要开发商愿意，安卓也可以吧，类似用c开发的安卓游戏

作者: 卖哥 时间: 2019-4-12 16:22

posted by wap, platform: Meizu M9

引用:

原帖由 @yfl2 于 2019-4-12 16:18 发表
只要开发商愿意，安卓也可以吧，类似用c开发的安卓游戏

是啊，ndk是现成的。

作者: yfl2 时间: 2019-4-12 16:24

posted by wap, platform: iPad

引用:

原帖由 @卖哥于 2019-4-12 16:22 发表
是啊，ndk是现成的。

主流的软件中哪些是预编译的？其他软件不这么弄的原因是什么？

作者: 卖哥 时间: 2019-4-12 16:31

posted by wap, platform: Meizu M9

引用:

原帖由 @yfl2 于 2019-4-12 16:24 发表
主流的软件中哪些是预编译的？其他软件不这么弄的原因是什么？

软解视频的软件肯定是的，安卓早期硬解不完善，有一类软件，需要根据使用的cpu型号分别下不同的版本，现在视频类其实也是只不过是一个应用内置多套原生代码根据识别cpu类型来切换。
系统自带应用应该也是的。
还有部分游戏应该也是的。
基本上就是兼容问题吧，那就要付出软件体积的代价，一般公开发行也就游戏或者像是软解这类极度吃性能靠虚拟机根本跑不动没办法才这么做。

作者: ff_cactus 时间: 2019-4-12 16:53

posted by wap, platform: iPhone

引用:

原帖由 @卖哥于 2019-4-12 16:31 发表
软解视频的软件肯定是的，安卓早期硬解不完善，有一类软件，需要根据使用的cpu型号分别下不同的版本，现在视频类其实也是只不过是一个应用内置多套原生代码根据识别cpu类型来切换。
系统自带应用应该也是的。
还有部分游戏应该也是的。
基本上就是兼容问题吧，那就要付出软件体积的代价，一般公开发行也就游戏或者像是软解这类极度吃性能靠虚拟机根本跑不动没办法才这么做。

又跑来这里装逼了？

你造的谣不打算圆个场了吗？233333，太LOW。

作者: zlw 时间: 2019-4-12 17:11

安卓并不全是java写的。需要效率的部分用编译好的本地代码很正常。

重复执行次数少的代码，比如界面逻辑，用java写成本低。然后java效率大概一直靠jit之类（就是模拟器里面的动态重编译）的技术提高。我不知道有没有把一个apk包转换成另一个完整的全本地代码的apk包的实现，想起来应该略难。我能想到的静态编译，可能还是保留一个支持jit的vm（而不是让一个整体翻译后的代码直接跑），只是不需要运行时翻译代码（load已经编译好的本地代码段）而已。

当然这都是想象，从来没仔细查过谷歌的东西，更不知道华为的了。不过华为假如要开发者干预的话，确实可能能更容易实现更高效率，不过也要看开发者鸟不鸟他。

作者: 卖哥 时间: 2019-4-12 17:28

posted by wap, platform: Meizu M9

引用:

原帖由 @zlw 于 2019-4-12 17:11 发表
安卓并不全是java写的。需要效率的部分用编译好的本地代码很正常。

重复执行次数少的代码，比如界面逻辑，用java写成本低。然后java效率大概一直靠jit之类（就是模拟器里面的动态重编译）的技术提高。我不知道有没有把一个apk包转换成另一个完整的全本地代码的apk包的实现，想起来应该略难。我能想到的静态编译，可能还是保留一个支持jit的vm（而不是让一个整体翻译后的代码直接跑），只是不需要运行时翻译代码（load已经编译好的本地代码段）而已。

当然这都是想象，从来没仔细查过谷歌的东西，更不知道华为的了。不过华为假如要开发者干预的话，确实可能能更容易实现更高效率，不过也要看开发者鸟不鸟他。

我猜测到时间部分华为自家市场里的应用会变成方舟版的。

作者: 流浪的枪骑兵 时间: 2019-4-12 17:45

我觉得吧，人家源码还放没出来，评价人家好坏是不是有点太早了？
客观讲，视频里的效果看起来是很牛X，不过凡事皆有代价，这个代价如果是兼容性的话，这东西的实用性就大打折扣了。
一切还得等华为把源码放出来再说，反正华为号称过是要放出来的。

作者: 藕是张力 时间: 2019-4-12 18:04

posted by wap, platform: iPhone
兼容性没问题，兼容所有华为机器即可

作者: masterfish 时间: 2019-4-12 18:18

posted by wap, platform: Android

引用:

原帖由 @流浪的枪骑兵于 2019-4-12 17:45 发表
我觉得吧，人家源码还放没出来，评价人家好坏是不是有点太早了？
客观讲，视频里的效果看起来是很牛X，不过凡事皆有代价，这个代价如果是兼容性的话，这东西的实用性就大打折扣了。
一切还得等华为把源码放出来再说，反正华为号称过是要放出来的。

华为要求app厂商重新编译上传她的store，这样就没有兼容性的问题了。换句话来说，每个手机大厂都这样搞，首先性能效率就不输apple了，其次流氓软件也可以被控制了。

作者: 分分钟叫你做人 时间: 2019-4-12 18:48

posted by wap, platform: 小米5
简单说就是，可能在打包的时候就先编译了，不需要再在你手机上边执行边编译了。

跟玩gba烧录卡似的。如果采用把游戏拷贝到tf卡上，插卡玩游戏时，再把tf卡的游戏写到rom里，这样做好处是拷游戏方便，u盘插tf卡就能拷。缺点是烧录是在gba上运行，玩游戏或切换游戏需要花时间和耗电！

如果是那种火线烧录卡，直接在拷贝游戏时，由电脑直接烧录游戏到rom，这样插卡玩游戏或切换游戏时，不需要等待，没有额外耗电！

所谓黑科技，也就跟gba烧录游戏类似吧。把编译的过程，甩给电脑打包去做，程序安装好了，直接就能高效的运行。大概就这么个意思。

作者: 卖哥 时间: 2019-4-12 19:37

引用:

原帖由 masterfish 于 2019-4-12 18:18 发表
posted by wap, platform: Android
华为要求app厂商重新编译上传她的store，这样就没有兼容性的问题了。换句话来说，每个手机大厂都这样搞，首先性能效率就不输apple了，其次流氓软件也可以被控制了。

流氓软件效率更高了。

作者: fatehe 时间: 2019-4-12 19:44

posted by edfc, platform: iPhone 8
就是自己深度定制的系统吧，你得用我的开发包来打包APP，才能在我的系统跑流畅？

作者: wangmax 时间: 2019-4-12 20:41

感觉是讨论偏了，有个根本概念错误，只要是机器码效率就高，不是的，机器码也有代码质量的差别。
举个例子，iOS 的ipa，通过OC、swift可以开发编译打包出来，而通过C#在Xamarin中也可以开发打包ipa，还有java在Codename One里、AS3在AIR里，都可以编译打包出ipa，它们都是可以在iOS运行的机器码。
全都是机器码，但其他几个效率惨不忍睹，体积也各自差别很大。这些和苹果官方的oc在cocoa touch 下编译的机器码根本没法比。
所以核心问题是编译后的代码质量，而不仅仅是JIT还是AOT的方式问题。

作者: 阿喀牛斯 时间: 2019-4-12 20:48

引用:

原帖由 yfl2 于 2019-4-12 16:24 发表
posted by wap, platform: iPad
主流的软件中哪些是预编译的？其他软件不这么弄的原因是什么？

Posted by TGFC·NG
ndk需要给每一个平台独立开发，调试，现在安卓一共有数万个碎片机器，java版本可以完全适配，不管是arm还是x86，mips，电视还是手机，车载中控还是后视镜，都可以用同一套代码

作者: yfl2 时间: 2019-4-12 20:52

引用:

原帖由 阿喀牛斯 于 2019-4-12 20:48 发表

Posted by TGFC·NG
ndk需要给每一个平台独立开发，调试，现在安卓一共有数万个碎片机器，java版本可以完全适配，不管是arm还是x86，mips，电视还是手机，车载中控还是后视镜，都可以用同一套代码

类比pc平台，为什么win程序就没有这个问题，只要在os层面兼容，就可以预编译好呢？

作者: 阿喀牛斯 时间: 2019-4-12 21:02

引用:

原帖由 yfl2 于 2019-4-12 20:52 发表

类比pc平台，为什么win程序就没有这个问题，只要在os层面兼容，就可以预编译好呢？

Posted by TGFC·NG
win有这个问题啊，exe只能在x86的win上运行，不能在arm的win上用

作者: 卖哥 时间: 2019-4-12 21:05

posted by wap, platform: Meizu M9

引用:

原帖由 @yfl2 于 2019-4-12 20:52 发表
类比pc平台，为什么win程序就没有这个问题，只要在os层面兼容，就可以预编译好呢？

要么仗着性能足够强，无所谓效率，能跑就行
要么仗着容量足够大，准备一堆根据cpu不同来分别调用的dll。

作者: 耶稣复临 时间: 2019-4-12 21:08

posted by wap, platform: Samsung
听听名字，方舟，不就是为了发大水的时候带着国产app自己跑路不至于死么？但是这么一来，软件生态怎么搞，华为os？中国独供？

作者: wangmax 时间: 2019-4-12 21:08

通过NDK用纯C/C++开发，主要是图形类应用，比如游戏，这种都是不太需要系统功能组件 API的，NDK的API最好用的是OpenGL，其他API种类非常有限。
因为谷歌根本就没打算开放所有native接口让你玩C/C++，这个是商业策略问题，不是技术问题。

作者: 黑暗骑士巫妖王 时间: 2019-4-12 21:26

posted by wap, platform: Chrome

引用:

原帖由 @阿喀牛斯于 2019-4-12 20:48 发表
Posted by TGFC·NG
ndk需要给每一个平台独立开发，调试，现在安卓一共有数万个碎片机器，java版本可以完全适配，不管是arm还是x86，mips，电视还是手机，车载中控还是后视镜，都可以用同一套代码

ndk开发的基本只兼容ARM

作者: 藕是张力 时间: 2019-4-12 21:52

posted by wap, platform: iPhone
就是在安卓框架下，学习iOS的优点呗

作者: 流浪的枪骑兵 时间: 2019-4-13 19:53

引用:

原帖由 masterfish 于 2019-4-12 18:18 发表
posted by wap, platform: Android
华为要求app厂商重新编译上传她的store，这样就没有兼容性的问题了。换句话来说，每个手机大厂都这样搞，首先性能效率就不输apple了，其次流氓软件也可以被控制了。

不是程序员吧
为什么会确信换个编译器还一定能编译过呢？

欢迎光临 TGFC Lifestyle (http://club.tgfcer.com/)