Android 4.4發(fā)布了一個ART運行時，準備用來替換掉之前一直使用的Dalvik虛擬機，希望籍此解決飽受詬病的性能問題。老羅不打算分析ART的實現(xiàn)原理，只是很有興趣知道ART是如何無縫替換掉原來的Dalvik虛擬機的。畢竟在原來的系統(tǒng)中，大量的代碼都是運行在Dalvik虛擬機里面的。開始覺得這個替換工作是挺復雜的，但是分析了相關代碼之后，發(fā)現(xiàn)思路是很清晰的。本文就詳細分析這個無縫的替換過程。
老羅的新浪微博：
http://weibo.com/shengyangluo
，歡迎關注！
我們知道，Dalvik虛擬機實則也算是一個Java虛擬機，只不過它執(zhí)行的不是class文件，而是dex文件。因此，ART運行時最理想的方式也是實現(xiàn)為一個Java虛擬機的形式，這樣就可以很容易地將Dalvik虛擬機替換掉。注意，我們這里說實現(xiàn)為Java虛擬機的形式，實際上是指提供一套完全與Java虛擬機兼容的接口。例如，Dalvik虛擬機在接口上與Java虛擬機是一致的，但是它的內(nèi)部可以是完全不一樣的東西。
實際上，ART運行時就是真的和Dalvik虛擬機一樣，實現(xiàn)了一套完全兼容Java虛擬機的接口。為了方便描述，接下來我們就將ART運行時稱為ART虛擬機，它和Dalvik虛擬機、Java虛擬機的關系如圖1所示：
圖1 Java虛擬機、Dalvik虛擬機和ART運行時的關系
從圖1可以知道，Dalvik虛擬機和ART虛擬機都實現(xiàn)了三個用來抽象Java虛擬機的接口：
1. JNI_GetDefaultJavaVMInitArgs -- 獲取虛擬機的默認初始化參數(shù)
2. JNI_CreateJavaVM -- 在進程中創(chuàng)建虛擬機實例
3. JNI_GetCreatedJavaVMs -- 獲取進程中創(chuàng)建的虛擬機實例
在Android系統(tǒng)中，Davik虛擬機實現(xiàn)在libdvm.so中，ART虛擬機實現(xiàn)在libart.so中。也就是說，libdvm.so和libart.so導出了JNI_GetDefaultJavaVMInitArgs、JNI_CreateJavaVM和JNI_GetCreatedJavaVMs這三個接口，供外界調(diào)用。
此外，Android系統(tǒng)還提供了一個系統(tǒng)屬性persist.sys.dalvik.vm.lib，它的值要么等于libdvm.so，要么等于libart.so。當?shù)扔趌ibdvm.so時，就表示當前用的是Dalvik虛擬機，而當?shù)扔趌ibart.so時，就表示當前用的是ART虛擬機。
以上描述的Dalvik虛擬機和ART虛擬機的共同之處，當然它們之間最顯著還是不同之處。不同的地方就在于，Dalvik虛擬機執(zhí)行的是dex字節(jié)碼，ART虛擬機執(zhí)行的是本地機器碼。這意味著Dalvik虛擬機包含有一個解釋器，用來執(zhí)行dex字節(jié)碼，具體可以參考 Dalvik虛擬機簡要介紹和學習計劃 這個系列的文章。當然，Android從2.2開始，也包含有JIT（Just-In-Time），用來在運行時動態(tài)地將執(zhí)行頻率很高的dex字節(jié)碼翻譯成本地機器碼，然后再執(zhí)行。通過JIT，就可以有效地提高Dalvik虛擬機的執(zhí)行效率。但是，將dex字節(jié)碼翻譯成本地機器碼是發(fā)生在應用程序的運行過程中的，并且應用程序每一次重新運行的時候，都要做重做這個翻譯工作的。因此，即使用采用了JIT，Dalvik虛擬機的總體性能還是不能與直接執(zhí)行本地機器碼的ART虛擬機相比。
那么，ART虛擬機執(zhí)行的本地機器碼是從哪里來的呢？Android的運行時從Dalvik虛擬機替換成ART虛擬機，并不要求開發(fā)者要將重新將自己的應用直接編譯成目標機器碼。也就是說，開發(fā)者開發(fā)出的應用程序經(jīng)過編譯和打包之后，仍然是一個包含dex字節(jié)碼的APK文件。既然應用程序包含的仍然是dex字節(jié)碼，而ART虛擬機需要的是本地機器碼，這就必然要有一個翻譯的過程。這個翻譯的過程當然不能發(fā)生應用程序運行的時候，否則的話就和Dalvik虛擬機的JIT一樣了。在計算機的世界里，與JIT相對的是AOT。AOT進Ahead-Of-Time的簡稱，它發(fā)生在程序運行之前。我們用靜態(tài)語言（例如C/C++）來開發(fā)應用程序的時候，編譯器直接就把它們翻譯成目標機器碼。這種靜態(tài)語言的編譯方式也是AOT的一種。但是前面我們提到，ART虛擬機并不要求開發(fā)者將自己的應用直接編譯成目標機器碼。這樣，將應用的dex字節(jié)碼翻譯成本地機器碼的最恰當AOT時機就發(fā)生在應用安裝的時候。
我們知道，沒有ART虛擬機之前，應用在安裝的過程，其實也會執(zhí)行一次“翻譯”的過程。只不過這個“翻譯”的過程是將dex字節(jié)碼進行優(yōu)化，也就是由dex文件生成odex文件。這個過程由安裝服務PackageManagerService請求守護進程installd來執(zhí)行的。從這個角度來說，在應用安裝的過程中將dex字節(jié)碼翻譯成本地機器碼對原來的應用安裝流程基本上就不會產(chǎn)生什么影響。
有了以上的背景知識之后，我們接下來就從兩個角度來了解ART虛擬機是如何做到無縫替換Dalvik虛擬機的：
1. ART虛擬機的啟動過程；
2. Dex字節(jié)碼翻譯成本地機器碼的過程。
我們知道，Android系統(tǒng)在啟動的時候，會創(chuàng)建一個Zygote進程，充當應用程序進程孵化器。Zygote進程在啟動的過程中，又會創(chuàng)建一個Dalvik虛擬機。Zygote進程是通過復制自己來創(chuàng)建新的應用程序進程的。這意味著Zygote進程會將自己的Dalvik虛擬機復制給應用程序進程。通過這種方式就可以大大地提高應用程序的啟動速度，因為這種方式避免了每一個應用程序進程在啟動的時候都要去創(chuàng)建一個Dalvik。事實上，Zygote進程通過自我復制的方式來創(chuàng)建應用程序進程，省去的不僅僅是應用程序進程創(chuàng)建Dalvik虛擬機的時間，還能省去應用程序進程加載各種系統(tǒng)庫和系統(tǒng)資源的時間，因為它們在Zygote進程中已經(jīng)加載過了，并且也會連同Dalvik虛擬機一起復制到應用程序進程中去。關于Zygote進程和應用程序進程啟動的更多知識，可以參考 Android系統(tǒng)進程Zygote啟動過程的源代碼分析 和 Android應用程序進程啟動過程的源代碼分析 這兩篇文章。
即然應用程序進程里面的Dalvik虛擬機都是從Zygote進程中復制過來的，那么接下來我們就繼續(xù)Zygote進程是如何創(chuàng)建Dalvik虛擬機的。從 Dalvik虛擬機的啟動過程分析 這篇文章可以知道，Zygote進程中的Dalvik虛擬機是從AndroidRutime::start這個函數(shù)開始創(chuàng)建的。因此，接下來我們就看看這個函數(shù)的實現(xiàn)：
void AndroidRuntime::start(const char* className, const char* options)
{
......
/* start the virtual machine */
JniInvocation jni_invocation;
jni_invocation.Init(NULL);
JNIEnv* env;
if (startVm(&mJavaVM, &env) != 0) {
return;
}
......
/*
* Start VM. This thread becomes the main thread of the VM, and will
* not return until the VM exits.
*/
char* slashClassName = toSlashClassName(className);
jclass startClass = env->FindClass(slashClassName);
if (startClass == NULL) {
ALOGE("JavaVM unable to locate class '%s'\n", slashClassName);
/* keep going */
} else {
jmethodID startMeth = env->GetStaticMethodID(startClass, "main",
"([Ljava/lang/String;)V");
if (startMeth == NULL) {
ALOGE("JavaVM unable to find main() in '%s'\n", className);
/* keep going */
} else {
env->CallStaticVoidMethod(startClass, startMeth, strArray);
#if 0
if (env->ExceptionCheck())
threadExitUncaughtException(env);
#endif
}
}
......
}
這個函數(shù)定義在文件frameworks/base/core/jni/AndroidRuntime.cpp中。
AndroidRutime類的成員函數(shù)start最主要是做了以下三件事情：
1. 創(chuàng)建一個JniInvocation實例，并且調(diào)用它的成員函數(shù)init來初始化JNI環(huán)境；
2. 調(diào)用AndroidRutime類的成員函數(shù)startVm來創(chuàng)建一個虛擬機及其對應的JNI接口，即創(chuàng)建一個JavaVM接口和一個JNIEnv接口；
3. 有了上述的JavaVM接口和JNIEnv接口之后，就可以在Zygote進程中加載指定的class了。
其中，第1件事情和第2件事情又是最關鍵的。因此，接下來我們繼續(xù)分析它們所對應的函數(shù)的實現(xiàn)。
JniInvocation類的成員函數(shù)init的實現(xiàn)如下所示：
#ifdef HAVE_ANDROID_OS
static const char* kLibrarySystemProperty = "persist.sys.dalvik.vm.lib";
#endif
static const char* kLibraryFallback = "libdvm.so";
bool JniInvocation::Init(const char* library) {
#ifdef HAVE_ANDROID_OS
char default_library[PROPERTY_VALUE_MAX];
property_get(kLibrarySystemProperty, default_library, kLibraryFallback);
#else
const char* default_library = kLibraryFallback;
#endif
if (library == NULL) {
library = default_library;
}
handle_ = dlopen(library, RTLD_NOW);
if (handle_ == NULL) {
if (strcmp(library, kLibraryFallback) == 0) {
// Nothing else to try.
ALOGE("Failed to dlopen %s: %s", library, dlerror());
return false;
}
// Note that this is enough to get something like the zygote
// running, we can't property_set here to fix this for the future
// because we are root and not the system user. See
// RuntimeInit.commonInit for where we fix up the property to
// avoid future fallbacks. http://b/11463182
ALOGW("Falling back from %s to %s after dlopen error: %s",
library, kLibraryFallback, dlerror());
library = kLibraryFallback;
handle_ = dlopen(library, RTLD_NOW);
if (handle_ == NULL) {
ALOGE("Failed to dlopen %s: %s", library, dlerror());
return false;
}
}
if (!FindSymbol(reinterpret_cast<void**>(&JNI_GetDefaultJavaVMInitArgs_),
"JNI_GetDefaultJavaVMInitArgs")) {
return false;
}
if (!FindSymbol(reinterpret_cast<void**>(&JNI_CreateJavaVM_),
"JNI_CreateJavaVM")) {
return false;
}
if (!FindSymbol(reinterpret_cast<void**>(&JNI_GetCreatedJavaVMs_),
"JNI_GetCreatedJavaVMs")) {
return false;
}
return true;
}
這個函數(shù)定義在文件libnativehelper/JniInvocation.cpp中。
JniInvocation類的成員函數(shù)init所做的事情很簡單。它首先是讀取系統(tǒng)屬性persist.sys.dalvik.vm.lib的值。前面提到，系統(tǒng)屬性persist.sys.dalvik.vm.lib的值要么等于libdvm.so，要么等于libart.so。因此，接下來通過函數(shù)dlopen加載到進程來的要么是libdvm.so，要么是libart.so。無論加載的是哪一個so，都要求它導出JNI_GetDefaultJavaVMInitArgs、JNI_CreateJavaVM和JNI_GetCreatedJavaVMs這三個接口，并且分別保存在JniInvocation類的三個成員變量JNI_GetDefaultJavaVMInitArgs_、JNI_CreateJavaVM_和JNI_GetCreatedJavaVMs_中。這三個接口也就是前面我們提到的用來抽象Java虛擬機的三個接口。
從這里就可以看出，JniInvocation類的成員函數(shù)init實際上就是根據(jù)系統(tǒng)屬性persist.sys.dalvik.vm.lib來初始化Dalvik虛擬機或者ART虛擬機環(huán)境。
接下來我們繼續(xù)看AndroidRutime類的成員函數(shù)startVm的實現(xiàn)：
int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** pEnv)
{
......
/*
* Initialize the VM.
*
* The JavaVM* is essentially per-process, and the JNIEnv* is per-thread.
* If this call succeeds, the VM is ready, and we can start issuing
* JNI calls.
*/
if (JNI_CreateJavaVM(pJavaVM, pEnv, &initArgs) < 0) {
ALOGE("JNI_CreateJavaVM failed\n");
goto bail;
}
......
}
這個函數(shù)定義在文件frameworks/base/core/jni/AndroidRuntime.cpp中。
AndroidRutime類的成員函數(shù)startVm最主要就是調(diào)用函數(shù)JNI_CreateJavaVM來創(chuàng)建一個JavaVM接口及其對應的JNIEnv接口：
extern "C" jint JNI_CreateJavaVM(JavaVM** p_vm, JNIEnv** p_env, void* vm_args) {
return JniInvocation::GetJniInvocation().JNI_CreateJavaVM(p_vm, p_env, vm_args);
}
這個函數(shù)定義在文件libnativehelper/JniInvocation.cpp中。
JniInvocation類的靜態(tài)成員函數(shù)GetJniInvocation返回的便是前面所創(chuàng)建的JniInvocation實例。有了這個JniInvocation實例之后，就繼續(xù)調(diào)用它的成員函數(shù)JNI_CreateJavaVM來創(chuàng)建一個JavaVM接口及其對應的JNIEnv接口：
jint JniInvocation::JNI_CreateJavaVM(JavaVM** p_vm, JNIEnv** p_env, void* vm_args) {
return JNI_CreateJavaVM_(p_vm, p_env, vm_args);
}
這個函數(shù)定義在文件libnativehelper/JniInvocation.cpp中。
JniInvocation類的成員變量JNI_CreateJavaVM_指向的就是前面所加載的libdvm.so或者libart.so所導出的函數(shù)JNI_CreateJavaVM，因此，JniInvocation類的成員函數(shù)JNI_CreateJavaVM返回的JavaVM接口指向的要么是Dalvik虛擬機，要么是ART虛擬機。
通過上面的分析，我們就很容易知道，Android系統(tǒng)通過將ART運行時抽象成一個Java虛擬機，以及通過系統(tǒng)屬性persist.sys.dalvik.vm.lib和一個適配層JniInvocation，就可以無縫地將Dalvik虛擬機替換為ART運行時。這個替換過程設計非常巧妙，因為涉及到的代碼修改是非常少的。
以上就是ART虛擬機的啟動過程，接下來我們再分析應用程序在安裝過程中將dex字節(jié)碼翻譯為本地機器碼的過程。
Android應用程序的安裝過程可以參考 Android應用程序安裝過程源代碼分析 這篇文章。簡單來說，就是Android系統(tǒng)通過PackageManagerService來安裝APK，在安裝的過程，PackageManagerService會通過另外一個類Instalerl的成員函數(shù)dexopt來對APK里面的dex字節(jié)碼進行優(yōu)化：
public final class Installer {
......
public int dexopt(String apkPath, int uid, boolean isPublic) {
StringBuilder builder = new StringBuilder("dexopt");
builder.append(' ');
builder.append(apkPath);
builder.append(' ');
builder.append(uid);
builder.append(isPublic ? " 1" : " 0");
return execute(builder.toString());
}
......
}
這個函數(shù)定義在文件frameworks/base/services/java/com/android/server/pm/Installer.java中。
Installer通過socket向守護進程installd發(fā)送一個dexopt請求，這個請求是由installd里面的函數(shù)dexopt來處理的：
int dexopt(const char *apk_path, uid_t uid, int is_public)
{
struct utimbuf ut;
struct stat apk_stat, dex_stat;
char out_path[PKG_PATH_MAX];
char dexopt_flags[PROPERTY_VALUE_MAX];
char persist_sys_dalvik_vm_lib[PROPERTY_VALUE_MAX];
char *end;
int res, zip_fd=-1, out_fd=-1;
......
/* The command to run depend ones the value of persist.sys.dalvik.vm.lib */
property_get("persist.sys.dalvik.vm.lib", persist_sys_dalvik_vm_lib, "libdvm.so");
/* Before anything else: is there a .odex file? If so, we have
* precompiled the apk and there is nothing to do here.
*/
sprintf(out_path, "%s%s", apk_path, ".odex");
if (stat(out_path, &dex_stat) == 0) {
return 0;
}
if (create_cache_path(out_path, apk_path)) {
return -1;
}
......
out_fd = open(out_path, O_RDWR | O_CREAT | O_EXCL, 0644);
......
pid_t pid;
pid = fork();
if (pid == 0) {
......
if (strncmp(persist_sys_dalvik_vm_lib, "libdvm", 6) == 0) {
run_dexopt(zip_fd, out_fd, apk_path, out_path, dexopt_flags);
} else if (strncmp(persist_sys_dalvik_vm_lib, "libart", 6) == 0) {
run_dex2oat(zip_fd, out_fd, apk_path, out_path, dexopt_flags);
} else {
exit(69); /* Unexpected persist.sys.dalvik.vm.lib value */
}
exit(68); /* only get here on exec failure */
}
......
}
這個函數(shù)定義在文件frameworks/native/cmds/installd/commands.c中。
函數(shù)dexopt首先是讀取系統(tǒng)屬性persist.sys.dalvik.vm.lib的值，接著在/data/dalvik-cache目錄中創(chuàng)建一個odex文件。這個odex文件就是作為dex文件優(yōu)化后的輸出文件。再接下來，函數(shù)dexopt通過fork來創(chuàng)建一個子進程。如果系統(tǒng)屬性persist.sys.dalvik.vm.lib的值等于libdvm.so，那么該子進程就會調(diào)用函數(shù)run_dexopt來將dex文件優(yōu)化成odex文件。另一方面，如果系統(tǒng)屬性persist.sys.dalvik.vm.lib的值等于libart.so，那么該子進程就會調(diào)用函數(shù)run_dex2oat來將dex文件優(yōu)化成oart文件，實際上就是將dex字節(jié)碼翻譯成本地機器碼，并且保存在一個oat文件中。
函數(shù)run_dexopt和run_dex2oat的實現(xiàn)如下所示：
static void run_dexopt(int zip_fd, int odex_fd, const char* input_file_name,
const char* output_file_name, const char* dexopt_flags)
{
static const char* DEX_OPT_BIN = "/system/bin/dexopt";
static const int MAX_INT_LEN = 12; // '-'+10dig+'\0' -OR- 0x+8dig
char zip_num[MAX_INT_LEN];
char odex_num[MAX_INT_LEN];
sprintf(zip_num, "%d", zip_fd);
sprintf(odex_num, "%d", odex_fd);
ALOGV("Running %s in=%s out=%s\n", DEX_OPT_BIN, input_file_name, output_file_name);
execl(DEX_OPT_BIN, DEX_OPT_BIN, "--zip", zip_num, odex_num, input_file_name,
dexopt_flags, (char*) NULL);
ALOGE("execl(%s) failed: %s\n", DEX_OPT_BIN, strerror(errno));
}
static void run_dex2oat(int zip_fd, int oat_fd, const char* input_file_name,
const char* output_file_name, const char* dexopt_flags)
{
static const char* DEX2OAT_BIN = "/system/bin/dex2oat";
static const int MAX_INT_LEN = 12; // '-'+10dig+'\0' -OR- 0x+8dig
char zip_fd_arg[strlen("--zip-fd=") + MAX_INT_LEN];
char zip_location_arg[strlen("--zip-location=") + PKG_PATH_MAX];
char oat_fd_arg[strlen("--oat-fd=") + MAX_INT_LEN];
char oat_location_arg[strlen("--oat-name=") + PKG_PATH_MAX];
sprintf(zip_fd_arg, "--zip-fd=%d", zip_fd);
sprintf(zip_location_arg, "--zip-location=%s", input_file_name);
sprintf(oat_fd_arg, "--oat-fd=%d", oat_fd);
sprintf(oat_location_arg, "--oat-location=%s", output_file_name);
ALOGV("Running %s in=%s out=%s\n", DEX2OAT_BIN, input_file_name, output_file_name);
execl(DEX2OAT_BIN, DEX2OAT_BIN,
zip_fd_arg, zip_location_arg,
oat_fd_arg, oat_location_arg,
(char*) NULL);
ALOGE("execl(%s) failed: %s\n", DEX2OAT_BIN, strerror(errno));
}
這兩個函數(shù)定義在文件frameworks/native/cmds/installd/commands.c中。
這從里就可以看出，函數(shù)run_dexopt通過調(diào)用/system/bin/dexopt來對dex字節(jié)碼進行優(yōu)化，而函數(shù)run_dex2oat通過調(diào)用/system/bin/dex2oat來將dex字節(jié)碼翻譯成本地機器碼。注意，無論是對dex字節(jié)碼進行優(yōu)化，還是將dex字節(jié)碼翻譯成本地機器碼，最終得到的結果都是保存在相同名稱的一個odex文件里面的，但是前者對應的是一個dexy文件（表示這是一個優(yōu)化過的dex），后者對應的是一個oat文件（實際上是一個自定義的elf文件，里面包含的都是本地機器指令）。通過這種方式，原來任何通過絕對路徑引用了該odex文件的代碼就都不需要修改了。
通過上面的分析，我們就很容易知道，只需要將dex文件的優(yōu)化過程替換成dex文件翻譯成本地機器碼的過程，就可以輕松地在應用安裝過程，無縫地將Dalvik虛擬機替換成ART運行時。
最后，還有一個地方需要注意的是，應用程序的安裝發(fā)生在兩個時機，第一個時機是系統(tǒng)啟動的時候，第二個時機系統(tǒng)啟動完成后用戶自行安裝的時候。在第一個時機中，系統(tǒng)除了會對/system/app和/data/app目錄下的所有APK進行dex字節(jié)碼到本地機器碼的翻譯之外，還會對/system/framework目錄下的APK或者JAR文件，以及這些APK所引用的外部JAR，進行dex字節(jié)碼到本地機器碼的翻譯。這樣就可以保證除了應用之外，系統(tǒng)中使用Java來開發(fā)的系統(tǒng)服務，也會統(tǒng)一地從dex字節(jié)碼翻譯成本地機器碼。也就是說，將Android系統(tǒng)中的Dalvik虛擬機替換成ART運行時之后，系統(tǒng)中的代碼都是由ART運行時來執(zhí)行的了，這時候就不會對Dalvik虛擬機產(chǎn)生任何的依賴。
至此，我們就分析完成ART運行時無縫替換Dalvik虛擬機的過程了，更多的干貨分享衣關注老羅的新浪微博： http://weibo.com/shengyangluo 。
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
