一、编译+解释

java 语言和 iOS 不同，OC 本质是 C语言，经过 Clang 编译前端编译之后生成中间代码，再经过优化后传递给编译后端 LLVM ，根据不同的架构，生成汇编代码后经过汇编，最终生成机器码。

Andriod 因为需要兼容的设备太多，所以只能生成中间代码，完成设备的识别之后再生成机器码来执行。其中，中间代码在 java 中时 .class 文件，在 Andriod 中就是 .dex 文件，而生成机器码的过程就是 Andriod 不断优化提升速度的过程，相对复杂，进程如下：

1. DVM

java 的代码运行在虚拟机中，也就是 DVM。一遍运行代码的同时，解释器对代码进行解释，生成机器码然后运行。因为这个边运行边解释的模式，所以导致 Andriod 早期运行速度很慢。

2. DVM + JIT

朝着 iOS 的直接生成机器码的优化方向进行优化，那就是如何尽可能多的在运行之前生成机器码。

所以，Andriod 2.2 中推出了 JIT，也就是 Just-In-Time，即在 APP 启动之前编译。

很明显，启动之前不可能编译所有的中间代码，所以 JIT 只是在 APP 启动之前编译常用的代码。如此就造成了几个问题：

1. app 启动速度贼慢；
2. 每次 app 启动都要重复编译；
3. 执行到未编译的代码时，还是会很慢；

针对上述几点， Andriod 退出了 ART + AOT

3. ART + AOT

ART 就是 Andriod-Runtime，用于替换虚拟机 DVM。AOT 就是 Ahead-Of-Time，也就是在 APP 安装时进行编译。

ART 如何替换 DVM 似乎值得深究，但是我不懂。

APP 安装时编译就很明显的导致几个问题：

1. app安装缓慢；
2. 手机开机后所有 app 执行 AOT 导致开机缓慢；
3. 刷机后全量 AOT；
4. 系统版本更新后全量 AOT；

除了这些问题，还会导致 AOT 之后应用控件明显增大，不知道这个是不是安卓越用越卡的原因。

因此，Andriod 继续推出了混合编译模式~

4. 混合编译：ART + AOT + JIT

混合编译基本核心就是：手机和 App 空闲时进行编译，运行时如果没有编译完成，那就使用 JIT 编译常用代码。

至此，已经是 Andriod7.0，直到这个时候，Andriod 才算是在一定程度上解决了 Andriod 卡顿的问题。

至于 Andriod 越用越卡这个原因暂时未研究~

5. 解释器优化

后面就属于模板优化的范畴了

6. 编译模板优化

7.

注意：广义的 LLVM 指的是编译的整个过程，也就是前后端的统称，Clang 只是 LLVM 的一个子集。狭义的 LLVM 指的就是编译后端；