Android 虚拟机 Vs Java 虚拟机

读书笔记，如需转载，请注明做者：Yuloran (t.cn/EGU6c76)

前言

本文分为两部分，第一部分为 《Garbage Collection in Android》 的翻译，第二部分简介 Android 虚拟机与 Java 虚拟机的差异。

Garbage Collection in Android

演讲人介绍

Colt McAnlis，Google 开发工程师。为便于写做，笔者将以第一人称视角对视频内容进行概述。

自动内存管理的陷进

不少高性能语言，如 C 和 C++ 都须要开发人员手动管理内存的分配与释放，但在代码量很大、业务逻辑很复杂时，很容易忘记释放已分配的内存，进而致使内存泄露。位于 Android Runtime 的 Dalvik（< Android 5.0） 或 ART（≥ Android 5.0）虚拟机的自动垃圾回收机制，将开放人员从手动管理内存的工做方式中解放了出来，从而提升了工做效率。但同时也隐藏了性能陷进，其中最须要关注的就是如何分配以及使用内存。

GC 概念由来

自动内存管理机制称为 Garbage Collection，是 John McCarthy 于1959 年提出的概念，用于解决 LISP 语言中的问题。它主要涉及两个原则：

1. 找出再也不访问的对象；
2. 回收这些对象占用的资源。

GC 实现的难点

想象一下，你分配了 20,000 个对象，那么怎么识别哪些对象是再也不访问的，或者何时应该触发 GC 事件呢？

这真是太难了！好在，自 GC 概念提出以后的 50 年里，咱们一直致力于提高垃圾收集器的性能，这也是为何 Android 的垃圾回收器比 John McCarthy 提出的复杂的多的缘由。

Android GC 简介

事实上，Android 系统根据所分配对象的类型以及 GC 时系统如何管理这些对象，将进程所使用的内存分红了多个空间。新分配的对象位于什么空间，取决于你的 Android Runtime 是什么版本，5.0 以上是 ART（Android Runtime）虚拟机，5.0如下是 Dalvik 虚拟机。

笔者注：上图具体含义见下文差别分析。

每一个空间都有大小限制（Set Size），系统会跟踪整个程序所占用的内存大小。当程序占用内存达到必定程度时，系统就会触发 GC 事件回收内存，以便未来分配给其它对象：

GC 事件在 Dalvik 虚拟机和 ART 虚拟机上的表现也不尽相同。在 Dalvik 虚拟机中，不少 GC 事件都是 "Stop the World Event"：

而 ART 虚拟机扩展了并行 GC 算法，消除了大的 GC 停顿时间，可是在重要步骤上，仍是会有短暂的停顿：

GC 致使的掉帧

尽管系统工程师作了大量优化来提高 GC 速度来减小卡顿，可是你的 App 仍然可能存在性能问题。咱们知道，Android 系统每 16 ms 就要渲染一帧，因此在一帧时间内，GC 时间越长，留给业务逻辑的时间就越短：

若是你的 GC 过于频繁（好比在循环中建立了大量临时对象）或 GC 时间过长，就会致使 1 帧的处理时间超过 16 ms 上限，这就会给用户形成卡顿、掉帧的视觉效果：

内存分析工具

好在，Android Studio 的 Profiler 工具，能够用来查看内存使用状况以及内存分配状况。

总结

不过，内存优化就是提及来简单，作起来难，因此你还须要观看如下视频来掌握更多的性能优化知识：

连接

Android 虚拟机与 Java 虚拟机的差别

其实笔者主要想关注的这几个虚拟机在内存布局及 GC 算法方面的差别，至于 JVM、Dalvik、ART 各自对应的可执行文件格式（.jar、.dex、.elf）、字节码结构（class、dex、elf）这显然是不一样的。奈何关于 Android 虚拟机内存布局网上资料甚少，大部分只围绕运行时堆内存的分配及其 GC 算法来说，没有涉及虚拟机栈（方法执行模型）、常量池、方法区，因此这部分无法跟 Java 虚拟机进行对比。不过，万物之间是存在广泛联系的，没有东西能够凭空产生。既然 Java 虚拟机的方法执行模型都能跟 C 语言在概念上很类似，Dalvik 和 ART 天然也能够照此理解，细节上确定是不同的，毕竟指令集都不同。真想深究，只能看 虚拟机源码 了。

