编译和运行APP

APK的编译过程

我们的项目是如何构建成APK的呢？ 在解释这个问题之前，先看一下google官方的一张流程图

build-process_2x.png

根据上面的图，我们大概可以知道

1. 编译器将我们编写的代码和一些第三方的代码编译成DEX文件
2. 然后将这个DEX文件和资源文件组合成APK
3. 当然APK需要签名才能正常的发布在手机上

APK的解析过程

我们正常的编译出一个APK，将APK安装到手机中，然后运行起来。这个时候就会出现一个这样的问题，什么时候去获取APK中的DEX文件呢（可执行文件）？

在回答这个问题之前，我们需要对一些概念进行补充。

 ##  一些英文单词
 JIT = just in time (即时编译)    
 AOT = ahead of time (提前编译)

Dalvik 和 Android RunTime

那还是很久的时候 （Android 2.2），Dalvik担任虚拟机角色。 而 Dalvik 使用了（JIT）即时编译技术。来编译DEX为机器码。即时编译技术存在有一些缺陷。

1. 每次启动应用都需要重新编译
2. 运行时比较耗电，造成电池额外的开销

就这样，我们一直使用者Dalvik到（Android 5.0）. Google 推出了Android运行时（ART）来承担虚拟机的角色从而替换之前的Dalvik，也更改了之前的编译模式JIT为AOT。AOT通过提前编译DEX并且缓存编译后的机器码。从而修复了JIT所存在的问题。会存在有一些其它的问题。

1. 应用的安装时间会变长
2. 机器码占用的存储空间更大。

一直忍受的安装时间缓慢的问题到（Android 7.0),Google又对编译模式进行修改。这次的修改是使用混编的模式。JIT和AOT混编。从而解决的单独模式在的问题

1. 应用在安装的时候 DEX 不会被编译
2. 手机进入空闲的时候，系统进行 AOT 进行编译
3. JIT 编译了一些代码后将这些代码保存到本地

运行 APP

我们点击了桌面上的图标，这个时候system_server接受到打开新进程的请求，会通知Zygote fork 新的进程。 为什么是Zygote来 fork 新的进程呢？ 因为Zygote 它的内存空间包含所有应用程序需要的核心库，但它还不包含任何特定于特定应用程序的代码。意味着你的程序启动的更快了！

终于运行起来了

image.png