ART运行时详析：OAT文件加载过程与结构剖析

118 浏览量更新于2024-07-15 收藏 805KB PDF 举报

本文主要深入探讨了Android运行时 ART ( Ahead-of-Time Compiler, 预编译器) 加载 OAT (Optimized Ahead-of-Time Artifacts, 优化预编译对象) 文件的过程。ART是Android 5.0 (Lollipop)及更高版本引入的一种新型执行环境，其核心在于将DEX (Dalvik Executable, Dalvik可执行文件) 转换为本地机器指令的OAT文件，从而实现无需重新编译APK就能在ART中高效运行。首先，OAT文件是Android私有的ELF (Executable and Linkable Format, 可执行与链接格式) 文件，具有标准的ELF文件头和多个段，如代码段(oatexec)和数据段(oatdata)。oatdata存储原始DEX文件转换后的本地机器指令，而oatexec则包含这些指令。OAT文件结构中的动态段包含符号表，用于指示各个段的起始和结束位置，便于系统找到所需数据和指令。在OAT生成过程中，APK通过dex2oat工具将DEX文件编译为OAT，这个工具接收ZIP文件描述符、OAT文件描述符、输入和输出文件名以及优化标志作为参数。dex2oat的运行表明OAT文件的生成是一个关键步骤，它确保了ART能够直接处理优化后的本地代码，提高了应用性能。理解OAT文件加载过程至关重要，因为它是ART运行APK的核心环节。OAT加载涉及解析ELF头、定位和加载oatdata和oatexec段，以及执行符号表查找。这部分内容不仅涉及内存管理和寻址，还牵涉到 ART 的缓存策略，比如热点代码的即时编译和缓存。本文接下来将详述OAT文件加载的具体步骤，包括但不限于头部解析、段加载和执行环境的初始化，以及如何根据oat头部信息确定指令执行的入口点。同时，为了全面理解ART的工作原理，读者还需理解类和方法查找过程，这部分内容将在后续章节中展开。 OAT文件是Android ART运行时的关键组成部分，其加载过程对理解ART性能优化和应用程序执行效率提升具有重要意义。通过深入分析OAT的结构和加载流程，我们可以更好地掌握ART技术，为优化Android应用性能提供理论依据。

2. 检查文件/data/dalvik-cache/system@framework@boot.art@classes.dex是否存在。如果存在，那么就以它为参

数，创建一个Image空间。否则的话，执行下一步。

3. 调用ImageSpace类的静态成员函数GenerateImage在/data/dalvik-cache目录下生成一个

system@framework@boot.art@classes.dex，然后再以该文件为参数，创建一个Image空间。

接下来我们再来看看ImageSpace类的静态成员函数GenerateImage的实现，如下所示：

static bool GenerateImage(const std::string& image_file_name) {

const std::string boot_class_path_string(Runtime::Current()->GetBootClassPathString());

std::vector<:string> boot_class_path;

Split(boot_class_path_string, ':', boot_class_path);

......

std::vector<:string> arg_vector;

std::string dex2oat(GetAndroidRoot());

dex2oat += (kIsDebugBuild ? "/bin/dex2oatd" : "/bin/dex2oat");

arg_vector.push_back(dex2oat);

std::string image_option_string("--image=");

image_option_string += image_file_name;

arg_vector.push_back(image_option_string);

......

for (size_t i = 0; i < boot_class_path.size(); i++) {

arg_vector.push_back(std::string("--dex-file=") + boot_class_path[i]);

}

std::string oat_file_option_string("--oat-file=");

oat_file_option_string += image_file_name;

oat_file_option_string.erase(oat_file_option_string.size() - 3);

oat_file_option_string += "oat";

arg_vector.push_back(oat_file_option_string);

......

if (kIsTargetBuild) {

arg_vector.push_back("--image-classes-zip=/system/framework/framework.jar");

arg_vector.push_back("--image-classes=preloaded-classes");

}

......

// Convert the args to char pointers.

std::vector<char*> char_args;

for (std::vector<std::string>::iterator it = arg_vector.begin(); it != arg_vector.end();

++it) {

char_args.push_back(const_cast<char*>(it->c_str()));

}

char_args.push_back(NULL);

// fork and exec dex2oat

pid_t pid = fork();

if (pid == 0) {

......

execv(dex2oat.c_str(), &char_args[0]);

......

return false;

} else {

......

// wait for dex2oat to finish

int status;

pid_t got_pid = TEMP_FAILURE_RETRY(waitpid(pid, &status, 0));

.......

}

return true;

}

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

ImageSpace类的静态成员函数GenerateImage实际上就调用dex2oat工具在/data/dalvik-cache目录下生成两个文件：

system@framework@boot.art@classes.dex和system@framework@boot.art@classes.oat。

system@framework@boot.art@classes.dex是一个Image文件，通过–image选项传递给dex2oat工具，里面包含了一

些需要在Zygote进程启动时预加载的类。这些需要预加载的类由/system/framework/framework.jar文件里面的

preloaded-classes文件指定。

system@framework@boot.art@classes.oat是一个OAT文件，通过–oat-file选项传递给dex2oat工具，它是由系统启动

路径中指定的jar文件生成的。每一个jar文件都通过一个–dex-file选项传递给dex2oat工具。这样dex2oat工具就可以将

它们所包含的classes.dex文件里面的DEX字节码翻译成本地机器指令。

