Dalvik是Google公司自己设计用于android平台的虚拟机。它可以支持已转换为 .dex（即Dalvik Executable）格式的Java应用程序的运行，.dex 格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

在 Android L (Android 5.0) 之前叫作 DVM，5.0 之后直接删除DVM，代替它的是传闻已久的ART（Android Runtime）。

在整个 Android 操作系统体系中，ART 位于下图黄色小方块位置：

不是说被删除就无用了，咱们毕竟做这一行的还是要简单的了解一下。

1.1 Dalvik 和 JVM 区别

Dalvik 基于寄存器，而 JVM 基于栈。
基于寄存器的虚拟机对于更大的程序来讲，在它们编译的时候，花费的时间更短。
JVM字节码中，局部变量会被放入局部变量表中，继而被压入堆栈供操做码进行运算，固然JVM也能够只使用堆栈而不显式地将局部变量存入变量表中。
Dalvik字节码中，局部变量会被赋给65536个可用的寄存器中的任何一个，Dalvik指令直接操做这些寄存器，而不是访问堆栈中的元素。

1.2 Dalvik 如何运行 java

VM字节码由.class文件组成，每一个文件一个class。
JVM在运行的时候为每个类装载字节码。相反的，Dalvik程序只包含一个.dex文件，这个文件包含了程序中全部的类。
Java编译器建立了JVM字节码以后，Dalvik的dx编译器删除.class文件，从新把它们编译成Dalvik字节码，而后把它们写进一个.dex文件中。这个过程包括翻译、重构、解释程序的基本元素（常量池、类定义、数据段）。
常量池描述了全部的常量，包括引用、方法名、数值常量等。类定义包括了访问标志、类名等基本信息。数据段中包含各类被VM执行的函数代码以及类和函数的相关信息（例如DVM所须要的寄存器数量、局部变量表、操做数堆栈大小），还有实例变量。

1.3 dex文件

class 文件是由一个 java 源码文件生成的 class 文件，而 Android 是把所有 class 文件进行合并优化，然后生成一个最终的 class.dex 文件。dex 文件去除了 class 文件中的冗余信息（比如重复字符常量），并且结构更加紧凑，因此在 dex 解析阶段，可以减少 I/O 操作，提高了类的查找速度。

实际上，dex 文件在 App 安装过程中还会被进一步优化为 odex(optimized dex)，此过程还会在后续介绍安装过程时再次提到。

注意：这一优化过程也会伴随着一些副作用，最经典的就是 Android 65535 问题。

65535 代表 dex 文件中的方法个数、属性个数、以及类的个数。也就是说理论上不止方法数，我们在 java 文件中声明的变量，或者创建的类个数如果也超过 65535 个，同样会编译失败，Android 提供了 MultiDex 来解决这个问题。很多网上的文章说 65535 问题是因为解析 dex 文件到数据结构 DexFile 时，使用了 short 来存储方法的个数，其实这种说法是错误的！

Android 65535问题解决

2. Android Runtime (ART)

Android Runtime (ART) 是运行 Android 5.0（API 级别 21）及更高版本的设备的默认运行时。此运行时提供大量功能，可提升 Android 平台和应用的性能和流畅度。

ART 是 Android 上的应用和部分系统服务使用的托管式运行时。ART 及其前身 Dalvik 最初是专为 Android 项目打造的。作为运行时的 ART 可执行 Dalvik 可执行文件并遵循 Dex 字节码规范。

ART 和 Dalvik 是运行 Dex 字节码的兼容运行时，因此针对 Dalvik 开发的应用也能在 ART 环境中运作。不过，Dalvik 采用的一些技术并不适用于 ART。

2.1 ART 功能

2.1.1 预先 (AOT) 编译

ART 引入了预先编译机制，可提高应用的性能。ART 还具有比 Dalvik 更严格的安装时验证。

在安装时，ART 使用设备自带的 dex2oat 工具来编译应用。此实用工具接受 DEX 文件作为输入，并为目标设备生成经过编译的应用可执行文件。该工具应能够顺利编译所有有效的 DEX 文件。但是，一些后处理工具会生成无效文件，Dalvik 可以接受这些文件，但 ART 无法编译这些文件。

2.1.2 垃圾回收方面的优化

垃圾回收 (GC) 会耗费大量资源，这可能有损于应用性能，导致显示不稳定、界面响应速度缓慢以及其他问题。ART 通过以下几种方式对垃圾回收做了优化：

