Android
十年前，Dalvik虚拟机曾是
Android生态的核心。然而，Dalvik的设计初衷更多是为了满足快速上线的需求，可以说是一种病急乱投医的产物。当时
Java应用虽然内存消耗较大，但
手机硬件资源极其有限，如何让
Java能够在内存仅有128MB的设备上运行成为一大挑战。于是，Dalvik应运而生，它以极低的标准追求运行可行性，而不顾效率问题。Dalvik仅支持即时编译（JIT），完全不支持提前编译（AOT），并且其JIT缓存不会持久化到存储中。这种设计与
Android早期随意终止进程的机制冲突明显——一旦应用程序被系统杀死，所有JIT缓存都会丢失，重新启动时又需要再次进行JIT编译，导致性能低下、卡顿频繁。为何Dalvik会采用如此激进的设计？主要是为了适应当时的硬件条件，尽可能优化内存占用，通过减少内存使用来适应小内存环境。然而，这种过度注重内存节省的方式也带来了严重的副作用：Dalvik的执行速度非常缓慢。2012年，Oracle的一项研究将HotSpot移植到
移动平台并与Dalvik进行了对比测试，结果发现HotSpot的性能比Dalvik快了近2.9倍（即290%）。这一结果表明，Dalvik在性能上的不足已经到了不可忽视的地步。因此，
Google决定彻底淘汰Dalvik，并在
Android 4.4.4版本中引入了全新的ART虚拟机。ART虚拟机支持全局AOT编译，在应用安装阶段就会将DEX文件预编译为OAT文件（Optimized ART File）。尽管这种策略显著延长了应用安装时间，但却大幅提升了运行效率。从
Android 5.0开始，ART正式取代Dalvik成为默认虚拟机，Dalvik也随之退出历史舞台。随着ART的全面启用，
Android性能实现了质的飞跃，整体运行速度较之前提高了两倍以上。相比之下，
IOS自诞生以来就坚持原生编译运行的理念，完全没有涉及JIT编译的概念。这种方式虽然会导致应用体积更大，安装所需流量通常是
Android应用的两倍甚至更多，但换来了更高的运行效率和更稳定的用户体验。尽管Dalvik已经被淘汰，但它的痕迹仍然留在
Android代码库中，一些类名仍带有Dalvik相关标识。这就好比现代浏览器的用户代理（UA）字符串中仍然保留着早已被淘汰的KHTML引擎字段一样。此外，十年前
Android的WebView还基于WebKit，但其版本远落后于
苹果自家使用的版本。而WebKit本身的性能一直不如
Google后来分叉并发展的Chromium。到2014年，Chromium在性能和兼容性方面已远远超越WebKit，这一趋势延续至今。如今，Safari浏览器无论是在极限性能还是兼容性方面，都仍然不及Firefox等竞争对手。