这样，我们就得到了一个包含有多个DEX文件的OAT文件system@framework@boot.art@classes.oat。

通过上面的分析，我们就清楚地看到了ART运行时所需要的OAT文件是如何产生的了。其中，由系统启动类路径指定

的DEX文件生成的OAT文件称为类型为BOOT的OAT文件，即boot.art文件。有了这个背景知识之后，接下来我们就继

续分析ART运行时是如何加载OAT文件的。

ART运行时提供了一个OatFile类，通过调用它的静态成员函数Open可以在本进程中加载OAT文件，它的实现如下所

示：

OatFile* OatFile::Open(const std::string& filename,

const std::string& location,

byte* requested_base,

bool executable) {

CHECK(!filename.empty()) location;

CheckLocation(filename);

#ifdef ART_USE_PORTABLE_COMPILER

// If we are using PORTABLE, use dlopen to deal with relocations.

// We use our own ELF loader for Quick to deal with legacy apps that

// open a generated dex file by name, remove the file, then open

// another generated dex file with the same name. http://b/10614658

if (executable) {

return OpenDlopen(filename, location, requested_base);

}

#endif

// If we aren't trying to execute, we just use our own ElfFile loader for a couple reasons:

// On target, dlopen may fail when compiling due to selinux restrictions on installd.

// On host, dlopen is expected to fail when cross compiling, so fall back to OpenElfFile.

// This won't work for portable runtime execution because it doesn't process relocations.

UniquePtr file(OS::OpenFileForReading(filename.c_str()));

if (file.get() == NULL) {

return NULL;

}

return OpenElfFile(file.get(), location, requested_base, false, executable);

}

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

参数filename和location实际上是一样的，指向要加载的OAT文件。参数requested_base是一个可选参数，用来描述要

加载的OAT文件里面的oatdata段要加载在的位置。参数executable表示要加载的OAT是不是应用程序的主执行文件。

一般来说，一个应用程序只有一个classes.dex文件，这个classes.dex文件经过编译后，就得到一个OAT主执行文

件。不过，应用程序也可以在运行时动态加载DEX文件。这些动态加载的DEX文件在加载的时候同样会被翻译成OAT

再运行，它们相应打包在应用程序的classes.dex文件来说，就不属于主执行文件了。

OatFile类的静态成员函数Open的实现虽然只有寥寥几行代码，但是要理解它还得先理解宏

ART_USE_PORTABLE_COMPILER的的作用。在前面Android运行时ART简要介绍和学习计划一文中提到，ART运行

时利用LLVM编译框架来将DEX字节码翻译成本地机器指令，其中要通过一个称为Backend的模块来生成本地机器指

令。这些生成的机器指令就保存在ELF文件格式的OAT文件的oatexec段中。

ART运行时会为每一个类方法都生成一系列的本地机器指令。这些本地机器指令不是孤立存在的，因为它们可能需要

其它的函数来完成自己的功能。例如，它们可能需要调用ART运行的堆管理系统提供的接口来为对象分配内存空间。

这样就会涉及到一个模块依赖性问题，就好像我们在编写程序时，需要依赖C库提供的接口一样。这要求Backend为类

方法生成本地机器指令时，要处理调用其它模块提供的函数的问题。

ART运行时支持两种类型的Backend：Portable和Quick。Portable类型的Backend通过集成在LLVM编译框架里面的一

个称为MCLinker的链接器来生成本地机器指令。关于MCLinker的更多知识，可以参考

https://code.google.com/p/mclinker。简单来说，假设我们有一个模块A，它依赖于模块B、C和D，那么在为模块A生

成本地机器指令时，指出它依赖于模块B、C和D就行了。在生成的OAT文件中会记录好这些依赖关系，这是ELF文件

格式本来就支持的特性。这些OAT文件要通过系统的动态链接器提供的dlopen函数来加载。函数dlopen在加载OAT文

件的时候，会通过重定位技术来处理好它与其它模块的依赖关系，使得它能够调用其它模块提供的接口。这个实际上

就通用的编译器、静态连接器以及动态链接器合作在一起干的事情，MCLinker扮演的就是静态链接器的角色。既然是

通用的技术，因为就称能产生这种OAT文件的Backend为Portable类型的。

另一方面，Quick类型的Backend生成的本地机器指令用另外一种方式来处理依赖模块之间的依赖关系。简单来说，就

是ART运行时会在每一个线程的TLS（线程本地区域）提供一个函数表。可以这个函数表，Quick类型的Backend生成

剩余30页未读，继续阅读

weixin_38639237

粉丝: 3
资源: 958

ART运行时详析：OAT文件加载过程与结构剖析

Android中内存加载dex

Android Oat Foramte分析笔记1

android-art-res, 在android开发的研究艺术中，源代码.zip

Android平台上，OAT文件是如何通过ELF Header、ProgramHeaderTable和SectionHeaderTable来优化原生代码的执行？

在Android OAT文件中，ELF Header、ProgramHeaderTable和SectionHeaderTable如何协同工作以优化原生代码的执行效率？

在Android平台上，OAT文件是如何通过ELF Header、ProgramHeaderTable和SectionHeaderTable来优化原生代码的执行？

UnsupportedOatVersionException: Unsupported oat version: 45

什么是dex2oat?

为什么adb push到设备的apk会变成apk lib oat格式

dex2oat的流程？

最新资源