Android 平台的绝大多数应用是使用 Java 及Kotlin语言写的，CPU 只能理解汇编指令，无法直接识别编程语言的虚拟机指令，为了让 CPU 能运行 编程语言（ Java 及Kotlin等）编写的程序，一般有两种办法：
AOT （Ahead of time）编译模式：在软件安装的时候把代码编译成机器代码
JIT（Just in time）编译模式：程序运行起来后，实时地把代码编译为机器语言然后执行

Android 平台分为几个阶段：

在Android5.0之前：

采用的是解释执行 + JIT 的方式执行，也就是dalvik模式，这个阶段是货真价实的【边解释边执行】的模式，代码效率相当低下，再加上那时候同样辣鸡的 GC （垃圾回收），Android 用起来真是惨不忍睹。

Android 5.0 ～ Android 6.0 ：

Google 推出了 ART （Android Runtime）来解决之前的 Java 代码执行效率问题。这个阶段采用的是完全 AOT 模式；Android 应用在安装的时候，系统会把所有Java代码提前编译为机器码。

两种种模式对比：

DVM与ART区别

Android 7.0 ～ 现在

Google做了很大的改进，基于这样一个事实：我们使用一个应用的时候，基本每个人只使用它一小部分功能，为什么要把所有代码全编译呢？只编译你经常用的那部分代码不就 OK 了，这样安装的时候啥也不干速度飞快，等你用的时候系统就能知道哪部分代码经常被执行，把这部分代码编译为机器码，运行起来速度也快。于是 Google 又引入了 JIT，这时候的执行模式是 AOT + JIT + 解释执行。
应用安装的时候不执行 AOT 编译，安装速度飞快。初次使用应用的时候没有机器码，因此只能解释执行。
应用运行起来之后，系统收集经常被运行的代码的信息，做两件事：
1）在必要的时候在运行时直接把 Java 代码编译（JIT）为机器码 ，然后使用机器码执行提高运行效率。
2）把这个「经常被运行的代码信息保存起来」
设备空闲的时候，系统拿出应用运行时候保存的「热点代码信息」直接把这些代码编译（AOT）为机器码 。
关于 Android 7.0 系统的演进可以参阅这里：Android 7.0 系统演进

Android 8.0上改进了解释器

解释模式执行效率大幅提升；

Android 10.0

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

方舟编译器：

方舟编译器

除了 Android 系统的这种 AOT 之外，难道没有别的办法了吗？我不负责任地猜测一下，方舟编译器可能是在Android 应用打包成APK的时候，直接把 Java 代码编译为了机器码？注意这个跟Android系统的那个 AOT 是不样的，系统是在应用安装或者系统空闲的时候做编译；这种方式你下载到的安装包就是编译好的了，不需要系统动手。
不管怎样，静待开源 ;-)