apk文件结构
assets
需要打包到Android应用程序的静态资源文件，资源不会变。
res中也是资源，但assets支持任意深度的子目录，意思就是里面还可以文件夹。
也不像res里面有资源id
res
如上，资源有id，是应用的资源文件。
lib
当前app所用的到的so文件，利用底层c，cpp代码实现。
可以理解为native，依赖库，有点像dll。
META-INF
所用到的证书签名文件MAINFEST.MF（摘要文件）。遍历apk内非文件夹非签名文件，逐个sha1，base64，校对校验信息。
CERT.SF，对MAINFEST.MF利用SHA-RSA对开发者的私钥进行签名，只有公共密钥才能解密。
INDEX.LIST APK索引目录。
CERT.RSA公钥信息，加密算法。
AndroidManifest.xml
可以理解成apk的一个介绍吧，系统清单文件，四大组件均在此配置并说明。
classes.dex
可执行文件。如果方法超过65535，会有多个dex，进行了分包处理。
所有代码均在此，可以通过反编译工具dex2jar转化成jar，再jd-gui查看代码。
resources.arsc
资源索引列表，描述具有ID值的资源的配置信息。
诸如此类
apk打包流程
下图就是大致流程，其中R.java理解成资源索引，3rd party lib理解成一些第三方的支撑函数，有点像dll，other resources就是之前的assets中的内容，debug or release key store是一些加密需要的东西。
apk安装流程
首先在data/app，以包名创建文件夹，并扫描出安装包，解析apk里面的资源文件，解析AndroidManifest.xml，再在data/data里面创建一个对应包名的文件夹。
对dex文件进行优化，保存在/data/dalvik-cache/下面某个目录里面。
然后把上面AndroidManifest.xml解析的四大组件信息注册到PackageManagerService，发送一条广播。
总的来说
拷贝apk。
解析apk 主要解析AndroidManifest.xml，获取安装信息，用户组id等。
虚拟机
jvm
java生成字节码在它上面跑，变成当下机器对应的字节码，屏蔽了底层的差异，达成一段代码多端跑的目的。
基于栈架构
dvm
jit机制
dalvik虚拟机，其中的所有dvm字节码由java字节码转换来，打包到dex可执行文件当中。
每个进程对应一个dvm实例，提供生命周期管理等等管理。
ART虚拟机
aot机制
总结
两者差异
三者前三项操作一致，但是获取路径不同。
下图这个就是5以上，用的art
