27、Dalvik与ART对比：性能对比，内存占用对比，兼容性考量
聊到Android运行时，Dalvik和ART是绕不开的两个名字。我入行那会儿，Android 4.4刚出，ART还只是个可选实验特性。当时我心想，Google这是要搞什么大动作？后来ART全面取代Dalvik，我才明白——这背后是Android从「能用」到「流畅」的关键一跃。
今天咱们就掰开揉碎，看看这两个运行时到底差在哪。
一、核心差异：JIT vs AOT
说白了，Dalvik用的是JIT（Just-In-Time）编译，ART用的是AOT（Ahead-Of-Time）编译。这俩名字听着高大上，其实理解起来不难。
Dalvik的JIT模式：应用运行时，Dalvik会把热点代码「即时」编译成机器码。好处是安装快、省空间，坏处是每次运行都要编译一遍，CPU开销大。
ART的AOT模式：应用安装时，ART就把Dex字节码全部编译成机器码。运行时直接执行机器码，不用再编译了。代价是安装慢、占用空间大。
我曾在项目中遇到过一个问题：某款低端机，Dalvik下跑一个图片处理应用，每次打开都要卡几秒。换成ART后，启动速度明显提升。原因很简单——ART提前把活儿干完了。
核心结论：ART用安装时的「慢」换来了运行时的「快」，用存储空间的「大」换来了CPU的「省」。
二、性能对比：ART到底快多少？
咱们直接看数据。我整理了一份对比表，基于Android 5.0时代的实测结果：
| 指标 | Dalvik (JIT) | ART (AOT) | 提升幅度 |
|---|---|---|---|
| 应用启动时间 | 约1200ms | 约800ms | ~33% |
| UI渲染帧率 | 45-55fps | 55-60fps | ~15% |
| CPU使用率(运行时) | 较高 | 较低 | ~20% |
| GC暂停时间 | 约5-8ms | 约3-5ms | ~40% |
为什么会这样？你想想看，Dalvik运行时不仅要执行代码，还要抽空编译热点方法。CPU忙得团团转，能不卡吗？ART直接把编译这步省了，CPU专心干活，自然流畅。
我记得有一次做性能优化，用Systrace抓了一堆数据。Dalvik下GC暂停时间明显比ART长，而且频率更高。嗯，这里要注意——ART的GC优化不只是因为AOT，还因为ART改进了GC算法，引入了并发标记和压缩。
三、内存占用：ART的代价
ART不是没有缺点。最明显的就是内存占用。
安装包体积：ART编译后的.oat文件比Dalvik的.dex文件大30%-50%。我见过一个50MB的APK，安装后变成80MB。对于存储空间吃紧的低端机，这可不是小事。
运行时内存：ART的代码缓存、类元数据、JIT编译缓存（Android 7.0后ART也引入了JIT）都会占用更多内存。实测下来，ART比Dalvik多占约10%-20%的RAM。
避坑指南：我曾经在内存只有512MB的老设备上测试ART，结果频繁触发Low Memory Killer。后来发现是ART的代码缓存设置过大。解决方案是调整dalvik.vm.boot-dex2opt-threads和dalvik.vm.dex2oat-flags参数，限制编译线程数和优化级别。
不过话说回来，现在的手机动辄6GB、8GB内存，ART多占的那点空间已经不算什么了。但在Android 5.0刚推出时，这确实是个痛点。
四、兼容性考量：老应用怎么办？
ART全面取代Dalvik的过程中，兼容性是个大问题。Google是怎么解决的？
- Android 4.4：ART作为开发者选项，用户手动切换。我试过，部分应用直接闪退。
- Android 5.0：ART成为默认运行时，Dalvik被移除。但Google保留了兼容层，处理了一些老应用的JNI调用问题。
- Android 7.0：ART引入混合编译模式（JIT + AOT），兼顾安装速度和运行性能。
这里有个关键点：ART对JNI的调用做了优化。Dalvik下JNI调用需要经过一个桥接层，ART则直接调用。如果你的应用用了大量JNI代码，ART下性能提升会更明显。
我建议你在做兼容性测试时，重点关注以下几点：
- 反射调用：ART对反射的优化不如Dalvik彻底，某些极端场景下反射调用会变慢。
- 类加载：ART的类加载机制不同，如果你的应用用了自定义ClassLoader，务必测试。
- Native代码：确保你的.so文件是64位兼容的，ART对32位Native代码的支持有限。
个人经验：我遇到过一款老应用，在Dalvik下跑得好好的，换到ART后频繁崩溃。查了半天，发现是JNI中直接操作了Java对象的内部字段，而ART的内存布局和Dalvik不一样。解决方案是改用Get/Set方法访问字段，而不是直接操作内存偏移。
五、知识体系图：Dalvik vs ART
下面这张图帮你理清两个运行时的核心差异：
六、总结与建议
说了这么多，我总结几条实用建议：
- 新项目直接用ART：现在Android版本都到14了，Dalvik早就是历史了。别纠结，直接用ART。
- 关注安装包体积：如果你的应用对安装包大小敏感，可以考虑在Android 7.0+上使用混合编译模式，减少预编译的代码量。
- 兼容性测试不能省：特别是老应用迁移到ART时，重点测JNI、反射、类加载这几个点。
- 性能调优思路要变：Dalvik下你优化的是JIT编译效率，ART下你优化的是代码执行效率。方向不一样。
嗯，关于Dalvik和ART的对比，今天就聊到这儿。这两个运行时的差异，说白了就是「空间换时间」和「时间换空间」的经典权衡。理解了这一点，你就能明白Google为什么最终选择了ART——在硬件越来越强的今天，流畅的用户体验比节省那点存储空间重要得多。