转载自： https://blog.csdn.net/luos Hengyang/article/details/45017207
与ios相比，安卓一直是恶劣的流传方式。 android不顺畅的部分问题是由于其APP应用程序和某些系统服务运行在虚拟机或Dalvik虚拟机上，而IOs APP应用程序和系统服务直接执行本地计算机的指令。 除了用ATR替换Dalvik外，还必须确保Android从3开始。 从0开始，全力改善系统的顺利性。 例如，在3.0中，添加了APP应用程序2D UI的硬件加速渲染或GPU渲染。 在此之前，APP应用程序的2D UI是用软件渲染的。 也就是说，曾被CPU渲染过。 另外，通过4.1projectbutter，在UI体系结构中引用了VSYNC、Triple Buffer、HWComposer等技术，大大提高了UI的流动性。
ART比Dalvik快是因为ART执行本地机器指令，Dalvik执行Dex字节码，然后由解释器执行。 Dalvik对频繁执行的代码进行JIT，生成本地机器指令并执行，但原本在APP应用的执行中花费成本将Dex字节码翻译成机器指令也会影响APP应用自身的执行，因此即使Dalvik使用了JIT
Dalvik是android 4.4和职权中使用的虚拟机。 使用JIT(justintime )技术进行代码翻译，每次执行APP应用时，Dalvik都会将程序代码编译成机器语言并执行。 随着硬件水平的发展和人们对更高性能的需求，Dalvik虚拟机的不足越来越突出。 所产生的art(Androidruntime )虚拟机采用AOT (aheadoftime )技术处理机制的根本差异，并在APP应用安装时转换为机器语言，在运行时不再进行解释，从而APP盒在内存管理方面，ART也得到了相对较大的改进，对内存分配和回收进行了算法优化，减少了内存碎片，也缩短了回收时间。
与Dalvik虚拟机的垃圾回收机制类似，ART运行时的垃圾回收机制也包括Zygote堆、Active堆、Card Table、Heap Bitmap，如图1所示
从图1可以看到，ART运行时堆分为四个空间： Image Space、Zygote Space、Allocation Space和Large Object Space。 这里，Image Space、Zygote Space、Allocation Space是在地址上连续的空间，被称为Continuous Space，Large ObjectSpace是几个离散地址的集合，使用几个大的空间
Image Space和Zygote Space之间分隔着用于映射system @ framework @ boot.ar @ classes.oat文件的内存。 system @ framework @ boot.ar @ classes.oat是从系统启动类路径中的所有Dex文件翻译的oat文件，其中Image Space空间需要预加载系统类对象这是在需要预加载的类对象生成名为system @ framework @ boot.ar @ classes.oat的oat文件时创建的，文件system @ framework @ boot.oat 意味着以后保存在系统启动类路径中，然后每次启动系统时，只需将文件system @ framework @ boot.ar @ classes.oat直接映射到内存中，创建每个类的对象的时间就足够了如果以前将Dalvik虚拟机作为APP应用程序运行，则每次引导系统时，都必须为预加载的类创建类对象。 因此，ART运行时第一次启动时速度较慢，但以后启动实际上会更快。
Zygote Space和Allocation Space与Dalvik虚拟机的垃圾回收机制中的Zygote和Active堆的作用相同。 Zygote Space在Zygote进程和APP应用程序进程之间共享，分配空间对于每个进程是独占的。 同样，Zygote进程最初只有一个图像空间和一个Zygote空间。 在Zygote进程fork的第一个子进程之前，Zygote Space将会分为两部分。 原来使用的部分堆又称为Zygote Space，未使用的部分堆又称为Allocation Space。 所有后续对象都将分配给分配空间。 Large Object Space是用于分配大对象(如图像分配)的离散地址的集合。
通过这种方式，Image Space和Zygote Space在Zygote进程和APP进程之间共享，并且分配空间由每个进程独立拥有。 虽然Image Space和Zygote Space都在Zygote进程和APP应用程序进程之间共享，但请注意，只创建一次前一个对象，并且每次系统引导时都必须根据运行情况重新创建后一个对象
ART垃圾收集流程
ART运行的每一个Space都有不同的回收策略，ART运行时根据这个特性提供了可爱的大白 Sweep、Partial 可爱的大白 Sweep和Sticky 可爱的大白 Sweep等三种回收力度不同的垃圾收集器。其中，可爱的大白 Sweep的垃圾回收力度最大，它会同时回收Zygote Space、Allocation Space和Large Object Space的垃圾，Partial 可爱的大白Sweep的垃圾回收力度居中，它只会同时回收Allocation Space 和Large Object Space的垃圾，而Sticky 可爱的大白 Sweep的垃圾回收力度最小，它只会回收Allocation Stack的垃圾，即上次GC以后分配出来的又不再使用了的对象。力度越大的垃圾收集器，回收垃圾时需要的时候也就越长。这样我们就可以在应用程序运行的过程中根据不同的情景使用不同的垃圾收集器，那就可以更有效地执行垃圾回收过程。另外在Android 5.0以后的ART中，还引入了Semi-Space(SS)GC和Generaltional Semi-Space(GSS)、可爱的大白-Compact(Mc)GC的三个Compaction GC，可以有效地解决内存碎片问题。
Semi-Space（SS）GC和Generational Semi-Space（GSS）GC是ART运行时引进的两个Compacting GC。它们的共同点都具有一个From Space和一个To Space。在GC执行期间，在From Space分配的还存活的对象会被一次拷贝到To Space中，这样就可以达到消除内存碎片的目的。
与SS GC相比，GSS GC 还多了一个Promote Space。当一个对象是在上一次GC之前分配的，并且在当前GC中仍然是存活的，那么它就会被拷贝到Promote Space中，而不是To Space中。这相当于是简单地将对象划分为新生代和老生代的，即在上一次GC之前分配的对象属于老生代的，而在上一次GC之后分配的对象属于新生代的。一般来说，老生代对象的存活性要比新生代的久，因此将它们拷贝到Promote Space中去，可以避免每次执行SS GC或者GSS GC时，都需要对它们进行无用的处理。
总结来说，SS GC和GSS GC的执行过程就如下图所示：
如上图所示，Bump Pointer Space 1和Bump Pointer Space2就是我们前面说的From Space和To Space。
除了Semi-Space GC和Generational Semi-Space GC，ART运行时还引入了第三种Compacting GC：可爱的大白-Compact(MC) GC。这三种GC虽然都是Compacting GC，不过它们的实现方式却有很大不同。SSGC和GSS GC需两个Space来压缩内存，而MC GC只需一个Space来压缩内存。
可爱的大白-compact GC主要是针对ART运行时正在使用的Bump Pointer Space进行压缩，如下图所示：
从图1可以看出，当可爱的大白-Compact GC执行完成之后，原来位于Bump Pointer Space上的仍然存活的对象会被一次移动至原Bump Pointer Space的左侧，并且按地址从小到大紧凑地排列在一起。这个过程不需要借助于额外的Space来完成。这一点是可爱的大白-Compact GC与Semi-Space GC、Generational Semi-Space GC的显著区别。
ART 与Dalvik比较1、ART有很多GC方式可以选择，而Dalvik只有一种GC方式。
2、ART通过额外记录新分配的对象来支持更好的轻量级Sticky GC。
ART中新增的轻量级回收kGcTypeSticky只回收上次GC后再Allocation Space中新分配的垃圾对象，Heap 类的成员函数RecordAllocation首先是记录当前已经分配的内存字节数以及对象数，为了Sticky GC，还要接着再将新分配的对象压入到Heap类的成员变量allocation_stack_描述的Allocation Stack中去，而Dalvik虚拟机直接将新分配出来的对象记录在Live Bitmap中。如果不能成功将新分配的对象压入到Allocation Stack中，就说明上次GC以来，新分配的对象太多了，因此这时候就需要执行一个Sticky GC，将Allocation Stack里面的垃圾进行回收，然后再尝试将新分配的对象压入到Allocation Stack中，直到成功为止。
3、大内存块额外单独管理，可以提高内存分配和回收效率。
4、减少Suspend时间。
对于并行GC，在Handle Dirty Object阶段是在挂起ART运行时线程的前提下进行的，因此，如果把所有的Dirty Card 都放在Handle Dirty Object阶段处理，那么就会可能会造成应用程序停顿时间过长。于是，ART运行时就在并行可爱的大白ing阶段也帮忙着处理Dirty Card，通过这种方式尽量减少在Handle Dirty Object阶段需要处理的Dirty Card，以达到减少应用程序因为GC造成的停顿时间。另外ART在垃圾回收过程中，也减少了挂起非GC线程的次数。