Android虚拟机依赖自动化的内存管理机制,即自动垃圾收集。这一Java语言编程模式的基石也是Android系统自诞生之日起,非常重要的一部分。这里向不太了解垃圾收集概念的朋友解释一下,所谓自动垃圾收集,就是说程序员在编程过程中,不需要自己负责物理内存的存储的分配和释放。只需要使用固定的模式创建你需要的变量或者对象,然后直接利用该变量或对象即可。程序的运行环境会自动在内存中分配相应的内存空间存储该变量或者对象, 并在该变量或者对象失效后,自动释放所分配的内存。这是和其他需要人工进行存储管理的较低层次语言最大的区别。自动垃圾收集的好处是,程序员不必再在编程时担心内存管理的问题,当然,这也是有代价的,那就是程序员无法控制内存何时分配和释放,因而无法在需要时进行优化(Java语言有一些编程接口可以供程序员手工优化程序,但控制方式和粒度有限).
Android曾经被Dalvik的垃圾收集机制折腾了很久。Android平台的内存普遍较小,每次应用程序需要分配内存,当堆空间(分配给应用程序的一块内存空间)不能提供如此大小的空间时,Dalvik的垃圾收集器就会启动。垃圾收集器会遍历整个堆空间,查看每一个应用程序分配的对象,并对所有可到达的对象(即还会被使用的对象)标记,并将那些没有标记的对象空间释放掉。
在Dalvik虚拟机中,垃圾收集器执行的过程将导致两次应用程序的停顿:
所谓停顿,即应用程序所有正在执行的进程将暂停。如果停顿时间过长,将会导致应用程序在渲染时出现丢帧现象,进而导致应用程序的卡顿现象,大大降低用户体验。
Google声称,在Nexus 5手机上,这种停顿的平均长度在54ms。这个停顿时间将导致平均每次垃圾收集会导致在应用程序渲染显式时丢掉4帧的。
我自己的经验和测试表明,根据应用程序的不同,停顿的时间可能会增大很多。比如,在官方的FIFA应用程序这一典型程序中,垃圾收集的停顿会非常厉害。
07-01 15:56:14.275: D/dalvikvm(30615): GCFORALLOC freed 4442K, 25% free 20183K/26856K, paused 24ms, total 24ms
07-01 15:56:16.785: I/dalvikvm-heap(30615): Grow heap (frag case) to 38.179MB for 8294416-byte allocation
07-01 15:56:17.225: I/dalvikvm-heap(30615): Grow heap (frag case) to 48.279MB for 7361296-byte allocation
07-01 15:56:17.625: I/Choreographer(30615): Skipped 35 frames! The application may be doing too much work on its main thread.
07-01 15:56:19.035: D/dalvikvm(30615): GCCONCURRENT freed 35838K, 43% free 51351K/89052K, paused 3ms+5ms, total 106ms
07-01 15:56:19.035: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 96ms
07-01 15:56:19.815: D/dalvikvm(30615): GCCONCURRENT freed 7078K, 42% free 52464K/89052K, paused 14ms+4ms, total 96ms
07-01 15:56:19.815: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 74ms
07-01 15:56:20.035: I/Choreographer(30615): Skipped 141 frames! The application may be doing too much work on its main thread.
07-01 15:56:20.275: D/dalvikvm(30615): GCFORALLOC freed 4774K, 45% free 49801K/89052K, paused 168ms, total 168ms
07-01 15:56:20.295: I/dalvikvm-heap(30615): Grow heap (frag case) to 56.900MB for 4665616-byte allocation
07-01 15:56:21.315: D/dalvikvm(30615): GCFORALLOC freed 1359K, 42% free 55045K/93612K, paused 95ms, total 95ms
07-01 15:56:21.965: D/dalvikvm(30615): GCCONCURRENT freed 6376K, 40% free 56861K/93612K, paused 16ms+8ms, total 126ms
07-01 15:56:21.965: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 111ms
07-01 15:56:21.965: D/dalvikvm(30615): WAITFORCONCURRENTGC blocked 97ms
07-01 15:56:22.085: I/Choreographer(30615): Skipped 38 frames! The application may be doing too much work on its main thread.
07-01 15:56:22.195: D/dalvikvm(30615): GCFORALLOC freed 1539K, 40% free 56833K/93612K, paused 87ms, total 87ms
07-01 15:56:22.195: I/dalvikvm-heap(30615): Grow heap (frag case) to 60.588MB for 1331732-byte allocation
07-01 15:56:22.475: D/dalvikvm(30615): GCFORALLOC freed 308K, 39% free 59497K/96216K, paused 84ms, total 84ms
07-01 15:56:22.815: D/dalvikvm(30615): GCFORALLOC freed 287K, 38% free 60878K/97516K, paused 95ms, total 95ms
上面的log是从FIFA应用程序运行后的几秒钟时间里截取的。垃圾收集器在短短的8秒内被执行了9次,导致应用程序总共卡顿了603ms,丢帧达214次。绝大多数的卡顿都来自内存分配请求,在log中以”GC_FOR_ALLOC“标签描述。
ART将整个垃圾收集系统做了重新设计和实现。为了能做些对比,下面给出使用ART运行相同的应用程序,在相同的场景下提取的log:
07-01 16:00:44.531: I/art(198): Explicit concurrent mark sweep GC freed 700(30KB) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 186us total 12.763ms
07-01 16:00:44.545: I/art(198): Explicit concurrent mark sweep GC freed 7(240B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 198us total 9.465ms
07-01 16:00:44.554: I/art(198): Explicit concurrent mark sweep GC freed 5(160B) AllocSpace objects, 0(0B) LOS objects, 792% free, 18MB/21MB, paused 224us total 9.045ms
07-01 16:00:44.690: I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 810% free, 38MB/58MB, paused 1.195ms total 87.219ms
07-01 16:00:46.517: I/art(29197): Background partial concurrent mark sweep GC freed 74626(3MB) AllocSpace objects, 39(4MB) LOS objects, 1496% free, 25MB/32MB, paused 4.422ms total 1.371747s
07-01 16:00:48.534: I/Choreographer(29197): Skipped 30 frames! The application may be doing too much work on its main thread.
07-01 16:00:48.566: I/art(29197): Background sticky concurrent mark sweep GC freed 70319(3MB) AllocSpace objects, 59(5MB) LOS objects, 825% free, 49MB/56MB, paused 6.139ms total 52.868ms
07-01 16:00:49.282: I/Choreographer(29197): Skipped 33 frames! The application may be doing too much work on its main thread.
07-01 16:00:49.652: I/art(1287): Heap transition to ProcessStateJankImperceptible took 45.636146ms saved at least 723KB
07-01 16:00:49.660: I/art(1256): Heap transition to ProcessStateJankImperceptible took 52.650677ms saved at least 966KB
ART和Dalvik的差别非常大,新的运行时内存管理仅仅停顿了12.364ms,运行了4次前台垃圾收集,以及2次后台垃圾收集。在应用程序执行的过程中,应用程序的堆空间大小并没有增加,而Dalvik虚拟机中堆空间共增加了4次。丢帧的个数方面,ART虚拟机也降到了63帧。
上面这段示例,只不过是一个开发并不完善的应用程序中最坏的一个场景。因为即使在ART虚拟机中,这个应用程序还是丢掉了不少帧渲染图像。不过上面的log对比依然很有参考价值,毕竟牛逼的程序员没几个,大多数的Android程序都没办法开发的很完美。Android需要能hold住这种情况。
ART将一些通常需要垃圾收集器做的工作,拆分给应用程序本身完成。这样,Dalvik中因为遍历堆空间引入的第一次停顿,就被完全消除了。而第二次停顿也因为一项预清理技术 (packard pre-cleaning)的应用而大大缩短。使用该技术后,只需要在清理完成后,简单的检查和验证时稍微停顿一下即可。Google声称,他们已经设法将这类停顿的时间缩短到3ms左右,相比Dalvik虚拟机的垃圾收集器来说,基本上是一个多数量级的降低,很不错了。
ART还引入了一个特殊的超大对象存储空间(large object space,LOS),这个空间与堆空间是分开的,不过仍然驻留在应用程序内存空间中。这一特殊的设计是为了让ART可以更好的管理较大的对象,比如位图对象(bitmaps)。在对堆空间分段时,这种较大的对象会带来一些问题。比如,在分配一个此类对象时,相比其他普通对象,会导致垃圾收集器启动的次数增加很多。有了这个超大对象存储空间的支持,垃圾收集器因堆空间分段而引发调用次数将会大大降低,这样垃圾收集器就能做更加合理的内存分配,从而降低运行时开销。
一个很好的例子,就是运行Hangouts(环聊)应用程序时,在Dalvik虚拟机中,我们能看到数次因为分配内存,运行GC而导致的停顿。
07-01 06:37:13.481: D/dalvikvm(7403): GCEXPLICIT freed 2315K, 46% free 18483K/34016K, paused 3ms+4ms, total 40ms
07-01 06:37:13.901: D/dalvikvm(9871): GCCONCURRENT freed 3779K, 22% free 21193K/26856K, paused 3ms+3ms, total 36ms
07-01 06:37:14.041: D/dalvikvm(9871): GCFORALLOC freed 368K, 21% free 21451K/26856K, paused 25ms, total 25ms
07-01 06:37:14.041: I/dalvikvm-heap(9871): Grow heap (frag case) to 24.907MB for 147472-byte allocation
07-01 06:37:14.071: D/dalvikvm(9871): GCFORALLOC freed 4K, 20% free 22167K/27596K, paused 25ms, total 25ms
07-01 06:37:14.111: D/dalvikvm(9871): GCFORALLOC freed 9K, 19% free 23892K/29372K, paused 27ms, total 28ms
我们从所有的垃圾收集log中截取了上述一段。其中的显式(GC_EXPLICIT)和并发(GC_CONCURRENT)是垃圾收集器中比较通用的清理和维护性调用。GC_FOR_ALLOC则是在内存分配器尝试分配新的内存空间,但堆空间不够用时,调用的。上面的log中,我们能看到堆空间因为分段操作而扩充了堆空间,但仍然无法装下大对象。在整个大对象分配的过程中,停顿时间长达90ms。
相比之下,下面这段log是从Android L预览版本的ART运行log中提取的。
07-01 06:35:19.718: I/art(10844): Heap transition to ProcessStateJankPerceptible took 17.989063ms saved at least -138KB
07-01 06:35:24.171: I/art(1256): Heap transition to ProcessStateJankImperceptible took 42.936250ms saved at least 258KB
07-01 06:35:24.806: I/art(801): Explicit concurrent mark sweep GC freed 85790(3MB) AllocSpace objects, 4(10MB) LOS objects, 850% free, 35MB/56MB, paused 961us total 83.110ms
我们目前还不知道log中的”Heap Transition”表达的什么意思,不过可以猜测应该是堆空间大小重设机制。在应用程序已经运行之后,唯一的对垃圾收集器的调用仅消耗的961us。我们并没有在这段截取的log之前,发现任何对垃圾收集器的调用操作。这段log中比较有趣的,就是LOS的统计。能够看到,在LOS中有4个较大的对象,共10MB。这块内存并没有分配在堆空间内,否则应该会有类似Dalvik的提示。
ART的内存分配系统本身也被重写了。虽然ART相比Dalvik,在内存分配方面,能够带来大约25%的性能提升,不过Google显然对此不满意,因此引入了一个新的内存分配器来取代当前使用的“malloc”分配器。
这个新的内存分配器,“rosalloc”(Runs-of-Slots-Allocator)是依据多线程Java应用程序的特点而设计的。此内存分配器有更细粒度的锁机制,可以直接对独立的对象上锁,而非对整个待分配的内存空间上锁。在线程局部区域中的小对象的分配,完全可以无视锁的存在了。没有了锁的请求和释放,线程局部小对象的访问速度也就大幅提升了。
这个新的内存分配器大幅提升了内存分配的速度,加速比达到了10x。
同时,ART的垃圾回收算法也做了改进,提升了用户使用体验,避免应用程序的卡顿。这些算法在Google内部目前仍然正在开发中。近期,Google仅仅介绍了一个新算法,“Moving Garbage Collector”.核心思想是,当应用程序运行在后台时,将程序的堆空间做段合并操作。