大多采用并发设计，具有一次 GC 暂停；
并发复制，可减少后台内存使用和碎片；
GC 暂停的时间不受堆大小影响；
在清理最近分配的短时对象这种特殊情况中，回收器的总 GC 时间更短；
优化了垃圾回收的工效，能够更加及时地进行并行垃圾回收，这使得 GC_FOR_ALLOC 事件在典型用例中极为罕见。

2.1.3 开发和调试方面的优化

ART 提供了大量功能来优化应用开发和调试。

2.1.3.1 支持采样分析器

一直以来，开发者都使用 Traceview 工具（用于跟踪应用执行情况）作为分析器。虽然 Traceview 可提供有用的信息，但每次方法调用产生的开销会导致 Dalvik 分析结果出现偏差，而且使用该工具明显会影响运行时性能。

ART 添加了对没有这些限制的专用采样分析器的支持，因而可更准确地了解应用执行情况，而不会明显减慢速度。KitKat 版本为 Dalvik 的 Traceview 添加了采样支持。

Traceview：Traceview 已弃用。如果您使用的是 Android Studio 3.2 或更高版本，应改为使用 CPU 性能剖析器来执行以下操作：检查通过使用 Debug 类检测应用而捕获的 .trace 文件，记录新方法跟踪记录，保存 .trace 文件，以及检查应用进程的实时 CPU 使用情况。

2.1.3.2 支持更多调试功能

ART 支持许多新的调试选项，特别是与监控和垃圾回收相关的功能。例如，您可以：

查看堆栈跟踪中保留了哪些锁，然后跳转到持有锁的线程。
询问指定类的当前活动的实例数、请求查看实例，以及查看使对象保持有效状态的参考。
过滤特定实例的事件（如断点）。
查看方法退出（使用“method-exit”事件）时返回的值。
设置字段观察点，以在访问和/或修改特定字段时暂停程序执行。

2.1.3.3 优化了异常和崩溃报告中的诊断详细信息

当发生运行时异常时，ART 会为您提供尽可能多的上下文和详细信息。ART 会提供 java.lang.ClassCastException、java.lang.ClassNotFoundException 和 java.lang.NullPointerException 的更多异常详细信息。（较高版本的 Dalvik 会提供 java.lang.ArrayIndexOutOfBoundsException 和 java.lang.ArrayStoreException 的更多异常详细信息，这些信息现在包括数组大小和越界偏移量；ART 也提供这类信息。）

ART 还通过纳入 Java 和原生堆栈信息，在应用原生代码崩溃报告中提供更实用的上下文信息。

2.2 Android 8.0 中的 ART 功能改进

在 Android 8.0 版本中，Android Runtime (ART) 有了极大改进。下面的列表总结了设备制造商可以在 ART 中获得的增强功能。

2.2.1 并发压缩式垃圾回收器

正如 Google 在 Google I/O 大会上所宣布的那样，ART 在 Android 8.0 中提供了新的并发压缩式垃圾回收器 (GC)。该回收器会在每次执行 GC 时以及应用正在运行时对堆进行压缩，且仅在处理线程根时短暂停顿一次。该回收器具有以下优势：

GC 始终会对堆进行压缩：堆的大小平均比 Android 7.0 中的小 32%。
得益于压缩，系统现可实现线程局部碰撞指针对象分配：分配速度比 Android 7.0 中的快 70%。
H2 基准的停顿次数比 Android 7.0 GC 的少 85%。
停顿次数不再随堆的大小而变化，应用在使用较大的堆时也无需担心造成卡顿。
GC 实现细节 - 读取屏障：
- 读取屏障是在读取每个对象字段时所做的少量工作。
- 它们在编译器中经过了优化，但可能会减慢某些用例的速度。

2.2.2 循环优化

在 Android 8.0 版本中，ART 采取了多种循环优化措施，具体如下：

消除边界检查
- 静态：在编译时证明范围位于边界内
- 动态：运行时测试确保循环始终位于边界内（否则不进行优化）
消除归纳变量
- 移除无用归纳
- 用封闭式表达式替换仅在循环后使用的归纳
消除循环主体内的无用代码，移除整个死循环
强度降低
循环转换：逆转、交换、拆分、展开、单模等
SIMDization（也称为矢量化）

