关于华为方舟编译器，你怎么看
把ART，方舟编译器和LLVM的拉在一起比一比，顺便驳一驳把ART（Android Runtime） 捧上神坛的观点！
下面这个观点很有市场，6年前的ART已经是机器码了，方舟编译器似乎是新瓶装ART旧酒啊！
ART往往只能静态编译不到20%的机器码
因为Java的动态语义完全啃不动，只能原封不动放在一边，等运行的时侯边解释边运行。
Java 语言定义的语义可以粗略分为静态和动态两部分,动态语义部分是在静态时无法确定的。ART和方舟编译器的两个编译器两者根本的区别在于AOT无法编译 Java的动态语义部分，比如反射。换句话说，ART仅能编译静态部分。由于Java语言独特的虚拟机机制（简称JVM），在运行时，首先在手机上打开虚拟机，然后将应用程序的Java字节码即时编译为机器码，边翻译边执行，执行效率与iOS有了差距。
ART 并非在应用一安装完成的时候就一次把AOT做完，需要应用跑过几次之后才有充足的数据来进行 Profile-guided 的编译工作。并且有些 OEM 会配置 ART 的 daemon 使得设备必须在充电的状态下才能执行 dex2oat 工具编译应用。
ART在Android的实践一直差强人意
Android 5.0 ～ 6.0 ，Google 推出了 ART 来解决之前的 Java 代码执行效率问题。这个阶段采用的是完全 AOT 模式；Android 应用在安装的时候，系统会把所有Java静态语义（动态语义搞不定）提前编译为机器码。这种模式有两个缺点完全不能忍：
首先，安装速度极为慢。哪怕当前的 855 采用 AOT 模式编译较大的应用（如支付宝）可能就要一分钟。更别说当年蜗牛般的 CPU ，安装一个应用都让你等得头皮发麻。更要命的时候，系统开机时会对所有的应用执行 AOT 操作，这时候你的开机速度可能要半个小时……
另外，就是占用ROM空间，Java 代码编译为机器码之后体积会急剧膨胀。就拿微博极速版来说9.5M，安装后直接干到37.5M，臃肿了300%，用有限的手机资源去优化指令，难免不彻底，消费者也没有耐心等你优化啊！
方舟编译器更像LLVM
EMUI9.1对安卓底层动刀背后，是华为与苹果下半场之争
mp.weixin.qq.com
图标
方舟编译器似乎能"100%静态编译动态语义"（从没人做到过）。也就是，甭管你什么语义，我都给你100%的静态化，将Java虚拟机彻底解构，这别说Art 、 Dalvik 等做不到的，纵观整个ICT行业还没人做到过。当然，原理效果有待验证。
对比ATR在手机安装的时候编译，方舟编译器在应用开发阶段就在服务器上编译（含彻底地优化指令）完成，在应用市场上架。节省了宝贵的手机资源，这一点就和LLVM完全一致了。
这里澄清一个概念：虚拟机其实是个好东西，在服务器或云端，大把的CPU，RAM，呼呼的风扇，跑起虚拟机来没一点负担。但手机端侧，CPU，RAM的资源非常有限，“边解释边执行”往往带来大量的随机卡顿。
最后，顺便说一下iOS的LLVM，LLVM在编程阶段就没有JVM（虚拟机机制），从一开始就是冲着100%静态化去的，虽然Swift掌握起来不如Java语言容易，但在运行机制上讲确实是个先天优势。