ART虚拟机是Android系统的运行时环境，负责加载DEX字节码、管理内存与垃圾回收，并通过AOT/JIT混合编译把应用代码变成机器码；理解它的关键，是看清编译、类加载、执行和GC四条链路如何协同。 它不是神秘黑盒，而是应用启动速度、安装耗时、内存占用和卡顿问题的底层舞台，下面从实际开发视角拆开讲。
ART虚拟机是什么？用一句话通俗解释
ART全称Android Runtime，从Android 5.0起成为默认运行时，你可以把它想成应用进程里的“翻译官兼管家”：一边把APK里的classes.dex翻译成机器能执行的代码，一边管理对象分配、线程、异常和垃圾回收。
它和标准JVM不是一回事,JVM执行Java字节码，面向通用Java SE；ART执行DEX字节码，基于寄存器架构，面向移动端，APK解压后能看到classes.dex，多DEX应用还有classes2.dex等，ART不会直接“读一行执行一行”就完事，它会结合解释器、JIT和AOT编译，在不同场景下切换执行方式。
ART虚拟机的核心职责
- 类加载：按双亲委派模型加载
BootClassLoader、PathClassLoader、DexClassLoader中的类。 - 方法执行：解释器、JIT编译代码、AOT编译代码之间切换。
- 内存分配：管理Java堆、大对象空间、线程本地分配缓冲等区域。
- 垃圾回收：识别GC Roots，做并发标记、并发复制和分代回收，减少暂停。
- 调试与监控：提供JDWP、JVMTI、方法追踪、堆转储等接口。
- 异常与线程：维护栈帧、异常分发、锁与同步状态。
ART虚拟机与Dalvik虚拟机区别对比
Dalvik是ART之前的默认运行时,以JIT为主；ART引入AOT预编译，后来演变为AOT+JIT+Profile引导的混合模式，业内专家指出，ART的设计目标是在启动速度、安装时间、存储占用之间取平衡，而不是单纯追求某一项最快。
| 对比维度 | Dalvik | ART |
|---|---|---|
| 执行对象 | DEX字节码 | DEX字节码 |
| 编译策略 | JIT为主 | AOT、JIT、混合编译 |
| 安装耗时 | 相对较短 | 可能更长，需dex2oat |
| 冷启动 | 通常较慢 | 热点代码预编译后更快 |
| 存储占用 | 相对较小 | OAT/VDEX会占额外空间 |
| GC设计 | 较早方案 | 更强调并发与低暂停 |
实际设备上可以用命令观察编译状态：
adb shell dumpsys package com.example.app
在输出里找Dexopt state段落，也可以强制按速度模式编译：
adb shell cmd package compile -m speed -f com.example.app
-m speed表示尽量AOT编译，-m speed-profile表示按Profile热点编译，-m verify只做验证，不同Android版本支持略有差异。
Android ART虚拟机工作原理详解：从DEX到机器码
ART的工作链路可以拆成三步：安装或空闲时编译，运行时类加载与执行，持续进行内存管理。
第一步：dex2oat把DEX编译成OAT
应用安装或系统空闲时,PackageManager会触发dex2oat，它读取APK里的DEX，生成OAT文件，通常位于：
/data/app/<包名>/oat/arm64/base.oat /data/app/<包名>/oat/arm64/base.vdex
OAT是ELF格式,里面包含编译后的机器码、方法元数据和调试信息；VDEX保存DEX及验证结果，运行时ART优先加载OAT/VDEX，减少重复解析和验证。
编译过滤器很关键：
verify：只验证，几乎不生成机器码。quicken：做轻量优化，旧版本常见。speed-profile：按Profile热点编译，移动端常用。speed：尽量全量AOT，启动快但安装和存储成本高。
开发阶段可手动触发后台优化：
adb shell cmd package bg-dexopt-job
也可以查看Profile路径,Android 7以后，常见路径在：
/data/misc/profiles/cur/0/<包名>/primary.prof /data/misc/profiles/ref/<包名>/primary.prof
需要root权限才能直接读取,Profile记录热点方法和类，speed-profile编译会参考它。
第二步：类加载与执行引擎切换
应用启动后,ART先创建运行时，加载BootClassLoader中的系统类，再由PathClassLoader加载APK，类加载过程包括加载、链接、验证、准备、解析和初始化，验证不通过会抛VerifyError，类初始化失败会抛ExceptionInInitializerError。
执行引擎有三种形态：
- 解释器：启动快，执行慢，适合冷门方法。
- JIT：方法变热后编译成机器码，放入JIT代码缓存。
- AOT：安装或空闲时预编译，启动时直接执行。
方法入口会在解释器入口和编译代码入口之间切换,JIT编译后，Profile会记录热点；设备空闲时，系统再触发dex2oat做AOT编译，这样既避免安装时全量编译太久，又让常用路径越用越快。
第三步：内存布局与垃圾回收
ART的堆不是一块“大水池”，常见区域包括Zygote空间、App Image、RegionSpace和大对象空间LOS，小对象通常在线程本地分配缓冲中快速分配，大对象进入LOS，减少复制成本。
GC Roots包括线程栈中的引用、JNI全局引用、类静态字段、常量等，ART的GC会做并发标记、并发复制和分代回收，分代回收利用“大多数对象朝生夕死”的规律，减少全堆扫描，读屏障用于维护并发复制时的引用正确性。
排查内存时可用：
adb shell dumpsys meminfo com.example.app adb logcat -s art
前者看Java堆、Native堆、Graphics等分布，后者过滤ART的GC日志，抓堆转储可在调试包或具备权限时执行：
adb shell am dumpheap com.example.app /data/local/tmp/app.hprof
国内手机厂商ART虚拟机优化差异在哪里？开发者实测思路
同一份APK在不同ROM上启动耗时不同,不一定是代码问题，国内手机厂商会定制编译策略、后台dexopt触发时机、GC阈值和CPU调度，行业共识认为，厂商调优会明显影响冷启动和后台内存回收表现。
厂商定制的主要落点
- 后台编译策略：有的ROM充电空闲时积极dexopt，有的更保守。
- Profile采集：系统可能限制后台应用采集热点，影响
speed-profile效果。 - GC参数：低内存设备更早触发回收，暂停策略不同。
- 性能调度：大核绑定、频率策略会影响编译和执行速度。
- 安装优化：应用商店预编译、云端编译会改变首次启动表现。
实测时别只看一次启动,用同一台设备、同一版本APK、清后台后跑三次：
adb shell am start -W -n com.example.app/.MainActivity
记录TotalTime和WaitTime，取中位数，再对比强制speed编译前后的差异：
adb shell cmd package compile -m speed -f com.example.app adb shell cmd package compile -m speed-profile -f com.example.app
如果强制AOT后启动明显变快,说明热点编译或Profile覆盖不足；如果差异很小，瓶颈更可能在布局、IO、锁竞争或Native初始化。
ART虚拟机对手机性能影响大吗？
影响集中在冷启动、安装时间、存储占用和后台内存，对普通用户，ART在后台自动工作，不需要手动干预，对开发者，ART编译状态是排查启动慢的第一层线索，但不是唯一答案，列表卡顿还要看渲染线程、主线程IO和锁。
ART虚拟机调优工具需要付费吗？
Android SDK自带的adb、simpleperf、dumpsys、am等工具免费，第三方商业APM和性能平台通常按订阅收费，是否付费取决于团队是否需要线上聚合、版本对比和告警，个人排查先用系统工具足够。
常用命令清单：
adb shell cmd package compile -m verify -f com.example.app adb shell cmd package compile -m speed-profile -f com.example.app adb shell cmd package bg-dexopt-job adb shell dumpsys package com.example.app adb shell dumpsys meminfo com.example.app adb shell simpleperf record -p <pid> --duration 10
simpleperf和堆转储在部分设备上需要root或调试权限，先确认权限再执行。
ART虚拟机常见问答（Q&A）
ART虚拟机是什么？和JVM有什么区别？
ART是Android专用运行时,执行DEX字节码，基于寄存器架构，围绕移动端做AOT/JIT混合编译和低暂停GC，JVM执行Java字节码，基于栈架构，面向通用Java SE生态，两者都管理内存和线程，但指令集、编译策略和运行环境不同。
ART虚拟机会完全取代Dalvik吗？
Android 5.0起ART成为默认运行时，Dalvik已退出默认运行时位置，历史应用仍以DEX形式交付，由ART负责加载和编译，兼容性通过DEX格式和运行时支持处理。
普通用户需要手动优化ART虚拟机吗？
不需要,系统会在应用安装、充电空闲和后台任务中自动触发dexopt与Profile编译，开发者若遇到启动慢，应优先查看Dexopt state、Profile覆盖和am start -W耗时，再决定是否调整编译策略，ART的默认策略已经在启动速度、安装耗时和存储占用之间做了平衡。