ART虚拟机最常用的操作集中在包管理与编译控制，核心命令是通过adb shell调用cmd package或cmd art，覆盖强制编译、模式切换、状态查看与性能优化。
ART虚拟机命令的本质与适用场景
Android从5.0起默认使用ART（Android Runtime）替代Dalvik，应用在安装时或首次运行时会被编译为原生机器码，相比Dalvik的JIT即时编译，ART采用AOT（预先编译）与JIT结合的方式，启动更快、执行更稳，但对于普通用户和开发者来说，ART并非透明，系统提供了一系列命令来主动干预编译行为，这些命令多数需在adb shell环境或Android系统终端中执行，且要求设备已解锁或拥有调试权限。
适用场景包括：应用冷启动过慢、安装后未完成编译、刷机后首轮编译卡顿、游戏掉帧严重、开发者测试不同编译模式对性能的影响，掌握这些命令，能直接绕过图形界面，用字节级指令控制ART运行状态。
art虚拟机命令有哪些常用操作
日常操作中,我们打交道最多的是cmd package compile、cmd package dexopt、dumpsys系列命令，它们各自负责编译触发、状态查询和日志输出，下面按使用频率分类。
强制编译与清理编译数据
强制编译是最常见的操作，尤其是在刷机或安装新系统后，系统后台编译不积极时手动触发，命令格式如下：
adb shell cmd package compile -m speed -f com.example.app-m指定编译模式，-f表示强制覆盖原有编译结果，该命令会立即对目标应用执行完整AOT编译，耗时约数秒到数分钟，耗电和发热明显，如果希望编译所有应用，可将包名替换为-a参数：
adb shell cmd package compile -m speed -f -a注意,-a全量编译会持续较长时间，一般只建议在充电且连接Wi-Fi时操作。
清除编译数据则相反，用于恢复应用至未编译状态，便于测试JIT表现，使用：
adb shell cmd package compile --reset com.example.app该命令删除该应用的.oat文件，回落至仅解释执行或JIT模式，全量重置为：
adb shell cmd package compile --reset -a重置后首次启动会变慢,属于正常现象。
查看当前编译模式与编译状态
想知道某个应用当前处于哪种编译模式,使用dumpsys：
adb shell dumpsys package dexopt com.example.app输出中会包含dexopt状态、编译器过滤（如speed、verify）、上次编译时间等字段，例如字段CompilerFilter: speed代表已AOT优化为速度模式，若显示quicken或verify，说明只做了部分优化。
查看系统全局编译统计,可用：
adb shell cmd package compile -a --check-prof该命令会报告各应用当前编译器过滤类型,适合批量排查哪些应用未触发编译。
触发后台编译调度任务
ART会在设备空闲和充电时自动执行编译任务,但有时我们希望主动唤醒调度器，通过cmd package bg-dexopt-job可以强制触发一次后台维护式编译：
adb shell cmd package bg-dexopt-job该命令与reboot后的dexopt流程类似，但权重较低，适合用于测试系统空闲编译逻辑，日常优化不建议频繁使用。
查看ART运行时信息
除了包管理,ART自身也暴露了调试命令，在shell中直接执行：
adb shell cmd art dump可输出ART堆内存、GC策略和类加载数据，该命令对排查内存泄漏和GC抖动有辅助意义，但普通用户不必深究，更简洁的查看方式是：
adb shell dalvikvm -Xhelp这能列出dalvik虚拟机（ART的兼容入口）支持的所有运行时参数，适合进阶开发者复现特定GC策略。
art虚拟机编译模式怎么选
ART提供了多种编译器过滤模式,分别对应不同速度和空间的权衡，选错了，可能白了优化，选对了，流畅度提升明显。
各编译模式对比速查
下表是实际操作中会遇到的模式（即命令中的-m参数值）：
| 模式 | 编译范围 | 安装体积 | 启动速度 | 适用场景 |
|---|---|---|---|---|
verify |
仅校验字节码 | 最小 | 慢 | 调试、临时回滚 |
quicken |
部分指令优化 | 小 | 较快 | 节省空间与速度折中 |
speed
|
全局AOT编译 | 较大 | 快 | 日常主流推荐 |
speed-profile |
基于热点配置编译 | 较大 | 快 | 兼顾空间与启动效率 |
space |
空间优先编译 | 较大 | 较快 | 存储紧张设备 |
everything |
全部方法无条件编译 | 最大 | 最快 | 极致性能，忽略体积 |
行业共识认为，绝大多数用户应优先选speed或speed-profile，其中speed-profile会先运行一阵子再按热点编译，长期稳定性好，而everything会显著增加安装包体积，一般只用于基准测试。
根据使用场景选择模式
日常主力机：改用speed-profile模式是更聪明的做法，因为该模式会结合JIT运行数据，只编译高频热点方法，冷启动和内存占用均衡，操作命令：
adb shell cmd package compile -m speed-profile -a执行后系统会在后续使用中动态补充编译,不过首次强制切换后，需要几天使用习惯来积累profile数据，期间性能略低于稳定后的状态。
游戏或大型应用：游戏追求帧率稳定，建议单独对游戏包执行speed模式，例如对《王者荣耀》包：
adb shell cmd package compile -m speed -f com.tencent.tmgp.sgame该操作能减少游戏内每帧运行时的解释执行开销,实际体感是团战掉帧减少。
老手机或存储不足：建议维持verify或quicken，优先保证可用空间，虽然启动慢些，但能避免编译文件撑爆容量，同时降低闪存写入压力，用如下命令切换：
adb shell cmd package compile -m verify -aart虚拟机优化技巧与注意事项
掌握了基础命令,下面几条实操技巧可以帮你更安全地用好这些指令，避免砖机或耗电异常。
先备份现系统状态
强制全量编译会生成大量.oat文件，一旦遇到系统版本不兼容，可能反复触发编译失败，建议在执行全量编译前，先记录当前编译状态：
adb shell dumpsys package dexopt > dexopt_backup.txt
这能让你在异常后对比差异,并判断是哪个包导致问题。
编译过程与设备发热控制
全量编译时CPU会被大量占用,设备温度上升很快，业内专家指出，温度过高会触发系统限频，反而拉长编译时间，因此建议采取如下策略：
- 连接充电器且移除保护壳,确保散热通畅
- 分批次编译,不要一次对全部应用强制
everything - 编译中途不要重启,否则编译进度中断需重新开始
- 使用
watch命令实时监控进程状态，例如每5秒刷新一次：
watch -n 5 "ps -A | grep dex2oat"当dex2oat进程消失，说明编译流程结束。
与Android版本兼容性
不同安卓版本的ART命令参数略有差异,例如Android 8.0新增speed-profile模式，Android 10强化了bg-dexopt-job调度，而Android 12则支持--check-for-profile校验，如果你在多台设备上操作，先运行：
adb shell cmd package help查看当前系统支持的参数列表,避免使用不存在的选项。
持久化编译设置
部分命令的编译结果在应用更新后会消失,因为新版本应用会重跑dexopt，想要持久化保持编译偏好，可结合reset-on-idle策略，但该操作涉及系统原生配置，普通用户建议只做临时编译，若发现某次编译后应用异常，使用上文--reset命令回退即可。
常见问题解答
art虚拟机命令输入后报错”Failed to compile”怎么办？
大概率是参数未按系统版本适配,或目标包名不存在，先核对包名，使用adb shell pm list packages | grep 关键词查找完整包名，再确认当前系统是否支持-m后的模式，Android 8以下不支持speed-profile，最后尝试清除缓存后重新编译，命令为adb shell cmd package dexopt --reset配合再次编译。
全量编译后应用反而更卡了，是否该继续使用？
这是正常的过渡现象,全量编译会产生大量IO写入和缓存重建，首24小时内系统在频繁读取新编译产物，卡顿感明显，建议等待下一次设备空闲充电周期，让ART完成后台整理，如果持续三天仍卡，再改用speed-profile模式并观察热点数据统计即可。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/621652.html