循环优化器位于 ART 编译器中一个独立的优化环节中。大多数循环优化与其他方面的优化和简化类似。采用比平时更复杂的方式进行一些重写 CFG 的优化时会面临挑战，因为大多数 CFG 实用工具（请参阅 nodes.h）都侧重于构建而不是重写 CFG。

2.2.3 类层次结构分析

在 Android 8.0 中，ART 会使用类层次结构分析 (CHA)，这是一种编译器优化，可根据对类层次结构的分析结果，将虚拟调用去虚拟化为直接调用。虚拟调用代价高昂，因为它们围绕 vtable 查找来实现，且会占用几个依赖负载。另外，虚拟调用也不能内嵌。

以下是对相关增强功能的总结：

动态单一实现方法状态更新 - 在类关联时间结束时，如果 vtable 已被填充，ART 会按条目对超类的 vtable 进行比较。
编译器优化 - 编译器会利用某种方法的单一实现信息。如果方法 A.foo 设置了单一实现标记，则编译器会将虚拟调用去虚拟化为直接调用，并借此进一步尝试内嵌直接调用。
已编译代码无效 - 另外，在类关联时间结束时，如果单一实现信息已更新，且方法 A.foo 之前拥有单一实现，但该状态现已变为无效，则依赖方法 A.foo 拥有单一实现这一假设的所有已编译代码都需要变为无效代码。
去优化 - 对于堆栈上已编译的有效代码，系统会启动去优化功能，以强制使已编译无效代码进入解释器模式，从而确保正确性。系统会采用结合了同步和异步去优化的全新去优化机制。

2.2.4 .oat 文件中的内嵌缓存

ART 现在采用内嵌缓存，并对有足够数据可用的调用站点进行优化。内嵌缓存功能会将额外的运行时信息记录到配置文件中，并利用这类信息将动态优化添加到预先编译中。

2.2.5 Dexlayout

Dexlayout 是在 Android 8.0 中引入的一个库，用于分析 dex 文件，并根据配置文件对其进行重新排序。Dexlayout 旨在使用运行时配置信息，在设备的空闲维护编译期间对 dex 文件的各个部分进行重新排序。通过将经常一起访问的部分 dex 文件集中在一起，程序可以因改进文件位置而拥有更好的内存访问模式，从而节省 RAM 并缩短启动时间。

由于配置文件信息目前仅在运行应用后可用，因此系统会在空闲维护期间将 dexlayout 集成到 dex2oat 的设备编译中。

2.2.6 Dex 缓存移除

在 Android 7.0 及更低版本中，DexCache 对象拥有四个大型数组，与 DexFile 中特定元素的数量成正比，即：

字符串（每个 DexFile::StringId 一个引用），
类型（每个 DexFile::TypeId 一个引用），
方法（每个 DexFile::MethodId 一个原生指针），
字段（每个 DexFile::FieldId 一个原生指针）。

这些数组用于快速检索我们以前解析的对象。在 Android 8.0 中，除方法数组外，所有数组都已移除。

2.2.7 解释器性能

在 Android 7.0 版本中，通过引入 mterp（一种解释器，具有以汇编语言编写的核心提取/解码/解释机制），解释器性能得以显著提升。Mterp 模仿了快速 Dalvik 解释器，并支持 arm、arm64、x86、x86_64、mips 和 mips64。对于计算代码而言，ART 的 Mterp 大致相当于 Dalvik 的快速解释器。不过，有时候，它的速度可能会显著变慢，甚至急剧变慢：

调用性能。
字符串操作和 Dalvik 中其他被视为内嵌函数的高频用户方法。
堆栈内存使用量较高。

Android 8.0 解决了这些问题。

2.2.8 详细了解内嵌

从 Android 6.0 开始，ART 可以内嵌同一个 dex 文件中的任何调用，但只能内嵌来自其他 dex 文件的叶方法。此项限制具有以下两个原因：

从其他 dex 文件进行内嵌要求使用该 dex 文件的 dex 缓存，这与同一个 dex 文件内嵌（只需重复使用调用方的 dex 缓存）有所不同。已编译代码中需要具有 dex 缓存，以便执行一系列指令，例如静态调用、字符串加载或类加载。
堆栈映射只对当前 dex 文件中的方法索引进行编码。

为了应对这些限制，Android 8.0 做出了以下改进：

