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 。

Android ART運行時無縫替換Dalvik虛擬機的過程分析