Google I/O 2014 & 2015 之 ART

2014参考http://blog.csdn.net/innost/article/details/38358191

2015参考http://www.25pp.com/news/news_73878.html

 

Google Android 2014 I/O 新技术 

 

一、ART与Dalvik对比

ART是Android Runtime的缩写，它是Google用于替代饱受诟病的Dalvik虚拟机的替代品。ART究竟有什么神奇之处呢？根据相关资料，笔者总结其秘方如下：
•采用AOT（Ahead-Of-Time，预编译）编译技术，它能将Java字节码直接转换成目标机器的机器码。
•更为高效和细粒度的垃圾回收机制。

 

1.Dalvik:

一、Dalvik和标准Java虚拟机(JVM)首要差别：
Dalvik 基于寄存器，而 JVM 基于栈。
基于寄存器的虚拟机对于编译后变大的程序来说，在它们执行的时候，花费的时间更短。（Also of register-based VMs allow faster execution times at the expense of programs which are larger after compilation.）

二、Dalvik和Java运行环境的区别:
1：Dalvik主要是完成对象生命周期管理，堆栈管理，线程管理，安全和异常管理，以及垃圾回收等等重要功能。
2：Dalvik负责进程隔离和线程管理，每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例，其代码在虚拟机的解释下得以执行。
3：不同于Java虚拟机运行java字节码，Dalvik虚拟机运行的是其专有的文件格式Dex
4：所有的Android应用的线程都对应一个Linux线程，虚拟机因而可以更多的依赖操作系统的线程调度和管理机制
5：有一个特殊的虚拟机进程Zygote，他是虚拟机实例的孵化器。它在系统启动的时候就会产生，它会完成虚拟机的初始化，库的加载，预制类库和初始化的操作。如果系统需要一个新的虚拟机实例，它会迅速复制自身，以最快的数据提供给系统。对于一些只读的系统库，所有虚拟机实例都和Zygote共享一块内存区域。
6：当Android启动时，Dalvik VM 监视所有的程序（APK），并且创建依存关系树，为每个程序优化代码并存储在Dalvik缓存中。Dalvik第一次加载后会生成Cache文件，以提供下次快速加载，所以第一次会很慢。

 

2.Android runtime：

一、ART和Dalvik对比：
ART 的机制与 Dalvik 不同。在Dalvik下，应用每次运行的时候，字节码都需要通过即时编译器转换为机器码，这会拖慢应用的运行效率，而在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（AOT,Ahead-Of-Time）。这 样的话，应用的启动和执行都会变得更加快速。
新的运行环境ART能够使大多数应用的执行时间减半，另外，它将会显著提升电池的续航能力以及系统的性能。
预编译也会带来一些缺点。一方面，机器码占用的存储空间更大。字节码变为机器码之后，可能会增加 10%-20%。另一方面，应用的安装时间会变长。

 

3.Android ART运行时无缝替换Dalvik虚拟机的过程分析:

Dalvik虚拟机和ART虚拟机不同的地方就在于，Dalvik虚拟机执行的是dex字节码，ART虚拟机执行的是本地机器码。这意味着Dalvik虚拟机包含有一个解释器，用来执行dex字节码，Android从2.2开始，也包含有JIT（Just-In-Time），用来在运行时动态地将执行频率很高的dex字节码翻译成本地机器码，然后再执行。通过JIT，就可以有效地提高Dalvik虚拟机的执行效率。但是，将dex字节码翻译成本地机器码是发生在应用程序的运行过程中的，并且应用程序每一次重新运行的时候，都要做重做这个翻译工作的。因此，即使用采用了JIT，Dalvik虚拟机的总体性能还是不能与直接执行本地机器码的ART虚拟机相比。

那么，ART虚拟机执行的本地机器码是从哪里来的呢？Android的运行时从Dalvik虚拟机替换成ART虚拟机，并不要求开发者要将重新将自己的应用直接编译成目标机器码。也就是说，开发者开发出的应用程序经过编译和打包之后，仍然是一个包含dex字节码的APK文件。既然应用程序包含的仍然是dex字节码，而ART虚拟机需要的是本地机器码，这就必然要有一个翻译的过程。这个翻译的过程当然不能发生应用程序运行的时候，否则的话就和Dalvik虚拟机的JIT一样了。在计算机的世界里，与JIT相对的是AOT。AOT进Ahead-Of-Time的简称，它发生在程序运行之前。

没有ART虚拟机之前，应用在安装的过程，其实也会执行一次“翻译”的过程。只不过这个“翻译”的过程是将dex字节码进行优化，也就是由dex文件生成odex文件。这个过程由安装服务PackageManagerService请求守护进程installd来执行的。从这个角度来说，在应用安装的过程中将dex字节码翻译成本地机器码对原来的应用安装流程基本上就不会产生什么影响。

