看了下面不少朋友的回答，大部分都答偏了。
首先亮结论：方舟编译器不会安装在消费者的手机上。
下面来从以下几个维度说明原因。
1. 编译器是什么？
首先要明确的是：编译器是一个通用概念，它不是仅仅针对手机，最早它的对象是计算机。
编译器就相当于一个翻译官，它的作用就是将高级语言（比如Java）编写的代码，转换成在操作系统（比如微软的Windows 10）上可以直接运行的二进制程序（比如QQ.exe）。
1.1 为什么要转换成二进制程序，才能在计算机上运行呢？
因为计算机系统的本质就是一堆开关，通过“开关”状态的改变——闭、合，来触发相应物理特性的变化（电平变化、磁性变化等），达到相互通信的等价效果。而闭、合这两种状态正好可以对应1和0两个数，这样计算机系统就和表示1和0的二进制联系起来了。
无论是CPU，还是内存、鼠标、键盘、硬盘、光盘……它们都基于上述基本原理，笔者的专栏撰写了不少文章，详细介绍了背后的实现方式。
1.2 编译器 vs 解释器
现实世界中，常见的翻译有两种形式：一种是一次性全部翻译，比如翻译的文学著作；
另一种是同声传译，同声传译是一种实时翻译，主讲人说一句或者几句，翻译者同步翻译出来。
回到编译的世界，前者对应编译器，后者对应解释器。
编译器说白了就是一次性把所有的代码翻译成目标平台的二进制，然后运行的时候，直接全速运行。
解释器则是边翻译边运行：读一条或者几条语句，翻译成对应的二进制，然后运行这一部分；接着再读接下来的一条或者几条语句，翻译成对应的二进制，然后再运行接下来的这一部分……以此类推。
从上面的描述可以看出，从最终的运行效率上看，编译器的方式应该是远远超过解释器的，毕竟前者是一次性得到所有的二进制，这样运行的时候就是一股脑地往前冲；而解释器则是边翻译边运行，速度上比应该是要慢不少。
除此之外，因为编译器是一次性翻译，所以它可以纵观全局，找出可以复用、优化的部分，然后加以综合，便于得到全局最优的二进制结果；而解释器由于是边翻译边运行，是一种局部行为，不利于进行全局把控、优化。
传统Java的运行是基于JVM（Java虚拟机）的，JVM其实就是一个加强版的解释器。它引入了JIT及其变种技术。这个技术名词上看上去高大上，其实原理说白了很简单：
大家都知道现实世界都遵循“二八原则”，即：任何领域，少部分的占比贡献或者占据了绝大部分的价值或资源。这个原则在代码领域也同样适用：
有一些代码比较“热门”，会被不断地重用或者调用，比如Java语言里热门的类、方法等。这样在翻译它们的时候，把它们缓存起来，这样解释器再次遇到这些代码的时候，就不用重新再翻译一遍，直接从缓存里取出翻译的结果来就好了。
当然，为了取得更好的优化结果，大家还可以将颗粒度做得更小，比方说大家可以把方法中被频繁调用的循环语句的翻译结果缓存起来。
1.3 为什么Java要基于解释器技术的JVM呢？
既然JVM基于解释器技术，天生就比较慢，那为什么Java还要执着于这种模式20多年呢？或者换句话说，自从Java1995年左右诞生，直到现在，除了华为，难道就没有其他公司想到抛弃JVM，直接采用编译器技术，直接将Java代码编译成原生二进制呢？
基于虚拟机运行的高级语言，比如Java，从代码到最终的二进制执行，其实就是两个阶段：
第一个阶段：代码->中间代码（字节码）
第二个阶段：中间代码（字节码）->二进制
有小伙伴就会挑战了：为什么非要搞出一个中间代码（字节码）呢？这个其实来自Java这样的高级语言的市场营销口号：Wrtie once，Run everywhere（一次编写、到处运行）。
通过Java编译器（Javac）将代码编译成标准的中间代码（字节码）之后，就可以将它部署到任何硬件平台上，只要该硬件平台上有对应的解释器将它在运行时翻译成对应的目标二进制，然后就可以运行了。
通过这种策略，只要每一个硬件平台上有对应的解释器，保证从中间代码（字节码）翻译到二进制的运行效果都一样，那么程序员只用写一套代码就完事了。
更重要的是：只要对中间代码（字节码）的格式、含义等进行了明确的规定、形成规范，那么开发对应硬件平台上的解释器，这个工作就可以交给不同的专业公司去做，从社会分工上也极大提高了效率：
一些公司专注写上层应用程序代码，一些公司专注开发第一个阶段（代码->中间代码）的编译器，一些公司专注制定中间代码（字节码）的规范，另一些公司可以专注开发不同硬件平台上的解释器——有3家硬件平台，就可以交给3家公司去做……
说得再通俗一点就是：创造了更多的就业岗位、大家都有饭吃：）
用流行的行话来说，就是建生态。
如果干掉JVM，那么：
从专注制定中间代码（字节码）规范的公司角度看：
偶的饭碗没了！而且偶最生气，在之前的生态中，偶的话语权最高，现在偶直接被华丽丽地无视了！而且在现实世界中，制定规范的公司往往就是发明和营销该语言的公司，它的感受可想而知。
从专注开发第一个阶段（代码->中间代码）编译器的公司和专注开发第二个阶段（中间代码->二进制）解释器的公司角度看：
没偶啥事了，偶的饭碗没了——就算干掉JVM的新技术中仍然有中间代码的变种，那偶也得重新熟悉新变种，之前开发的东西都得改，这都是成本和风险。
在华为之前，历史上是否有尝试干掉JVM的公司呢？
答案是肯定的。
Java在1995被SUN发明出来之后，运行效率一直被诟病，1997年前后Java JIT技术开始被追捧。Symantec在打败了Borland等竞争对手、取得了JIT 编译器表面上的优势之后，立刻把重点放在了开发直接把 Java中间代码（字节码）编译成原生应用程序的原生Java 编译器。Symantec 成功开发出了这个原生Java编译器之后，加入到当时它最热销的集成开发环境Visual Café 中，成为一项吸引人的功能。不过很快地这个功能却引起了许多Java 使用者的批评，因为他们认为这违反了Java“一次编写、到处运行”的精神，如此一来厂商必须为每一个不同的平台开发原生Java 编译器，这会造成Java 应用程序在不同的平台执行的反应不一致的现象，又陷入C/C++语言开发的应用程序在不同的平台表现不一的相同问题。后来连发明Java的SUN也不赞成这种做法，当然这是因为SUN想力推自己的HotSpot编译器技术。因此原生Java编译器在风行了一阵短暂的时间之后就不再吸引人注意了。
下面再讲一个哪怕没有干掉JVM，只是魔改了JVM也被“修理”的例子。
比尔盖茨在挖到了Borland公司的首席架构师、被业内称为“编译器之神”的Anders Hejlsberg之后，在1996年11月发布了Microsoft Visual J++，该Java编译器的性能超越了同期的所有竞争对手。
但是这款编译器魔改了SUN制定的JVM规范，引入了很多自有创新，比如：
（1）对象模型创新：Sun的JVM的对象模型将“对象头”与对象的实例数据分开存放，而Microsoft Visual J++把两者放在了一起。
（2）使用指针而不是基于句柄的引用：因为Microsoft Visual J++基本上是用C/C++加上汇编写的，可以直接方便地使用指针来高效访问数据，而SUN是用Java来开发JVM的，只能使用句柄。
（3）垃圾收集机制创新：Microsoft Visual J++采用的分代的GC，大幅领先于当时的Sun JVM使用的不分代的GC。
（4）对象同步创新：SUM JVM使用的是哈希表来存放同步对象的映射，每次都需要先将句柄转换成key去查表；而微软采用的是它们在操作系统设计中常用的手法，直接在对象头中放一个同步块的指针，指针访问一步到位。
（5）RNI：直接采用COM技术访问本地接口，而不需要通过SUN定义的接口做二次转换。
Microsoft Visual J++推出之后也很快受到了所有Java 开发工具以及支持Java平台厂商的全面围剿。他们害怕Microsoft对Java市场的入侵，会让其他厂商再次无法生存。之后连SUN也开始领军围攻 Microsoft，因为SUN除了害怕Microsoft 会慢慢地主宰Java 平台和标准之外， 还发现 Microsoft正在很有技巧地逐步破坏Java语言和标准，例如Microsoft Visual J++便提供了许多非标准的Java用法并且很明显地把 Microsoft Visual J++绑死在Windows 平台，破坏 Java 的”一次编写、到处运行”的美梦。
通过上面两个20多年前的经典案例，不难看出：干掉JVM这件事，早有公司做过技术上的成功尝试，但是最终都没能在商业和市场上成功。这里面最关键的阻力在于：动了Java的品牌拥有者（以前是SUN，现在是收购了SUN的Oracle）的蛋糕，而它是Java的亲爹，掌握了“血统的纯正权”和“生态主导权”。根据现有的游戏规则，即便不是干掉JVM，哪怕是提供一个独立的JVM，也必须通过对应的TCK（Java兼容性测试）认证，才能被“合法化”。
2. 方舟编译器的优势是什么？
这个其实在前文已经表达得比较清楚了：直接编译出原生二进制，运行速度快。
但是带来的风险在上一个章节也揭示得很清楚了，这是现在大部分人忽视的地方。
既然干掉JVM的潜在风险不小，那么为什么仍然要力推方舟编译器呢？笔者分析如下：（1）因为方舟编译器本质上是一个通用的编译器框架，该框架理论上可以支持所有的语言，而不仅仅是Java。极端情况下，遭遇类似Symantec或者Microsoft当年受到的打击，也不是“满盘皆输”。
（2）方舟编译器这个框架，从实现上仍然采用了中间代码的技术，所以传统生态中，专注开发第一个阶段（代码->中间代码）编译器的公司和专注开发第二个阶段（中间代码->二进制）解释器的公司仍然可以在方舟生态中找到新的位置。关键在于配合怎样的生态政策和投资政策来吸引它们转型。
（3）基于方舟编译器的开放框架和中间语言技术，可以创造新的编程语言，这样也可以在极端情况下形成“编程语言的备胎”（这个有点杞人忧天了）。
（4）方舟配合鸿蒙等OS，撑大生态喇叭口，增加供应链上的自主控制点。
3. 方舟编译器的使用对象是谁？
它的使用对象是App开发者或者App运营商（App应用商城）。当他们使用方舟编译器将使用Java语言编写的App编译成目标手机硬件平台的二进制之后，就上架到App应用商城，供手机消费者下载。
4. 手机如何被方舟编译器加速？
不是手机被加速，而是App被加速。但这个加速是在上架App应用商城、被手机消费者下载之前就完成了。并没有什么额外“魔法”在消费者的手机上。
5. 方舟编译器的更多细节
关于方舟编译器的更多细节，可以关注笔者的头条号以及头条号付费专栏，里面有全方位的技术干货解读。
