Android作为与iOS分庭抗礼的智能系统，如今已经占据了智能手持设备的半壁江山，但是正如很多Android用户所抱怨的，它在UI流畅程度方面始终与iOS有差距，而且根据不少Android用户反映，自己的Android设备在长期使用后也会不同程度地出现卡顿的情况。当然，这与Android本身的运行机制有关，而谷歌也在为解决这样的问题而努力，在Android 4.1推出的时候，谷歌就进行了“黄油计划”来改善系统的流畅度，而在最新推出的Android4.4中，也包含了新的“Project Svelte”，翻译过来就是苗条计划，让我们来看个究竟。


Android被诟病的执行效率
    可能不少朋友都听说过Android运行效率不够好的原因是它是运行在Java虚拟机上的，说到这个，就不得不提Dalvik。
    Dalvik是谷歌自己设计的、用于Android平台的Java虚拟机。Dalvik虚拟机是Android移动设备的核心组成部分之一，它可以支持已转换为.dex（即Dalvik Executable）格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统（自然指的就是手机、平板以及各种智能随身设备）。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik应用作为一个独立的Linux 进程执行，独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。正是因为采用了Dalvik，才使得程序可以在不同架构的硬件平台上运行。
    Dalvik和Java虚拟机（JVM）本身最明显的差别就是Java虚拟机运行的是Java字节码，而Dalvik虚拟机运行的是专用的文件格式Dex。Dex文件格式可以减少文件的尺寸，提高I/O操作的类查找速度。当Android启动时，Dalvik VM 会监视所有的程序（APK），并且创建依存关系树，为每个程序优化代码并存储在Dalvik缓存中。Dalvik第一次加载后会生成Cache文件，以提供下次快速加载，所以第一次会很慢。
    当然，也有观点认为，像Dalvik这样基于寄存器的虚拟机由于在执行指令的时候需要先进行编码，所以指令的需求量会更大，这会影响到执行的效率。换句话说，Dalvik就是Android运行效率不够好的“罪魁祸首”。


谷歌的改进措施
    不用说，谷歌当然知道Dalvik的弊端，一直通过各种方法来改进Android系统的流畅度。早在Android 4.1时代，谷歌就进行了“黄油计划”，黄油计划支持60fps的动画效果、使应用的反应更灵敏，甚至可以在刷新屏幕时预判到手指将会触摸到哪里。
    黄油计划的改进是通过一系列手段实现的。首先，Android 4.1系统通过系统框架进行的渲染和动画都采用垂直同步的方式，因此不会有任何帧数提前或滞后；在图形管线中加入了三重缓冲，让滚动和翻页更顺滑；Android 4.1还会在屏幕刷新的时候预判手指下一次触摸的位置；在闲置时，系统会在下一次触摸发生时让CPU输入升压，以确保没有延迟。
    如果说Android 4.1时代的“黄油计划”解决的是软件问题，那么到了Android 4.3则是针对Android设备的存储硬件作出了改进。在Android 4.3中，谷歌加入了Trim功能，相信对固态硬盘比较关注的玩家很清楚Trim是什么，简单点说，就是针对Flash存储芯片的“磁盘整理”功能，为什么在4.3以前的Android设备会越用越慢？长期使用后在ROM中产生的“碎片”太多，造成Flash芯片性能降低是重要原因之一。有了Trim，除了可以回收Flash芯片中零散的数据块，减少写入放大，还可以进行负载平衡，延长它的使用寿命。
    到了Android 4.4，“Project Svelte”映入了人们的眼帘。其中的ART（Android Runtime）改变了应用运行的环境，只是被列为“实验室选项”，下面就来详细介绍一下ART。
    前面已经提到，在运行效率方面，Dalvik VM是Android的短板。因此，谷歌引进了新的 Android 运行环境 ART，在官方介绍中，称其为新的虚拟机，谷歌正是用它来替代旧的Dalvik VM。ART 会为 Android 带来怎样的改变？专业机构对此进行了分析。
    ART的机制与Dalvik不同，在Dalvik环境下，应用每次运行时，字节码都需要通过即时编译器转换为机器码，这会降低应用程序的运行效率，而在ART环境中，应用程序在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（Ahead-Of-Time）。因此，ART环境下应用程序启动和执行都会变得更快更流畅。
    根据一些测试结果，ART运行环境能够让大多数应用程序的执行时间减半，这就意味着，CPU消耗大、运行时间长的应用能够更快速地完成，一般的应用也能更加流畅，反映在实际使用中就是动画效果更顺畅、触控反馈更灵敏等等。另外，在多核处理器的设备上，可以更灵活地利用ARM的big.LITTLE 架构，从而达到更省电的目的。
    当然，ART的预编译也有一些弊端。首先，机器码占用的存储空间更大。字节码转变为机器码后，体积可能会增加 10%～20%，但在应用程序包中，可执行的代码通常只是一部分，所以增加的部分影响有限。其次，应用程序安装的时间会变长——毕竟增加了转码的步骤。安装时间增加多少取决于应用程序包中代码复杂程度和多少。
    综合来看，ART在应用程序体积上的弊端可以通过增加设备的ROM来解决，这完全可以接受，而对于安装时间的增加，毕竟一个程序也就安装一次，但使用却是很频繁的，而由此带来的系统流畅度的改善却很可观，总的来说还是利大于弊。未来Android的流畅度是否能与iOS抗衡，我们也拭目以待。

 


