APK的编译过程
我们的项目是如何构建成APK的呢？ 在解释这个问题之前，先看一下google官方的一张流程图
build-process_2x.png
根据上面的图，我们大概可以知道
- 编译器将我们编写的代码和一些第三方的代码编译成
DEX文件 - 然后将这个
DEX文件和资源文件组合成APK - 当然
APK需要签名才能正常的发布在手机上
APK的解析过程
我们正常的编译出一个APK，将APK安装到手机中，然后运行起来。这个时候就会出现一个这样的问题，什么时候去获取APK中的DEX文件呢（可执行文件）？
在回答这个问题之前，我们需要对一些概念进行补充。
## 一些英文单词
JIT = just in time (即时编译)
AOT = ahead of time (提前编译)
Dalvik 和 Android RunTime
那还是很久的时候 （Android 2.2），Dalvik担任虚拟机角色。 而 Dalvik 使用了（JIT）即时编译技术。来编译DEX为机器码。即时编译技术存在有一些缺陷。
- 每次启动应用都需要重新编译
- 运行时比较耗电，造成电池额外的开销
就这样，我们一直使用者Dalvik到（Android 5.0）. Google 推出了Android运行时（ART）来承担虚拟机的角色从而替换之前的Dalvik，也更改了之前的编译模式JIT为AOT。AOT通过提前编译DEX并且缓存编译后的机器码。从而修复了JIT所存在的问题。会存在有一些其它的问题。
- 应用的安装时间会变长
- 机器码占用的存储空间更大。
一直忍受的安装时间缓慢的问题到（Android 7.0),Google又对编译模式进行修改。这次的修改是使用混编的模式。JIT和AOT混编。从而解决的单独模式在的问题
- 应用在安装的时候
DEX不会被编译 - 手机进入空闲的时候，系统进行
AOT进行编译 -
JIT编译了一些代码后将这些代码保存到本地
运行 APP
我们点击了桌面上的图标，这个时候system_server接受到打开新进程的请求，会通知Zygote fork 新的进程。 为什么是Zygote来 fork 新的进程呢？ 因为Zygote 它的内存空间包含所有应用程序需要的核心库，但它还不包含任何特定于特定应用程序的代码。意味着你的程序启动的更快了！
终于运行起来了
image.png
