Android运行时ART加载OAT文件的过程分析

发表于 | 分类于

​ OAT文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。这使得我们无需重新编译原有的APK就可以让它正常地在ART里面运行，也就是我们不需要改变原来的APK编程接口。本文我们通过OAT文件的加载过程分析OAT文件的结构，为后面分析ART的工作原理打基础。

OAT文件的结构如图1所示：

img

​ 由于OAT文件本质上是一个ELF文件，因此在最外层它具有一般ELF文件的结构，例如它有标准的ELF文件头以及通过段（Section）来描述文件内容。

作为Android私有的一种ELF文件，OAT文件包含有两个特殊的段oatdata和oatexec，前者包含有用来生成本地机器指令的dex文件内容，后者包含有生成的本地机器指令，它们之间的关系通过储存在oatdata段前面的oat头部描述。此外，在OAT文件的dynamic段，导出了三个符号oatdata、oatexec和oatlastword，它们的值就是用来界定oatdata段和oatexec段的起止位置的。其中，[oatdata, oatexec - 1]描述的是oatdata段的起止位置，而[oatexec, oatlastword + 3]描述的是oatexec的起止位置。

在分析OAT文件的加载过程之前，我们需要简单介绍一下OAT是如何产生的。如前面Android ART运行时无缝替换Dalvik虚拟机的过程分析一文所示，APK在安装的过程中，会通过dex2oat工具生成一个OAT文件：

这个函数定义在文件frameworks/native/cmds/installd/commands.c中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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));  
}

APK安装过程中生成的OAT文件的输入只有一个DEX文件，也就是来自于打包在要安装的APK文件里面的classes.dex文件。实际上，一个OAT文件是可以由若干个DEX生成的。这意味着在生成的OAT文件的oatdata段中，包含有多个DEX文件。那么，在什么情况下，会生成包含多个DEX文件的OAT文件呢？

从前面Android ART运行时无缝替换Dalvik虚拟机的过程分析一文可以知道，当我们选择了ART运行时时，Zygote进程在启动的过程中，会调用libart.so里面的函数JNI_CreateJavaVM来创建一个ART虚拟机。函数JNI_CreateJavaVM的实现如下所示：

这个函数定义在文件art/runtime/jni_internal.cc中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
extern "C" jint JNI_CreateJavaVM(JavaVM** p_vm, JNIEnv** p_env, void* vm_args) {
  const JavaVMInitArgs* args = static_cast<JavaVMInitArgs*>(vm_args);
  if (IsBadJniVersion(args->version)) {
    LOG(ERROR) << "Bad JNI version passed to CreateJavaVM: " << args->version;
    return JNI_EVERSION;
  }
  Runtime::Options options;
  for (int i = 0; i < args->nOptions; ++i) {
    JavaVMOption* option = &args->options[i];
    options.push_back(std::make_pair(std::string(option->optionString), option->extraInfo));
  }
  bool ignore_unrecognized = args->ignoreUnrecognized;
  if (!Runtime::Create(options, ignore_unrecognized)) {
    return JNI_ERR;
  }
  Runtime* runtime = Runtime::Current();
  bool started = runtime->Start();
  if (!started) {
    delete Thread::Current()->GetJniEnv();
    delete runtime->GetJavaVM();
    LOG(WARNING) << "CreateJavaVM failed";
    return JNI_ERR;
  }
  *p_env = Thread::Current()->GetJniEnv();
  *p_vm = runtime->GetJavaVM();
  return JNI_OK;
}

20140924020914024

​ 首先是根据类签名信息从包含在OAT文件里面的DEX文件中查找目标Class的编号，然后再根据这个编号找到在OAT文件中找到对应的OatClass。接下来再根据方法签名从包含在OAT文件里面的DEX文件中查找目标方法的编号，然后再根据这个编号在前面找到的OatClass中找到对应的OatMethod。有了这个OatMethod之后，我们就根据它的成员变量begin_和code_offset_找到目标类方法的本地机器指令了。其中，从DEX文件中根据签名找到类和方法的编号要求对DEX文件进行解析，这就需要利用Dalvik虚拟机的知识了。

看不懂，先不看了。。。

原文：https://blog.csdn.net/Luoshengyang/article/details/39307813