不钻牛角尖了，头疼。再来看下这个图：

这图描述的就是 Dalvik 和 ART 虚拟机对运行时堆的空间划分，这个在源码中都有对应的实现。 上图具体含义可参考：

• 《Dalvik虚拟机垃圾收集机制简要介绍和学习计划 》 - 罗升阳
• 《ART运行时垃圾收集机制简要介绍和学习计划》 - 罗升阳

或者使用 看云 阅读更方便。

总的来讲，就是 Android 虚拟机没有使用 HotSpot 虚拟机所采用的分代收集算法，而是采用了标记-清除或者标记-复制算法，这个能够在编译系统时指定，可参考《Android Garbage Collection/dalvik GC》，不过通常都是标记清除算法。

如下摘自 《Android虚拟机之Dalvik虚拟机》：

• 内存管理

  ◇ Java Object Heap 大小受限，如：16M/24M/32M/48M
  ◇ Bitmap Memory(External Memroy)：大小计入 Java Object Heap
  ◇ Native Heap：大小不受限

• 垃圾收集(GC)

  ◇ Mark：使用RootSet标记对象引用
  ◇ Sweep：回收没有被引用的对象
  

• GingerBread（Android 2.3）以前

  ◇ Stop-the-word：也就是垃圾收集线程在执行的时候，其它的线程都中止
  ◇ Full heap collection：也就是一次收集彻底部的垃圾，一次垃圾收集形成的程序停止时间一般都大于 100ms

• GingerBread（Android 2.3）以后

  ◇ Cocurrent：也就是大多数状况下，垃圾收集线程与其它线程是并发执行的
  ◇ Partial collection：也就是一次可能只收集一部分垃圾，一次垃圾收集形成的程序停止时间一般都小于 5ms

ART 虚拟机对并行 GC 进行了扩展，将堆内存划分红更多不一样类型的具体空间，使用不一样的 GC 算法以得到更短的 GC 停顿时间。

Dalvik 虚拟机

wiki

Dalvik 虚拟机，是 Google 等厂商合做开发的 Android 移动设备平台的核心组成部分之一。它能够支持已转换为 .dex（即“Dalvik Executable”）格式的 Java 应用程序的运行。.dex 格式是专为 Dalvik 设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 由 Dan Bornstein 编写的，名字来源于他的祖先曾经居住过的小渔村达尔维克（Dalvík），位于冰岛 Eyjafjörður。

大多数虚拟机包括 JVM 都是一种堆栈机器，而 Dalvik 虚拟机则是寄存器机。两种架构各有优劣，通常而言，基于堆栈的机器须要更多指令，而基于寄存器的机器指令更长。

从 Android 5.0 版起，Android Runtime（ART）取代 Dalvik 成为系统内默认虚拟机。

差别：

• Dalvik 虚拟机早期并无使用即时编译（JIT）技术。从 Android 2.2 开始, Dalvik 虚拟机也支持 JIT.
• Dalvik 虚拟机有本身的字节码，并不是使用 Java 字节码。
• Dalvik 基于寄存器，而 JVM 基于堆栈。
• Dalvik VM 透过 Zygote 进行类别的预加载，Zygote 会完成虚拟机的初始化，也是与 JVM 不一样之处。

标记-清除算法（Mark-Sweep Algorithm）

Dalvik 虚拟机采用 Mark-Sweep 算法，不带压缩整理（Compact），因此比 Java 虚拟机更简单一些。

（a）GC 前的状态。示例中有一个 GC Root，全部对象都未被标记。

（b）GC 标记后的状态。在标记阶段，全部活动对象（Active Objects）都会被标记。

（c）GC 清除后的状态。全部垃圾已被回收，而且全部活动对象的标记状态都被重置为 false。

GC 触发时机

• 即将产生 OOM 时
• 堆内存使用达到上限时（系统可配）
• 显示调用 gc()

GC 日志

在 Dalvik（而不是 ART）中，每次垃圾回收都会将如下信息打印到 logcat 中：

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
复制代码

示例：

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
复制代码

垃圾回收缘由

