大版本迭代,升级了底层数据。你把原理搞清楚就不会这么说了。安装慢了,用起来变快了。
2008年9月,谷歌正式发布了Android1.0,但大家都知道的是,Android是基于Linux内核的操作系统,底层是Linux用于硬件驱动和资源调配,在中间加上了Java虚拟机,其表面层是Android运行库。
在Android2.2之前,Android的Java虚拟机是Dalvik。Dalvik支持转换为.dex格式的Java应用程序,每次运行程序的时候,Dalvik负责将dex文件翻译为机器码交由系统调用,但Dalvik的劣势,就是这是一种适合内存与处理器速度有限系统的解决方案。
到了Android2.2,由于Android系统的低效率,谷歌拿出了即时编译技术JIT(JustInTimeCompiler)。使得在App运行时,每当遇到一个新类,JIT编译器就会对这个类进行编译,而经过编译后的代码,会被优化成相当精简的原生型指令码(即nativecode),这样在下次执行到相同逻辑的时候速度就会更快
但很遗憾的是,即便JIT让Dalvik的性能提升了300%以上,但是由于JITD的策略是dex文件翻译成本地机器码,都需要发生在应用程序的运行过程中,并且应用程序每一次重新运行时,都要做重做这个翻译工作。也使得JIT+Dalvik的组合还是与高效无缘
有鉴于此,在Android4.4时谷歌推出了新的虚拟机ART(AndroidRuntime),来解决之前的Java代码执行效率太低的问题。ART使用的编译器被称为AOT(AheadOfTime),也就是预编译策略,指的是App在第一次安装时,Java代码就会被预先编译成机器码,使其成为真正的本地应用。但问题就是完全的AOT模式,让App安装和系统升级之后的优化非常耗时,同时被优化的App会占用额外的存储空间。但在这一时期中,Android的流畅度则有了一定的提升。
到了Android7.0之后,谷歌重新引入了JIT编译技术,形成了AOT+JIT+解释执行共存的模式。也免除了单独使用某一种解决方案带来的缺陷,解释执行是为了辅助优化AOT结果,避免进行无脑的全量编译,而JIT则是为了对ART进行代码分析,使其能够在运行时动态优化。并且在AndroidQ上,谷歌结合AI技术提供了系统预测感知功能,使得App在安装时,系统就能知道常用代码会被提前编译。
在“三剑合璧”的模式之下,如今的Android已经比4.X、5.X时代要高效很多。但是即便是这样的Android,在iOS面前依然是略逊一筹。使用C语言开发的iOS是不需要虚拟机的,再搭配专用的开发工具Xcode,以及编译效率超高的LLVM编译器,实现了只要APP运行就能够自动将整个程序编译,然后转换为机器码的静态编译。