从已编译代码中移除 dex 缓存访问（另请参阅“Dex 缓存移除”部分）
扩展堆栈映射编码。

2.2.9 同步方面的改进

ART 团队调整了 MonitorEnter/MonitorExit 代码路径，并减少了我们对 ARMv8 上传统内存屏障的依赖，尽可能将其替换为较新的（获取/释放）指令。

2.2.10 更快速的原生方法

使用 @FastNative 和 @CriticalNative 注解可以更快速地对 Java 原生接口 (JNI) 进行原生调用。这些内置的 ART 运行时优化可以加快 JNI 转换速度，并取代了现已弃用的 !bang JNI 标记。这些注解对非原生方法没有任何影响，并且仅适用于 bootclasspath 上的平台 Java 语言代码（无 Play 商店更新）。

@FastNative 注解支持非静态方法。如果某种方法将 jobject 作为参数或返回值进行访问，请使用此注解。

利用 @CriticalNative 注解，可更快速地运行原生方法，但存在以下限制：

方法必须是静态方法 - 没有参数、返回值或隐式 this 的对象。
仅将基元类型传递给原生方法。
原生方法在其函数定义中不使用 JNIEnv 和 jclass 参数。
方法必须使用 RegisterNatives 进行注册，而不是依靠动态 JNI 链接。

@FastNative 和 @CriticalNative 注解在执行原生方法时会停用垃圾回收。不要与长时间运行的方法一起使用，包括通常很快但一般不受限制的方法。

停顿垃圾回收可能会导致死锁。如果锁尚未得到本地释放（即尚未返回受管理代码），请勿在原生快速调用期间获取锁。此要求不适用于常规的 JNI 调用，因为 ART 将正执行的原生代码视为已暂停的状态。

@FastNative 可以使原生方法的性能提升高达 3 倍，而 @CriticalNative 可以使原生方法的性能提升高达 5 倍。

更多内容请参考：Android Runtime (ART) 和 Dalvik

3. 内存管理

Android Runtime (ART) 和 Dalvik 虚拟机使用分页和内存映射来管理内存。这意味着应用修改的任何内存，无论修改的方式是分配新对象还是轻触内存映射的页面，都会一直驻留在 RAM 中，并且无法换出。要从应用中释放内存，只能释放应用保留的对象引用，使内存可供垃圾回收器回收。这种情况有一个例外：对于任何未经修改的内存映射文件（如代码），如果系统想要在其他位置使用其内存，可将其从 RAM 中换出。

3.1 ART GC 概览

ART 有多个不同的 GC 方案，涉及运行不同的垃圾回收器。从 Android 8 (Oreo) 开始，默认方案是并发复制 (CC)。另一个 GC 方案是并发标记清除 (CMS)。

并发复制 GC 的一些主要特性包括：

CC 支持使用名为“RegionTLAB”的触碰指针分配器。此分配器可以向每个应用线程分配一个线程本地分配缓冲区 (TLAB)，这样，应用线程只需触碰“栈顶”指针，而无需任何同步操作，即可从其 TLAB 中将对象分配出去。
CC 通过在不暂停应用线程的情况下并发复制对象来执行堆碎片整理。这是在读取屏障的帮助下实现的，读取屏障会拦截来自堆的引用读取，无需应用开发者进行任何干预。
GC 只有一次很短的暂停，对于堆大小而言，该次暂停在时间上是一个常量。
在 Android 10 及更高版本中，CC 会扩展为分代 GC。它支持轻松回收存留期较短的对象，这类对象通常很快便会无法访问。这有助于提高 GC 吞吐量，并显著延迟执行全堆 GC 的需要。

ART 仍然支持的另一个 GC 方案是 CMS。此 GC 方案还支持压缩，但不是以并发方式。在应用进入后台之前，它会避免执行压缩，应用进入后台后，它会暂停应用线程以执行压缩。如果对象分配因碎片而失败，也必须执行压缩操作。在这种情况下，应用可能会在一段时间内没有响应。

由于 CMS 很少进行压缩，因此空闲对象可能会不连续。CMS 使用一个名为 RosAlloc 的基于空闲列表的分配器。与 RegionTLAB 相比，该分配器的分配成本较高。最后，由于内部碎片，Java 堆的 CMS 内存用量可能会高于 CC 内存用量。

3.2 垃圾回收