什么触发了垃圾回收以及是哪一种回收。可能出现的缘由包括：

• GC_CONCURRENT：在您的堆开始占用内存时能够释放内存的并发垃圾回收。
• GC_FOR_MALLOC：堆已满而系统不得不中止您的应用并回收内存时，您的应用尝试分配内存而引发的垃圾回收。
• GC_HPROF_DUMP_HEAP：当您请求建立 HPROF 文件来分析堆时出现的垃圾回收。
• GC_EXPLICIT：显式垃圾回收，例如当您调用 gc() 时（您应避免调用，而应信任垃圾回收会根据须要运行）。
• GC_EXTERNAL_ALLOC：这仅适用于 API 级别 10 及更低级别（更新版本会在 Dalvik 堆中分配任何内存）。外部分配内存的垃圾回收（例如存储在原生内存或 NIO 字节缓冲区中的像素数据）。

释放量

今后次垃圾回收中回收的内存量。

堆统计数据

堆的可用空间百分比与（活动对象数量）/（堆总大小）。

外部内存统计数据

API 级别 10 及更低级别的外部分配内存（已分配内存量）/（发生回收的限值）。

暂停时间

堆越大，暂停时间越长。并发暂停时间显示了两个暂停：一个出如今回收开始时，另外一个出如今回收快要完成时。 在这些日志消息积聚时，请注意堆统计数据的增大（上面示例中的 3571K/9991K 值）。若是此值继续增大，可能会出现内存泄漏。

ART 虚拟机

wiki

Android Runtime（缩写为ART），是一种在 Android 操做系统上的运行环境，由 Google 公司研发，并在 2013 年做为 Android 4.4 系统中的一项测试功能正式对外发布，在 Android 5.0 及后续 Android 版本中做为正式的运行时库取代了以往的 Dalvik 虚拟机。ART 可以把应用程序的字节码转换为机器码，是 Android 所使用的一种新的虚拟机。它与 Dalvik 的主要不一样在于：Dalvik 采用的是 JIT 技术，而 ART 采用 Ahead-of-time（AOT）技术。ART 同时也改善了性能、垃圾回收（Garbage Collection）、应用程序出错以及性能分析。

JIT 最先在 Android 2.2 系统中引进到 Dalvik 虚拟机中，在应用程序启动时，JIT 经过进行连续的性能分析来优化程序代码的执行，在程序运行的过程当中，Dalvik 虚拟机在不断的进行将字节码编译成机器码的工做。与 Dalvik 虚拟机不一样的是，ART 引入了 AOT 这种预编译技术，在应用程序安装的过程当中，ART 就已经将全部的字节码从新编译成了机器码。应用程序运行过程当中无需进行实时的编译工做，只须要进行直接调用。所以，ART 极大的提升了应用程序的运行效率，同时也减小了手机的电量消耗，提升了移动设备的续航能力，在垃圾回收等机制上也有了较大的提高。为了保证向下兼容，ART 使用了相同的 Dalvik 字节码文件（dex），即在应用程序目录下保留了 dex 文件供旧程序调用然而 .odex 文件则替换成了可执行与可连接格式（ELF）可执行文件。一旦一个程序被 ART 的 dex2oat 命令编译，那么这个程序将会指经过 ELF 可执行文件来运行。所以，相对于 Dalvik 虚拟机模式，ART 模式下 Android 应用程序的安装须要消耗更多的时间，同时也会占用更大的储存空间（指内部储存，用于储存编译后的代码），但节省了不少 Dalvik 虚拟机用于实时编译的时间。

Google 公司在 Android 4.4 中带来的 ART 模式仅仅是 ART 的一个预览版，系统默认仍然使用的是 Dalvik 虚拟机，4.4 上面提供的预览版 ART 相对于 Android 5.0 之后的 ART 运行时库有较大的不一样，尤为体如今兼容性上。

GC 日志

与 Dalvik 不一样，ART 不会为未明确请求的垃圾回收记录消息。只有在认为垃圾回收速度较慢时才会打印垃圾回收。更确切地说，仅在垃圾回收暂停时间超过 5ms 或垃圾回收持续时间超过 100ms 时。若是应用未处于可察觉的暂停进程状态，那么其垃圾回收不会被视为较慢。始终会记录显式垃圾回收。

