Android 系统自 5.0（Lollipop）起全面采用 ART（Android Runtime） 替代了早期Android 系统4.4以前的 Dalvik 虚拟机。虽然 ART 和 JVM（Java 虚拟机）在功能上存在相似性（如字节码执行、内存管理等），但 Android 本身不再依赖传统意义上的 JVM。寄存器高于栈运行速度。以下是详细解析：
1. ART 与 JVM 的核心区别
| 特性 | ART（Android Runtime） | DVM | JVM（Java 虚拟机） |
|---|---|---|---|
| 字节码格式 | 执行 DEX ->ELF->.oat文件 | 执行 DEX 字节码（.dex 文件） |
执行 JVM 字节码（.class 文件） |
| 编译方式 | 支持 AOT（预先编译） + JIT（即时编译） | JIT（即时编译） | 主要依赖 JIT 和 解释执行 |
| 架构设计 | 基于寄存器（硬件物理层使用，速度快） | 基于寄存器（软件层抽象，速度快） | 基于栈（通用设计） |
| 内存占用 | 优化后占用更低 | 内存占用高 | 通常较高 |
| 所属生态 | Android 专用 | Android 专用 | Java 标准生态（如 Oracle JDK） |
比较
OAT 是 ELF 的扩展：专为 ART 设计，包含 DEX 和本地机器码
2. Android 为何不再依赖 JVM？
-
性能优化：
ART 的 AOT（预先编译）机制将 DEX 字节码在应用安装时编译为机器码，大幅提升运行速度（相比 Dalvik 的 JIT 模式）。 -
资源限制：
移动设备对内存和电量的敏感度更高，基于寄存器的 ART 设计更适合移动端。 -
生态隔离：
Google 为 Android 构建了独立的运行时环境，避免与 Oracle JVM 的专利和兼容性问题。
3. Android 开发中与 JVM 的关联
尽管 Android 系统本身不依赖 JVM，但开发工具链仍与 Java/Kotlin 生态相关：
-
开发语言：
Android 应用使用 Java/Kotlin 编写，这些语言最初设计时面向 JVM，但通过以下方式适配 ART：
Java 代码 → 编译为 JVM 字节码 → 转换为 DEX 字节码 → ART 执行
-
JVM是Java虚拟机的简称，通常指Oracle的JVM，用于执行Java字节码。而Android的DVM和ART都是虚拟机，但它们执行的是Dex字节码，不是标准的Java字节码。虽然Android应用是用Java或Kotlin写的，但编译后的字节码会被转换成Dex格式，由DVM/ART执行。
-
ART/DVM和JVM的区别在于它们处理字节码的方式和架构。JVM是基于栈的，而Dalvik/ART是基于寄存器的，这样设计是为了移动设备优化性能。此外，ART引入了AOT（预先编译）机制，与JVM的JIT（即时编译）不同，提高了应用的运行效率。
-
Android现在使用ART，取代了Dalvik，两者都是Android专用的运行时环境，不同于JVM。虽然开发语言是Java/Kotlin，但编译后的代码在ART上运行，不依赖JVM。因此，Android系统中不会用到JVM。
-
工具链依赖：
- JDK（Java Development Kit）：编译和调试需要 JDK（如 OpenJDK），但它仅用于生成 JVM 字节码，最终会被转换为 DEX。
-
D8/R8 编译器：将 JVM 字节码（
.class文件）优化为 DEX 格式（.dex文件）。
-
JVM 的“影子存在”：
在 Android Studio 的调试过程中，IDE 可能使用 JVM 的某些工具（如javac编译器），但这些工具不参与最终应用的运行时。
4. 实际场景验证
-
检查 APK 内容：
解压 APK 文件后，你会看到classes.dex（ART 执行的目标），而非*.class文件（JVM 字节码）。APK 结构示例： ├── AndroidManifest.xml ├── classes.dex ← ART 字节码 ├── res/ └── META-INF/ -
运行时环境：
通过adb shell连接设备后，执行ps命令查看进程信息，所有 Android 应用均运行在 ART 上，而非 JVM 进程。
5.历史演变与现状
Android 1.0–4.4：
使用 DVM，牺牲安装速度换取运行效率。
典型问题：应用启动慢，GC 卡顿明显。
Android 5.0–7.0：
全面转向 ART，引入 AOT 编译。
安装时间变长，但用户体验显著提升。
Android 7.0+：
混合编译模式（AOT + JIT），安装时部分编译，运行时动态优化。
引入 Profile-Guided Optimization (PGO)，根据用户行为优化代码。
6. 常见误解澄清
-
误解 1：
“Android 用 Java 开发，所以必须依赖 JVM”。
真相：Java/Kotlin 仅是开发语言，最终代码会被转换为 DEX 格式由 ART 执行。 -
误解 2：
“Kotlin 替代 Java 后，Android 会抛弃 ART”。
真相：Kotlin 同样编译为 DEX 字节码，ART 仍是运行时基础。 -
误解 3：
“Flutter/Dart 应用不需要 ART”。
真相：Flutter 应用通过 AOT 编译为本地机器码，但 Android 系统本身仍依赖 ART 运行其他组件。 -
误解 4：
为什么安卓开发优化中，会说适量使用软引用和弱应用，不就是因为jvm会回收这些对象吗？
解释：在 Android 开发中，软引用（SoftReference） 和 弱引用（WeakReference） 的使用确实与垃圾回收（GC）机制相关，但它们的核心价值并不依赖于 JVM 的存在，而是由 Java 语言规范 和 ART 的垃圾回收机制 共同决定的。尽管 Android 运行时已从 JVM（Dalvik）切换到 ART，但这些引用的使用逻辑依然适用。GC并非JVM独有，DVM、ART都有。
// 使用弱引用避免 Activity 泄漏
public class MyHandler {
private WeakReference<Activity> activityRef; // ✅ 弱引用
public MyHandler(Activity activity) {
this.activityRef = new WeakReference<>(activity);
}
public void doSomething() {
Activity activity = activityRef.get();
if (activity != null && !activity.isDestroyed()) {
// 安全操作 Activity
}
}
}
7. 未来趋势
-
ART 持续优化：
Google 不断改进 ART 的垃圾回收、编译效率等（如 Android 12 对 ART 的并发压缩 GC 优化）。 -
非 JVM 语言支持：
Kotlin/Native、Rust 等语言通过直接编译为本地代码，减少对 DEX 的依赖，但 ART 仍是 Android 的核心运行时。
总结
- ✅ Android 系统自身不依赖传统 JVM，完全由 ART 负责字节码执行。
- ✅ 开发阶段需要 JDK，但仅用于将 Java/Kotlin 代码编译为中间格式，最终产物是 DEX 字节码。
- ✅ ART 是 Android 的专用运行时，针对移动设备深度优化，与 JVM 无直接关联。
- ✅ JVM：Java 生态基石，跨平台但效率不足，不适合移动端。
- ✅ DVM：Android 早期妥协方案，基于寄存器但 GC 性能差。DVM 的「基于寄存器」是虚拟机指令集设计，属于软件层抽象。
- ✅ ART：现代 Android 核心，AOT/JIT 混合 + 高效 GC，专为移动设备优化。ART 的「物理寄存器使用」是硬件执行的自然结果，与架构设计无关。ART 通过 AOT 编译彻底摆脱了 DVM 的执行模型，直接生成高效的本地机器码。
网友评论