ART 或 Dalvik 虚拟机之类的受管内存环境会跟踪每次内存分配。一旦确定程序不再使用某块内存，它就会将该内存重新释放到堆中，无需程序员进行任何干预。这种回收受管内存环境中的未使用内存的机制称为"垃圾回收"。垃圾回收有两个目标：

在程序中查找将来无法访问的数对象
回收这些对象使用的资源。

Android 的内存堆是分代的，这意味着它会根据分配对象的预期寿命和大小跟踪不同的分配存储分区。

可参阅： Java 垃圾回收(GC)

3.3 共享内存

为了在 RAM 中容纳所需的一切，Android 会尝试跨进程共享 RAM 页面。它可以通过以下方式实现这一点：

每个应用进程都从一个名为 Zygote 的现有进程分叉。系统启动并加载通用框架代码和资源（如 Activity 主题背景）时，Zygote 进程随之启动。为启动新的应用进程，系统会分叉 Zygote 进程，然后在新进程中加载并运行应用代码。这种方法使为框架代码和资源分配的大多数 RAM 页面可在所有应用进程之间共享。
大多数静态数据会内存映射到一个进程中。这种方法使得数据不仅可以在进程之间共享，还可以在需要时换出。静态数据示例包括：Dalvik 代码（通过将其放入预先链接的 .odex 文件中进行直接内存映射）、应用资源（通过将资源表格设计为可内存映射的结构以及通过对齐 APK 的 zip 条目）和传统项目元素（如 .so 文件中的原生代码）。
在很多地方，Android 使用明确分配的共享内存区域（通过 ashmem 或 gralloc）在进程间共享同一动态 RAM。例如，窗口 surface 使用在应用和屏幕合成器之间共享的内存，而光标缓冲区则使用在内容提供器和客户端之间共享的内存。

由于共享内存的广泛使用，在确定应用使用的内存量时需要小心谨慎。

3.4 分配与回收应用内存

Dalvik 堆局限于每个应用进程的单个虚拟内存范围。这定义了逻辑堆大小，该大小可以根据需要增长，但不能超过系统为每个应用定义的上限。

堆的逻辑大小与堆使用的物理内存量不同。在检查应用堆时，Android 会计算按比例分摊的内存大小 (PSS) 值，该值同时考虑与其他进程共享的脏页和干净页，但其数量与共享该 RAM 的应用数量成正比。此 (PSS) 总量是系统认为的物理内存占用量。

Dalvik 堆不压缩堆的逻辑大小，这意味着 Android 不会对堆进行碎片整理来缩减空间。只有当堆末尾存在未使用的空间时，Android 才能缩减逻辑堆大小。但是，系统仍然可以减少堆使用的物理内存。垃圾回收之后，Dalvik 遍历堆并查找未使用的页面，然后使用 madvise 将这些页面返回给内核。因此，大数据块的配对分配和解除分配应该使所有（或几乎所有）使用的物理内存被回收。但是，从较小分配量中回收内存的效率要低得多，因为用于较小分配量的页面可能仍在与其他尚未释放的数据块共享。

3.5 限制应用内存

为了维持多任务环境的正常运行，Android 会为每个应用的堆大小设置硬性上限。不同设备的确切堆大小上限取决于设备的总体可用 RAM 大小。如果您的应用在达到堆容量上限后尝试分配更多内存，则可能会收到 OutOfMemoryError。

在某些情况下，例如，为了确定在缓存中保存多少数据比较安全，您可能需要查询系统以确定当前设备上确切可用的堆空间大小。您可以通过调用 getMemoryClass() 向系统查询此数值。此方法返回一个整数，表示应用堆的可用兆字节数。

3.6 切换应用

当用户在应用之间切换时，Android 会将非前台应用保留在缓存中。非前台应用就是指用户看不到或未运行前台服务（如音乐播放）的应用。例如，当用户首次启动某个应用时，系统会为其创建一个进程；但是当用户离开此应用时，该进程不会退出。系统会将该进程保留在缓存中。如果用户稍后返回该应用，系统就会重复使用该进程，从而加快应用切换速度。

如果您的应用具有缓存的进程且保留了目前不需要的资源，那么即使用户未使用您的应用，它也会影响系统的整体性能。当系统资源（如内存）不足时，它将会终止缓存中的进程。系统还会考虑终止占用最多内存的进程以释放 RAM。

❤️Android Runtime (ART) 和 Dalvik❤️

1. Dalvik