dex2oat过程对系统性能的影响

问题

最近开发中遇到个问题，系统在休眠唤醒后的一段时间，经常会出现系统卡顿不流畅的情况。正好赶上前段时间对设备做过OTA升级，自然会想到是否是OTA升级给系统引入了新的问题。

看了一些设备在系统卡顿时间的log，多个设备此时后台都在执行dex2oat的过程。只是巧合吗？dex2oat会不会影响系统性能使系统变得卡顿？带着这个问题简单了解一下dex2oat。

 

dex2oat简介

android应用使用java语言写的，java跑在java虚拟机上。java虚拟机的作用是屏蔽底层系统与芯片的差异，使得上层只专注于app的开发，不用关注底层的差异，适配转换的工作都交给java虚拟机帮你做了。

android早期使用dalvik虚拟机，目前采用ART虚拟机。dex2oat工具是对dex文件进行转化，转化成虚拟机执行效率更高的格式。针对Dalvik虚拟机转化为odex文件，针对ART虚拟机转化为ELF文件。下图为

java语言在android的运行流程：

 

dex2oat在优化时，会根据需要优化一定量的method。也就是说并不是优化的method都会被翻译成oat模式。根据优化的method的量的多少，可以分为如下的几种模式：

Android 运行时 (ART) 包含一个具备代码分析功能的即时 (JIT) 编译器，该编译器可以在 Android 应用运行时持续提高其性能。N版本当中强化了JIT模式。JIT模式是Just in time 的简称。意思是在运行的时候，根据method有使用频率来决定是否要对某一个方法进行优化。虚拟机会统计每一个方法被执行的次数。如果某一个方法执行的次数比较多，达到一定的阈值，就会将升级为hot method，并将其记录在一个profile当中。在系统空闲并且在充电的时候，只将这些方法进行优化。在运行的时候，也会对这些方法进行优化，以方便在运行的时候使用。

备注： 以上内容主要来自 https://blog.csdn.net/long375577908/article/details/78190422

 

dex2oat命令行

开启 JIT 详细日志记录

adb root adb shell stop adb shell setprop dalvik.vm.extra-opts -verbose:jit adb shell start

停用 JIT

adb root adb shell stop adb shell setprop dalvik.vm.usejit false adb shell start

    基于配置文件强制编译特定软件包

adb shell cmd package compile -m speed-profile -f my-package

    全面强制编译特定软件包

adb shell cmd package compile -m speed -f my-package

基于配置文件强制编译所有软件包

adb shell cmd package compile -m speed-profile -f -a

全面强制编译所有软件包

adb shell cmd package compile -m speed -f -a

备注：以上内容主要来自 https://blog.csdn.net/zhangbijun1230/article/details/80590208

 

dex2oat占用资源测试

手动发命令触发dex2oat，通过top命令发现dex2oat进程占用将近300%的cpu（cpu一共4个核，总资源400%）

从log中也能看到，dex2oat开启了4个线程，在4个核上都在跑

看到这里感觉得找到了真凶，dex2oat占用cpu资源太多，导致cpu资源紧张，系统卡顿。

但是还有一个重要的信息被遗漏了，从top命令的截图中看到，dex2oat进程的nice值为10，优先级很低。cpu空闲的时候，优先级高低影响不大，都能分到足够的cpu资源。一旦cpu紧张的时候，优先级低的进程cpu使用时间就会被大量抢占，把cpu让给优先级更高的进程。android上用户能感知的进程的优先级都比较高，nice值远低于10（nice值越大优先级越低），所以一个nice值为10的进程，cpu抢占能力很低，不是造成系统卡顿的主因。实测结果也是这样的，在系统繁忙的时候dex2oat进程cpu占用就被抢占很严重，降到10%以下了。

另外补充一些信息：

1. dex2oat会判断cpu的核数，几个核就创建几个线程，并发执行，这就是为什么系统空闲时cpu占用如此高的原因。

2. OTA升级系统重启后，dex2oat不是一下全部执行完，有一些策略，分批执行，比如cpu闲时执行等。

 

结论

dex2oat进程优先级低，不是造成系统卡顿的主因。

最终经过分析导致系统卡顿的真因是cpu被降频了，高通平台有个限制温度低于5摄氏度cpu被降频，高于10摄氏度解除降频。猜测可能是为了考虑低温保护电池所做的措施。

 

编译选项配置

通过在模块的makefile文件设定 LOCAL_DEX_PREOPT 选项为ture or false，来指定应用启用或停用预先优化功能。

启用预先优化功能，即在模块编译的时候就进行dex2oat的优化，生成apk的同时生成优化后的oat文件。增加了systemimage的大小，但节省了在系统在运行时进行dex2oat的资源开销，以空间换时间。