DVM ART 内置APK 32 64 兼容
这篇文章,最基本的理论开始,最后讲遇到问题解决方法
第一部分:odex vdex art 文件
vdex
- package 直接转化的 可执行二进制码 文件:
- 第一次开机就会生成在/system/app/<packagename>/oat/ 下;
- 在系统运行过程中,虚拟机将其 从 “/system/app” 下 copy 到 “/data/davilk-cache/” 下
odex
- odex 是从vdex 这个文件中 提取了部分模块生成的一个新的 可执行二进制码 文件 , odex 从vdex 中提取后,vdex 的大小就减少了。
- 第一次开机就会生成在/system/app/<packagename>/oat/ 下
在系统运行过程中,虚拟机将其 从 “/system/app” 下 copy 到 “/data/davilk-cache/” 下 - odex + vdex = apk 的全部源码
art
- odex 进行优化 生成的 可执行二进制码 文件,主要是apk 启动的热点函数相关地址的记录,方便寻址相关;
- 第一次开机不会生成在/system/app/<packagename>/oat/ 下,以后也不会;
- odex 文件在运行时,虚拟机会计算函数调用频率,进行函数地址的修改;如果频率比较多,就最后在/data/davilk-cache/ 由虚拟机生成;生成art 文件后,/system/app 下的odex 和 vdex 会无效,即使你删除,apk也会正常运行
- push 一个新的apk file 覆盖之前/system/app 下apk file ,会触发PKMS 扫描时下发force_dex flag ,强行生成新的vdex 文件 ,覆盖之前的vdex 文件,由于某种机制,这个新vdex 文件会copy到/data/dalvik-cache/下,于是art 文件也变化了。
第二部分:JVM DVM ART
JVM:JVM虚拟机运行的是java字节码。java -> java bytecode(class) -> java bytecode(jar)。
DVM:DVM虚拟机解析执行的dex字节码。java -> java bytecode(class) -> dalvik bytecode(dex)。
ART:ART虚拟机执行本地机器码。java -> java bytecode(class) -> dalvik bytecode(dex) -> optimized android runtime machine code(oat->art)。
Android--<-Android 4.4-DVM-->ART-->Android 5.0--ART->Android 7.1-> DVM(JIT)&ART---->now
ART所使用的AOT(Ahead-Of-Time)编译,在应用首次安装时,字节码预编译成机器码存在本地
DVM是典型的JIT(Just-In-Time),在此模式下,应用每次运行的时候,字节码都需要即时编译器转换为机器码再执行
第三部分 ART 的运作方式
ART 官方说明
ART 使用预先 (AOT) 编译,并且从 Android 7.0(代号 Nougat,简称 N)开始结合使用 AOT、即时 (JIT) 编译和配置文件引导型编译。所有这些编译模式的组合均可配置,我们将在本部分中对此进行介绍。例如,Pixel 设备配置了以下编译流程:
最初安装应用时不进行任何 AOT 编译。应用前几次运行时,系统会对其进行解译,并对经常执行的方法进行 JIT 编译。
当设备闲置和充电时,编译守护进程会运行,以便根据在应用前几次运行期间生成的配置文件对常用代码进行 AOT 编译。
下一次重新启动应用时将会使用配置文件引导型代码,并避免在运行时对已经过编译的方法进行 JIT 编译。在应用后续运行期间进行了 JIT 编译的方法将会被添加到配置文件中,然后编译守护进程将会对这些方法进行 AOT 编译。
ART 包括一个编译器(dex2oat 工具)和一个为启动 Zygote 而加载的运行时 (libart.so)。dex2oat 工具接受一个 APK 文件,并生成一个或多个编译工件文件,然后运行时将会加载这些文件。文件的个数、扩展名和名称会因版本而异,但在 Android O 版本中,将会生成以下文件:
* .vdex:其中包含 APK 的未压缩 DEX 代码,另外还有一些旨在加快验证速度的元数据。
* .odex:其中包含 APK 中已经过 AOT 编译的方法代码。
* .art (optional):其中包含 APK 中列出的某些字符串和类的 ART 内部表示,用于加快应用启动速度。
第四部分:运行机制
DVM
运行时中,APK在安装的时候,安装服务PackageManagerService会通过守护进程installd调用一个工具 dexopt
对打包在APK里面包含有Dex字节码的classes.dex进行优化,优化得到的文件保存在/data/dalvik-cache目录 中,并且以.odex为后缀名,表示这是一个优化过的Dex文件。
ART
运行时中,APK在安装的时候,同样安装服务 PackageManager Service会通过守护进程installd调用另外一个工具dex2oat
对打包在APK里面包含有Dex字节码进翻译。翻译后得到的是一个ELF格式的oat文件,这个oat文件同样是以.odex后缀结束,并且也是保存在/data/dalvik-cache目录中。
Android在首次启动和首次安装应用时,需要将字节码翻译成机器码,这样Android系统的启动速度将会大大减慢,如果没有预优化,APP的运行速度也会加上翻译所需要的时间。所以,这个翻译的工作需要转移到编译上面来,也就是所,在编译APK文件时,将会预先对APK进行翻译的优化,然后再打包到系统里面去,这样Android系统在首次启动时,就不再需要花费大量的时间去翻译APK的字节码。
第五部分:遇到问题
03-12 10:48:50.247 1381 1381 E AndroidRuntime: Process: com.android.settings, PID: 1381
03-12 10:48:50.247 1381 1381 E AndroidRuntime: java.lang.RuntimeException: Unable to instantiate application com.android.settings.SettingsApplication: java.lang.ClassNotFoundException: Didn’t find class “com.android.settings.SettingsApplication” on path: DexPathList[[zip file “/system/priv-app/Settings/Settings.apk”],nativeLibraryDirectories=[/system/priv-app/Settings/lib/arm64, /system/priv-app/Settings/Settings.apk!/lib/armeabi-v7a, /system/lib, /vendor/lib, /system/lib, /vendor/lib]]
下面指令查看 系统安装的package信息
adb shell dumpsys package p > dumpsys_p
注意出错的apk:primaryCpuAbi=arm64-v8a
,是64 bit apk , 因此寻找了32 bit的库
apk架构确定顺序:
- 如果apk包中lib文件夹下有.so库,就根据这个.so库的架构模式,确定app的primaryCpuAbi的值
- 对于system app, 如果没法通过第一步确定primaryCpuAbi的值,PKMS会根据
/system/app/${APP_NAME}/lib和/system/app/${APP_NAME}/lib64
这两个文件夹是否存在,来确定它的primaryCpuAbi的值 - 对于还没有确定的app, 在最后还会将自己的primaryCpuAbi值与和他使用相同UID的package的值设成一样
- 对于到这里还没有确认primaryCpuAbi的app,就会在启动进程时使用ro.product.cpu.abilist这个property的值的第一项作为它关联的ABI
解决方法:
基于android加载so文件的机制,我们可以采用一下几种方法来解决该问题
- apk不使用系统的uid,自己新增一个具有系统权限的uid(比较麻烦)
- 把我们的apk修改为64位的,将所有使用的32位so替换为64位(可能有些三方so不提供64位版本
- 把所有32位库再封装一次,做成jar包,然后使用这些jar包。(需要自己封装)
将所有32位库服务抽离出来,单独运行一个(或多个)进程。(需要提前确定好app的架构,不然需要重构app) - 在系统apk(例如:Settings)安装位置system/priv-app/xxx/目录下面建立一个lib/arm64文件夹.(利用apk架构确定顺序强制将系统apk变为64位)
- 将系统apk编译 不剥离 dex 模式
a.在apk对应的android.mk中LOCAL_DEX_PREOPT := nostripping
b./device/xxx/xxx/BoardConfig.mk,DEX_PREOPT_DEFAULT := nostripping
其他问题,在实际的解决问题的时候要考虑系统签名,API 版本问题
REF:
https://www.cnblogs.com/blogs-of-lxl/p/11608115.html
https://zhuanlan.zhihu.com/p/104122672
https://www.jianshu.com/p/18a8a4e6af3f