Android卡顿的罪魁：垃圾回收

APK两种模式（ART与Dalvik）流程的对比

ART的运行效率远高于Dalvik

    早在Android 4.4发布的时候我们就介绍过ART运行环境，它相对于Dalvik来说虽然增加了程序的载入速度，但减少了编译次数，因此总的来说运行速度更快、更流畅。不过，这只是ART让Android更流畅的原因之一，它相对于Dalvik的改进还有更深层的内容，例如，大大减少了Android卡顿的次数和卡顿时间的长短。

    首先我们得了解一下Android的卡顿是如何产生的。首先，Android虚拟机采用的是自动内存管理方式，这个方式的优点是程序开发者无需考虑内存的管理；而缺点是开发者失去了控制权，从而程序必须依赖系统本身的管理机制。由此，Android原本的Dalvik垃圾回收机制就是造成系统卡顿的原因之一（对于Java虚拟机来说，垃圾回收就是把程序使用完之后的内存空间清空，从而让它们可再次被使用的机制）。

    简单地说，在Dalvik 虚拟机下，当系统启动垃圾回收时，会造成两次暂停（一次在遍历阶段，一次在标记阶段）。所谓暂停，就是所有线程都停止执行。如果暂停时间过长，应用程序的渲染中就会出现掉帧，这从用户体验上来说，就是应用程序在运行的时候出现了卡顿。

ART到底减少了多少卡顿？

Dalvik环境下运行FIFA的日志记录了垃圾回收的信息

    从谷歌自己提供的数据来看，Dalvik环境下，每一次卡顿平均时长为54ms，以Nexus 5为例，这就意味这应用程序的渲染丢掉了4帧（60fps×0.054s/1s=3.24 frame，超过3帧不到4帧也算是丢掉4帧）。当然，如果应用程序本身调用内存的部分编写得不够好，垃圾回收的次数会更多，这也就意味这丢掉的帧数会更多。根据Anandtech的测试，在Dalvik环境下、FIFA游戏中，启动游戏后的8秒钟内，垃圾回收就一共启动了9次，总共卡顿了603ms，丢掉了214帧。

    而在ART环境下时，情况有了很大的改善。在同样的运行时间里，卡顿时长的总和为 12.364ms（总共启动了4 次前台垃圾回收和2次后台垃圾回收），总共丢掉了63 帧。这个成绩相比Dalvik来说已经是突破性的提升了。

   ART能实现这样的效果是因为应用程序在这种环境下本身就做了垃圾回收的一些工作，因此在垃圾回收启动之后，只会造成一次暂停，而不是Dalvik的两次。在遍历阶段，应用程序不需要再暂停了，标记阶段的暂停时间也大大缩短，这是因为谷歌采用了一项新技术：packard pre-cleaning，在暂停产生前就做了许多工作，从而减轻了系统在暂停时的工作量。从谷歌公布的信息来看，平均暂停时间已经降低到了3ms，这比Dalvik模式下的54ms快了很多。除此以外，谷歌还改进了内存分配系统，把内存分配的速度提升了10倍，垃圾回收的算法也进行了改进，减少应用被打断的次数。

    这样看来，ART在改进Android系统卡顿方面的确效果非凡，说Android L的流畅度已经赶上了iOS 8也并非完全是夸张。

延伸阅读：ART和Dalvik的架构区别

   ART相对于Dalvik的一大变化是它不仅支持即时编译（JIT），而且还支持预先编译（AOT）。我们知道，在Dalvik环境下，每次应用程序运行，都需要先从字节码编译为原生代码才行。而ART 可以只编译一次，然后每次应用程序运行时，都可以直接执行编译好的原生代码。很好理解的是，预先编译也可以明显改善电池续航，因为应用程序每次运行时不用重复编译了，从而减少了 CPU 的使用频率，降低了能耗。

    当然，ART的预先编译也有一些缺点，例如设备首次启动以及应用程序首次启动的时间会变长。不过，谷歌表示这个差距不是很大，而且他们会在这方面努力改善，使其效率接近甚至超过Dalvik；另一个缺点是原生代码占用的存储空间更大，不过，对于现在手机和平板的存储空间来说这一点点多出来的容量需求不是什么问题。

    另外，可能大家会担心ART的运行环境会造成与之前Dalvik环境下应用程序的兼容问题，其实这完全没必要。ART是兼容 Dalvik 的字节码格式dex的，因此，开发者编写软件不会受到影响，也没有什么兼容性问题。

    在对未来的64位架构支持方面，ART必然不会落下，这确实会带来性能上的提升和加密能力的大幅改进，同时还能保持与现有 32 位应用的兼容性。与苹果的实现方法不同，谷歌在这方面使用了指针压缩，以避免系统转换到 64 位后，内存空间占用大幅增加，所以其虚拟机仍然采用32位指针。谷歌宣称，谷歌商店现有的应用程序中，85% 都可以直接转移到64位，剩下的15%由于有原生代码，则需要重新编译，但从整体上来说，所有应用程序转移到64位平台不会花太长时间。