虚拟机（二）：Android 篇

虚拟机（一）：Java 篇

虚拟机（二）：Android 篇

Dalvik和JVM区别

• Dalvik 基于寄存器，而 JVM 基于栈。
  • 基于栈的架构具有更好的可移植性，因为其实现不依赖于物理寄存器
  • 基于栈的架构通常指令更短，因为其操作不需要指定操作数和结果的地址
  • 基于寄存器的架构通常运行速度更快，因为有寄存器的支撑
  • 基于寄存器的架构通常需要较少的指令来完成同样的运算，因为不需要进行压栈和出栈
  • 栈属于内存，速度稍慢，空间更大。寄存器属于CPU，速度更快，空间更小。
  • dex
    • dex格式是专为Dalvik设计的一种压缩格式，可以减少整体文件尺寸，提高I/O操作的速度，适合内存和处理器速度有限的系统。
    • dex文件格式相对来说更加的紧凑。dex文件按照类型（例如：常量，字段，方法）划分，将同一类型的元素集中到一起并且去掉了重复项进行存放。这样可以更大程度上避免重复，减少文件大小。
    • 为了便于开发者分析dex文件中的内容，Android系统中内置了dexdump工具。借助这个工具，我们可以详细了解到dex的文件结构和内容。oat文件也有对应的dump工具oatdump。

      ART和Dalvik区别

      

      • Dalvik是为32位设计的，不适用于64位CPU。
      • 编译
        • Dalvik：通过dexopt的工具将 APK 中内容 DEX 转化为 ODEX。在应用安装后，利用JIT进行部分编译，其他直接将字节码存储起来，在每次运行时，需要将字节码编译成机器语言。
        • ART：通过dex2oat的工具将 APK 中内容 DEX 编译成包含本地机器码 OAT。应用在安装后，会进行一次AOT（Ahead Of Time 运行前编译）预编译，将应用安装包中的字节码转换成机器语言存储在本地（系统只能运行二进制程序），这样，应用在运行时，可以直接执行这些二进制程序。Art上应用启动快，运行快，但是耗费更多存储空间，安装时间长，总的来说ART的功效就是"空间换时间"。
        • 内存分配器 内存空间
        • 垃圾回收
          • 将GC的停顿由2次改成1次
          • 在仅有一次的GC停顿中进行并行处理
          • 前后台划分

            JIT的回归

            • 解决系统、应用的安装、升级慢的问题
            • 编译生成的Oat文件中，既包含了原先的Dex文件，又包含了编译后的机器代码。而实际上，对于用户来说，并非会用到应用程序中的所有功能，因此很多时候编译生成的机器码是一直用不到的。
            • Android 7.0 中，Google又为Android添加了即时 (JIT) 编译器。JIT和AOT的配合，是取两者之长，避两者之短：在APK安装时，并不是一次性将所有代码全部编译成机器码。而是在实际运行过程中，对代码进行分析，将热点代码编译成机器码，让它可以在应用运行时持续提升 Android 应用的性能。

              AOT和JIT配合：

              • 最初在安装应用程序的时候不执行任何AOT编译。应用程序运行的前几次都将使用解释模式，并且经常执行的方法将被JIT编译。
              • 当设备处于空闲状态并正在充电时，编译守护进程会根据第一次运行期间生成的Profile文件对常用代码运行AOT编译。
              • 应用程序的下一次重新启动将使用Profile文件引导的代码，并避免在运行时为已编译的方法进行JIT编译。在新运行期间得到JIT编译的方法将被添加到Profile文件中，然后被编译守护进程使用。

                ART 内存模型

                

                

                • ImageSpace
                  • 永远不GC
                  • ZygoteSpace
                    • “full”gc条件下才会扫描该区域
                    • 本身没有创建相关的内存资源，而是通过外部传入的MemMap对象，作为内存资源，自身只是起到了一个管理作用
                    • 继承自Zygote进程的资源存放地
                    • MallocSpace
                      • 每次GC都会尝试清除该区域
                      • DlmallocSpace：采用的是dlmalloc内存分配管理模型，它是一个开源库，也是c语言malloc调用的具体实现。
                      • RosAllocSpace：采用的是谷歌自己的内存分配rosalloc完成。rosalloc是一种动态分配内存算法，专门为了art虚拟机做了适配，其实它是一种多粒度内存分配算法，ros的意思就是run of slot，可以理解为一个run是RosAllocSpace中内存分配的单元，每个Run有自己的内存分配粒度（slot）
                      • LargeObjectSpace
                        • 每次GC都会尝试清除该区域
                        • 采用mmap去分配内存空间
                        • 不连续
                        • large_object_threshold_默认为12kb
                        • RegionSpace
                          • 每次GC都会尝试清除该区域
                          • 内存块分配
                          • 内存对齐，由属性kRegionSize决定（每个Region默认1m）
                          • 每个Region本身还对应一个状态RegionState
                          • Copying Collection（拷贝垃圾回收机制）的内存分配模型
                          • BumpPointerSpace
                            • 每次GC都会尝试清除该区域
                            • 顺序分配

                              内存分配器：

                              • Davlik虚拟机使用的是传统的 dlmalloc 内存分配器进行内存分配。这个内存分配器是Linux上很常用的
                              • Google为ART虚拟机开发了一个基于位图的新内存分配器：RoSalloc，它的全称是Rows of Slots allocator。RoSalloc相较于dlmalloc来说，在多线程环境下有更好的支持，具有分片锁：在dlmalloc中，分配内存时使用了全局的内存锁，这就很容易造成性能不佳。而在RoSalloc中，当分配规模较小时可添加线程的本地缓冲区，允许在线程本地区域存储小对象，这就是避免了全局锁的等待时间。
                              • ART虚拟机中，这两种内存分配器都有使用。
                              • RegionTLAB：从 Android 8 (Oreo) 开始，默认垃圾回收方案是并发复制 (CC)。CC 支持使用名为“RegionTLAB”的触碰指针分配器。此分配器可以向每个应用线程分配一个线程本地分配缓冲区 (TLAB)，这样，应用线程只需触碰“栈顶”指针，而无需任何同步操作，即可从其 TLAB 中将对象分配出去。
                              • RosAlloc 是基于空闲列表的分配器，与 RegionTLAB 相比，该分配器的分配成本较高。由于 CMS 很少进行压缩，因此空闲对象可能会不连续，导致碎片更多。

                                ART GC

                                触发垃圾回收：

                                • kGcCauseForAlloc 内存分配失败
                                • kGcCauseBackground 后台进程的垃圾回收，为了确保内存的充足
                                • kGcCauseExplicit 明确的System.gc()调用
                                • kGcCauseForNativeAlloc 由于native的内存分配
                                • kGcCauseCollectorTransition 垃圾收集器发生了切换
                                • kGcCauseHomogeneousSpaceCompact 当前景和后台收集器都是CMS时，发生了后台切换
                                • kGcCauseClassLinker ClassLinker导致

                                  抛开System.gc引起的主动gc，大部分GC由ConcurrentGCTask与分配时AllocInternalWithGc触发

                                  回收策略：

                                  • Sticky 仅仅释放上次GC之后创建的对象。基于“分代”的垃圾回收思想
                                  • Partial 仅仅对应用程序的堆进行垃圾回收，但是不处理Zygote的堆
                                  • Full 会对应用程序和Zygote的堆都会进行垃圾回收

                                    综述：

                                    • ART 有多个不同的 GC 方案，这些方案包括运行不同垃圾回收器。在heap.cc的CollectGarbageInternal方法中，会根据当前的GC类型和原因，选择合适的垃圾回收器，然后执行垃圾回收。
                                    • CMS（Concurrent Mark Sweep，并发标记清除）方案，主要使用粘性（sticky）CMS 和部分（partial）CMS。
                                    • 粘性（sticky）CMS
                                      • 粘性CMS是ART的不移动（non-moving ）分代垃圾回收器，增加了GC吞吐量。
                                      • 它仅扫描堆中自上次 GC 后修改的部分，并且只能回收自上次GC后分配的对象。
                                      • 不同于普通的分代GC，粘性 CMS 不会移动。年轻对象被保存在一个分配堆栈（基本上是 java.lang. Object 数组）中，而非为其设置一个专用区域。这样可以避免移动所需的对象以维持低暂停次数，但缺点是容易在堆栈中加入大量复杂对象图像而使堆栈变长。
                                      • 前后台
                                        • 当应用将进程状态更改为察觉不到卡顿的进程状态（例如，后台或缓存）时，ART 将暂停应用线程以执行堆压缩。
                                        • Compact类型的垃圾回收器便是“标记-压缩”算法。这种类型的垃圾回收器，会在将对象清理之后，将最终还在使用的内存空间移动到一起，这样可以既可以减少堆中的碎片，也节省了堆空间。但是由于这种垃圾回收器需要对内存进行移动，所以耗时较多，因此这种垃圾回收器适合于切换到后台的应用。
                                        • 垃圾回收器的决定会在Heap初始化的时候，选择垃圾回收器，需要指定前台垃圾回收器与后台垃圾回收器
                                        • 在前台环境下，用户对于卡顿会更加敏感，因此需要选择更快的垃圾回收，而后台环境下，卡顿不敏感，因此需要进行内存的整理，便于内存块的整合
                                        • android7前台是CMS（Concurrent Mark Sweep，并发标记清除），后台是HSC。
                                        • 并发复制 (CC)
                                          • 从 Android 8 (Oreo) 开始，默认方案是并发复制 (CC)。
                                          • 通过在不暂停应用线程的情况下并发复制对象来执行堆碎片整理。这是在读取屏障的帮助下实现的，读取屏障会拦截来自堆的引用读取，无需应用开发者进行任何干预。
                                          • GC 只有一次很短的暂停，对于堆大小而言，该次暂停在时间上是一个常量。
                                          • 在 Android 10 及更高版本中，CC 会扩展为分代 GC。轻松回收存留期较短的对象，并显著延迟执行全堆 GC 的需要。