Android系统在启动的时候，会创建一个Zygote进程，充当应用程序进程孵化器。Zygote进程在启动的过程中，又会创建一个Dalvik虚拟机。Zygote进程是通过复制自己来创建新的应用程序进程的。这意味着Zygote进程会将自己的Dalvik虚拟机复制给应用程序进程。通过这种方式就可以大大地提高应用程序的启动速度，因为这种方式避免了每一个应用程序进程在启动的时候都要去创建一个Dalvik。事实上，Zygote进程通过自我复制的方式来创建应用程序进程，省去的不仅仅是应用程序进程创建Dalvik虚拟机的时间，还能省去应用程序进程加载各种系统库和系统资源的时间，因为它们在Zygote进程中已经加载过了，并且也会连同Dalvik虚拟机一起复制到应用程序进程中去。

通过上面的分析，我们就很容易知道，只需要将dex文件的优化过程替换成dex文件翻译成本地机器码的过程，就可以轻松地在应用安装过程，无缝地将Dalvik虚拟机替换成ART运行时。

 

二、AOT编译介绍

AOT编译技术的目的是将Java字节码直接转换成目标机器的机器码。对比Dalvik使用的JIT（Just-In-Time）编译技术：
-使用JIT时，Java程序在第一次执行某个函数时，需要先将其字节码转成机器码。
-使用AOT后，Java程序在安装前，其相关代码就会转成机器码。如此，在执行过程中，就不需要花费额外的时间来做字节码转换工作了。

除了提前转换字节码外，AOT还在以下方面做了优化工作：
-函数调用的去虚拟化（devirtualize method calls）。Java语言中，接口及虚函数可以很容易得解耦调用模块和实际的实现模块。但在具体执行的时候，虚拟机却要花费不少时间来查找真正的实现函数。函数调用的去虚拟化也是一种常见的优化方法，读者可参考[1],[2]来了解更多信息。
-快速接口调用。
-避免类初始化过程中的检查。
-消除异常检查。

 

三、ART垃圾回收机制介绍:
ART另一项值得称道的特性就是大幅改进了Java的垃圾回收机制。垃圾回收工作主要包括两个步骤：
•遍历应用程序的堆栈，枚举该应用所分配的所有对象，然后标记哪些对象还有效（这些有效的对象叫Reachable Objects）。
•释放不可到达对象所占据的空间。
那么ART是如何优化GC的呢？总体而言有下面几个方法：
•单独创建了一块名为“Large Object Space”（LOS）的空间用来保存较大尺寸的对象。
•创建了一种名叫Runs-of-Slots-Allocator（RosAlloc）的分配器。这种分配器的特点是分配内存时，会采用更细粒度的锁控制。例如有不同的锁来保护不同的对象分配，或者当线程分配一些小尺寸对象时使用线程自己的堆栈，从而可完全不使用锁保护。据Google自己的数据，RosAlloc能达到最多10倍的速度提升，效果可谓惊人。
•另外，为了防止内存的碎片化，ART还引入了一个名为“Moving garbage collector”的方法，其目的是清理堆栈以减少内存碎片。由于这个工作会导致应用程序长时间中断，所以它必须等程序退到后台时才能开展。

 

四、JobScheduler介绍:
CPU运行是一阵一阵的，每次运行都很短。这是什么原因呢？举个例子：
很多应用程序都会设置一个定时器，一旦时间到达，设备就会被唤醒，这些应用也能被触发以执行相关的操作。可是这些操作还依赖其他外界条件，例如必须连着Wi-Fi，或者连着移动网络。
由于这些外界条件不能满足，应用虽然被唤醒，但依然不能完成相关操作，所以它又回到休眠状态。

如此反复，就出现了图12中红框所示的情况。对于这种情况，应用程序本身即使非常在意功耗，它也没有办法避免。所以，Project Volta提供了一个名为JobScheduler的机制及对应的API以帮助开发者解决这个问题。

简单点说，JobScheduler其实是一个系统级的任务管理中心（对应的服务名叫“taskmanager”），应用程序通过JobScheduler API向这个管理中心池添加任务。最为关键的是，应用程序还需要设置这些任务被触发的条件，比如：
-设备是否有合适的网络链接，如Wi-Fi或移动网络链接等。
-设备是否空闲。
-设备是否处于充电状态。
-所链接的网络是否收费等。

显然，有了JobScheduler，只有那些所有条件都满足的任务才能真正被触发执行，这样就能有效避免应用程序被定时器唤醒但由于其他条件不满足又不能真正工作的情况。