观点：提升效率，为可穿戴智能设备做准备
    当然，ART只是Android 4.4中提升系统流畅度的最重要的改进之一，除此外，Android 4.4还可以在配置比较低（例如只有512MB RAM）的设备上流畅运行，这与它改进了内存管理机制也有很大关系。不过，对低配置的设备友善并不意味着Android4.4是老机器的春天，毕竟手机平板厂商也不愿意为太老的设备去提供Android4.4的升级包，而是希望用户花钱购买更新的产品。所以，由此也可以推断，谷歌的“Project Svelte”（苗条计划）实际上是在为可穿戴智能设备铺路，相对于手机平板来说，智能手表的确算得上是更“苗条”的设备，同时由于续航的限制，它们的硬件配置不可能与手机平板相提并论，这也是谷歌为何要降低系统要求的原因之一。


延伸阅读：iOS用起来比Android流畅的原因
第一点：iOS最先响应屏幕
    拿到手机或平板，屏幕触控的响应速度是最先体验到的，第一印象当然重要。iOS设备在这方面表现明显好于Android设备，由此也给用户留下了iOS更流畅的印象。产生这样的体验差异与两者的交互响应优先级有关。iOS对屏幕触控的响应优先级是最高的，它的响应顺序依次为Touch--Media--Service--Core，当用户触摸了屏幕，系统就会首先去处理屏幕响应。而Android系统的响应优先级顺序是Application--Framework--Library--Kernal，和显示相关的属于Library层面，已经排到第三位去了，也就是说当你触摸屏幕之后，Android系统首先会激活应用、框架，然后才是屏幕响应，体验有延迟是很正常的了。


第二点：运行机制效率不同
    Android基于JAVA，而iOS基于Objective-C。Objective-C的优势是效率高但比较封闭， JAVA的优势是跨平台，但缺点是运行效率相对偏低。Objective-C编译器gcc为iOS架构优化到了极致，运行过程中不需要虚拟机环境，执行效率自然很高，而Android是通过JAVA虚拟机来执行，系统需要占用大量内存来换取执行速度，加上不定期的内存自动回收机制，从而导致了卡顿现象的出现。




第三点：iOS基于GPU加速而Android侧重CPU
    这应该很好理解，既然iOS把很多加速工作都交给了GPU，那CPU就可以空闲出来提供更短的响应时间。而Android由于是开放平台，需要面对很多不同的硬件配置，因此它的很多特效都要靠软件进行加速和渲染，因此相对来说更依赖CPU的运算，所以就加大了CPU的负荷，让系统在程序响应方面出现卡顿。
    虽然Android 4.0以及4.1等更高版本中进行了改进，将硬件加速设为默认开启，但依旧无法做到所有特效全部都靠GPU进行加速。