dalvik和ART虚拟机哪个好？看完对比你就明白了！

今天咱们聊聊Dalvik这玩意儿。现在新入门的兄弟们可能对它没啥概念了，毕竟安卓系统都迭代到不知道多少版本了。但在咱刚开始折腾安卓那会儿，Dalvik可是如雷贯耳，天天打交道的东西。

最初的邂逅：与Dalvik的亲密接触

我记得那还是安卓2.x、4.0的时代，我刚开始学着写点小程序，在模拟器或者当时那配置不咋地的手机上跑。那会儿的应用，启动速度普遍不快，用着用着还可能卡一下。那时候，咱们写的Java代码，编译打包成APK后，里面的dex文件就是在Dalvik虚拟机上跑的。

Dalvik这家伙，它是基于JIT（Just-In-Time，即时编译）的。 啥意思？就是说，你每次打开一个App，或者App运行到某段代码的时候，Dalvik才会把那部分代码编译成本地机器能直接执行的指令。你想，等于你一边开车，引擎盖里还有个小工匠在吭哧吭哧地临时给你造零件，这速度能快到哪儿去？

所以那时候，为了优化App性能，可没少折腾。比如：

• 减少方法数：因为dex文件有个65535方法数的限制，稍微大点的项目就得搞分包，头疼。
• 关注内存：Dalvik的垃圾回收机制（GC）一启动，整个应用都可能卡顿一下，所以得小心翼翼地管理内存，避免频繁GC。
• 启动速度优化：因为是即时编译，首页如果复杂点，白屏时间就特别明显。

那段时间，看logcat输出，研究Dalvik的堆栈信息，成了家常便饭。虽然过程挺痛苦，但也确实学到了不少底层的东西。

时代的眼泪：ART的登场

后来大概是安卓4.4的时候，谷歌推出了ART（Android RunTime）作为实验性选项，到了安卓5.0，ART就正式取代Dalvik，成了默认的运行时环境。

ART跟Dalvik最大的不同，就是它搞了个AOT（Ahead-Of-Time，预编译）。 这就厉害了，它在App安装的时候，就把代码一次性编译成本地机器码。这样，每次你打开App，它直接就能跑，省去了Dalvik那个即时编译的步骤。

我记得当时特意找了台能切换Dalvik和ART的手机（那时候有些系统还提供这个选项），同一个App，在ART模式下，启动速度和运行流畅度的提升是肉眼可见的。简直是质的飞跃！

ART也不是完美无缺的。因为是预编译，

• 安装时间变长了：毕竟要在安装时就把所有代码编译完。
• 占用的存储空间变大了：编译后的本地代码比原来的dex文件要大。

但这点牺牲，换来的是用户体验的大幅提升，完全值得。所谓“空间换时间”嘛

实践中的感受与总结

从Dalvik到ART的转变，对我来说，最直观的感受就是App真的变快了，卡顿也少了。以前很多需要小心翼翼处理的性能瓶颈，在ART时代似乎一下子就没那么突出了。这并不是说ART时代就不用做性能优化了，只是底子变好了，咱们可以把更多精力放在业务逻辑和更精细的优化上。

回过头来看Dalvik，虽然它有不少缺点，比如执行效率相对较低，垃圾回收机制不够完善等，但它毕竟支撑了安卓系统早期的发展，也算是功不可没。了解Dalvik的一些机制，比如它的指令集、堆栈管理、GC过程，对于理解安卓应用的运行原理，甚至对于现在做一些逆向分析或者深度性能优化，都还是有帮助的。

技术这东西就是这样，一代新人换旧人。虽然Dalvik现在基本成了历史名词，但它在我这样的老安卓人的实践经历中，还是留下了挺深刻的印记。今天就跟大家分享到这里，算是一点小小的回忆和记录。