ART概述重点.pptx

ART概述;Java虚拟机、Dalvik虚拟机和ART运行时的关系;三个用来抽象Java虚拟机的接口;在Android系统中，Davik虚拟机实现在libdibdvm.sovm.so中，ART虚拟机实现在libart.so中。也就是说，libdibdvm.sovm.so和libart.so导出了JNI_GetDefaultJavaVMInitArgs、JNI_CreateJavaVM和JNI_GetCreatedJavaVMs这三个接口，供外界调用。此外，Android系统还提供了一个系统属性persist.sys.dalvik.vm.lib，它的值要么等于libdvm.so，要么等于libart.so。当等于libdvm.so时，就表示当前用的是Dalvik虚拟机，而当等于libart.so时，就表示当前用的是ART虚拟机。;以上描述的Dalvik虚拟机和ART虚拟机的共同之处，当然它们之间最显著还是不同之处。不同的地方就在于，Dalvik虚拟机执行的是dex字节码，ART虚拟机执行的是本地机器码。这意味着Dalvik虚拟机包含有一个解释器，用来执行dex字节码。当然，Android从2.2开始，也包含有JIT（Just-In-Time），用来在运行时动态地将执行频率很高的dex字节码翻译成本地机器码，然后再执行。通过JIT，就可以有效地提高Dalvik虚拟机的执行效率。但是，将dex字节码翻译成本地机器码是发生在应用程序的运行过程中的，并且应用程序每一次重新运行的时候，都要做重做这个翻译工作的。因此，即使用采用了JIT，Dalvik虚拟机的总体性能还是不能与直接执行本地机器码的ART虚拟机相比。;Android的运行时从Dalvik虚拟机替换成ART虚拟机，并不要求开发者要将重新将自己的应用直接编译成目标机器码。也就是说，开发者开发出的应用程序经过编译和打包之后，仍然是一个包含dex字节码的APK文件。既然应用程序包含的仍然是dex字节码，而ART虚拟机需要的是本地机器码，这就必然要有一个翻译的过程。这个翻译的过程当然不能发生应用程序运行的时候，否则的话就和Dalvik虚拟机的JIT一样了。在计算机的世界里，与JIT相对的是AOT。AOT进Ahead-Of-Time的简称，它发生在程序运行之前。我们用静态语言（例如C/C++）来开发应用程序的时候，编译器直接就把它们翻译成目标机器码。这种静态语言的编译方式也是AOT的一种。但是前面我们提到，ART虚拟机并不要求开发者将自己的应用直接编译成目标机器码。这样，将应用的dex字节码翻译成本地机器码的最恰当AOT时机就发生在应用安装的时候。;如果你是先安装应用软件再将虚拟机转换到ART模式（手机需重启），重启后系统会自动将之前在Dalvik模式下安装的应用软件预编译一下。如果你是先转换到ART模式再安装应用软件，那么在安装的过程中，系统就会对软件进行预编译，所以你会觉得在ART模式下安装应用所花费的时间比在Dalvik模式下长一些，原因就是因为在安装过程中系统会对应用进行预编译。所以时间长，所占用的空间也要大一些。综上所述，你所问的两种情况不会有区别。但是，不排除个别厂商的系统在切换到ART模式后不对原先安装的应用进行预编译。;ART虚拟机是如何做到无缝替换Dalvik虚拟机的两个关键点;即然应用程序进程里面的Dalvik虚拟机都是从Zygote进程中复制过来的，那么接下来我们就继续Zygote进程是如何创建Dalvik虚拟机的。我们可以知道，Zygote进程中的Dalvik虚拟机是从AndroidRuntime::start这个函数开始创建的。因此，接下来我们就看看这个函数的实现： AndroidRuntime类的成员函数start最主要是做了以下三件事情： 1. 创建一个JniInvocation实例，并且调用它的成员函数init来初始化JNI环境； 2. 调用AndroidRuntime类的成员函数startVm来创建一个虚拟机及其对应的JNI接口，即创建一个JavaVM接口和一个JNIEnv接口； 3. 有了上述的JavaVM接口和JNIEnv接口之后，就可以在Zygote进程中加载指定的class了 ;JniInvocation类的成员函数init所做的事情很简单。它首先是读取系统属性persist.sys.dalvik.vm.lib的值。前面提到，系统属性persist.sys.dalvik.vm.lib的值要么等于libdvm.so，要么等于libart.so。因此，接下来通过函数dlopen加载到进程来的要么是libdvm.so，要么是libart.so。无论加载的是哪一个so，都要求它导出JNI_GetDefaultJavaVMInitArgs、JNI_