ART 会在其垃圾回收日志消息中包含如下信息：

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>
复制代码

示例：

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms
复制代码

垃圾回收缘由

什么触发了垃圾回收以及是哪一种回收。可能出现的缘由包括：

• Concurrent：不会暂停应用线程的并发垃圾回收。此垃圾回收在后台线程中运行，并且不会阻止分配。
• Alloc：您的应用在堆已满时尝试分配内存引发的垃圾回收。在这种状况下，分配线程中发生了垃圾回收。
• Explicit：由应用明确请求的垃圾回收，例如，经过调用 gc() 或 gc()。与 Dalvik 相同，在 ART 中，最佳作法是您应信任垃圾回收并避免请求显式垃圾回收（若是可能）。不建议使用显式垃圾回收，由于它们会阻止分配线程并没必要要地浪费 CPU 周期。若是显式垃圾回收致使其余线程被抢占，那么它们也可能会致使卡顿（应用中出现间断、抖动或暂停）。
• NativeAlloc：原生分配（如位图或 RenderScript 分配对象）致使出现原生内存压力，进而引发的回收。
• CollectorTransition：由堆转换引发的回收；此回收由运行时切换垃圾回收引发。回收器转换包括将全部对象从空闲列表空间复制到碰撞指针空间（反之亦然）。当前，回收器转换仅在如下状况下出现：在 RAM 较小的设备上，应用将进程状态从可察觉的暂停状态变动为可察觉的非暂停状态（反之亦然）。
• HomogeneousSpaceCompact[/ˌhɒmə(ʊ)'dʒiːnɪəs/]：齐性空间压缩是空闲列表空间到空闲列表空间压缩，一般在应用进入到可察觉的暂停进程状态时发生。这样作的主要缘由是减小 RAM 使用量并对堆进行碎片整理。
• DisableMovingGc：这不是真正的垃圾回收缘由，但请注意，发生并发堆压缩时，因为使用了 GetPrimitiveArrayCritical，回收遭到阻止。通常状况下，强烈建议不要使用 GetPrimitiveArrayCritical，由于它在移动回收器方面具备限制。
• HeapTrim：这不是垃圾回收缘由，但请注意，堆修剪完成以前回收会一直受到阻止。

垃圾回收名称

ART 具备能够运行的多种不一样的垃圾回收。

• Concurrent mark sweep (CMS)：整个堆回收器，会释放和回收映像空间（Image Space）之外的全部其余空间。
• Concurrent partial mark sweep：几乎整个堆回收器，会回收除了映像空间（Image Space）和 zygote 空间之外的全部其余空间。
• Concurrent sticky mark sweep：生成回收器，只能释放自上次垃圾回收以来分配的对象。此垃圾回收比完整或部分标记清除运行得更频繁，由于它更快速且暂停时间更短。
• Marksweep + semispace：非并发、复制垃圾回收，用于堆转换以及齐性空间压缩（对堆进行碎片整理）。

释放的对象

这次垃圾回收从非大型对象空间回收的对象数量。

释放的大小

这次垃圾回收从非大型对象空间回收的字节数量。

释放的大型对象

这次垃圾回收从大型对象空间回收的对象数量。

释放的大型对象大小

这次垃圾回收从大型对象空间回收的字节数量。

堆统计数据

空闲百分比与（活动对象数量）/（堆总大小）。

暂停时间

一般状况下，暂停时间与垃圾回收运行时修改的对象引用数量成正比。当前，ART CMS 垃圾回收仅在垃圾回收即将完成时暂停一次。移动的垃圾回收暂停时间较长，会在大部分垃圾回收期间持续出现。

若是您在 logcat 中看到大量的垃圾回收，请注意堆统计数据的增大（上面示例中的 25MB/38MB 值）。若是此值继续增大，且始终没有变小的趋势，则可能会出现内存泄漏。或者，若是您看到缘由为“Alloc”的垃圾回收，那么您的操做已经快要达到堆容量，而且将很快出现 OOM 异常。

附

官网 GC 日志原文

这个网页好像没有英文版，可是有的中文解释又很别扭，好比“映像空间”，这是什么鬼？其实就是 Image Space...