之前因為需要，研究了一下ART的相關原始碼，也做了一些記錄與總結，現在重新整理了一下與大家共同討論和交流一下。

0x00 概述

---

ART是Android平臺上的新一代執行時,用來代替dalvik。它主要採用了AOT的方法，在apk安裝的時候將dalvikbytecode一次性編譯成arm本地指令（但是這種AOT與c語言等還是有本質不同的，還是需要虛擬機器的環境支援），這樣在執行的時候就無需進行任何解釋或編譯便可直接執行，節省了執行時間，提高了效率，但是在一定程度上使得安裝的時間變長，空間佔用變大。

從Android的原始碼上看，ART相關的內容主要有compiler和與之相關的程式dex2oat、runtime、Java除錯支援和對oat檔案進行解析的工具oatdump。

下面這張圖是ART的原始碼目錄結構：

中間有幾個目錄比較關鍵，

首先是dex2oat，負責將dex檔案給轉換為oat檔案，具體的翻譯工作需要由compiler來完成，最後編譯為dex2oat；

其次是runtime目錄，內容比較多，主要就是執行時，編譯為libart.so用來替換libdvm.so，dalvik是一個外殼，其中還是在呼叫ART runtime；

oatdump也是一個比較重要的工具，編譯為oatdump程式，主要用來對oat檔案進行分析並格式化顯示出檔案的組成結構；

jdwpspy是java的除錯支援部分，即JDWP服務端的實現。

0x01 oat檔案

---

oat檔案的格式，可以從dex2oat和oatdump兩個目錄入手。簡單的說，oat檔案是巢狀在一個elf檔案的格式中的。在elf檔案的動態符號表中有三個重要的符號：oatdata、oatexec、oatlastword，分別表示oat的資料區，oat檔案中的native code和結束位置。這些關係結構在圖中說明的很清楚，簡單理解就是在oatdata中，儲存有原來的dex檔案內容，在頭部還保留了定址到dex檔案內容的偏移地址和指向對應的oat class偏移，oat class中還儲存了對應的native code的偏移地址，這樣也就間接的完成了dexbytecode和native code的對應關係。

具體的一些程式碼可以參考/art/dex2oat/dex2oat.cc中的static int dex2oat(intargc, char** argv)函式和/art/oatdump/oatdump.cc的static intoatdump(intargc, char** argv)的函式，可以很快速的理解oat檔案的格式和解析。在/art/compiler/elf_writer_quick.cc中的Write函式很值得參考。

0x02 執行時的啟動

---

ART執行時的啟動過程很早，是由zygote所啟動的，與dalvik的啟動過程完全一樣，保證了由dalvik到ART的無縫銜接。

整個啟動過程是從app_processs（/frameworks/base/cmds/app_process/app_main.cpp）開始的，建立了一個物件AppRuntime runtime，這個是一個單例，整個系統執行時只有一個。隨著zygote的fork過程，只是在不斷地複製指向這個物件的指標個每個子程式。然後就開始執行runtime.start方法。這個方法裡先呼叫startVm啟動虛擬機器。是由JNI_CreateJavaVM方法具體執行的的，即/art/runtime/jni_internal.cc的 extern "C" jintJNI_CreateJavaVM(JavaVM** p_vm, JNIEnv** p_env, void* vm_args)。然後呼叫startReg註冊一些native的method。在最後比較重要的是查詢到要執行的java程式碼的main方法，然後執行進入托管程式碼的世界，這也是我們感興趣的地方。

如圖，最後呼叫的是CallStaticVoidMethod，去看看它的實現：

再去尋找InvokeWithVarArgs：

跳到InvokeWithArgArray：

可以看到一個很關鍵的class：

即ArtMethod，它的一個成員方法就是負責呼叫oat檔案中的native code的：

最後這就是最終的入口：

283行的blxip指令就是最終進入native code的位置。可以大致得到結論，透過查詢相關的oat檔案，得到所需要的類和方法，並將其對應的native code的位置放入ArtMethod結構，最後透過Invoke成員完成呼叫。下一步的工作需要著重關注的便是native code程式碼呼叫其他的java方法時如何去透過執行時定位和跳轉的。

注意註釋中描述了ART下的ABI，與標準的ARM呼叫約定相似，但是R0存放的是呼叫者的方法的ArtMethod物件地址，R0-R3包含的才是引數，包括this。多餘的存放在棧中，從SP+16的位置開始。返回值同樣透過R0/R1傳遞。R9指向執行時分配的當前的執行緒物件指標。

0x03 類載入

---

類載入的任務主要由ClassLinker類來負責，先看一下這個過程的順序圖：

順序圖中以靜態成員的初始化和虛擬函式的初始化為例，描述了呼叫的邏輯。下面進行詳細的敘述。

從FindClass開始：

#!java
mirror::Class* ClassLinker::FindClass(constchar* descriptor, mirror::ClassLoader* class_loader) {
……
mirror::Class* klass = LookupClass(descriptor, class_loader);
if (klass != NULL) {
returnEnsureResolved(self, klass);
  }
if (descriptor[0] == '[') {
returnCreateArrayClass(descriptor, class_loader);   

  } elseif (class_loader == NULL) {
DexFile::ClassPathEntry pair = DexFile::FindInClassPath(descriptor, boot_class_path_);
if (pair.second != NULL) {
returnDefineClass(descriptor, NULL, *pair.first, *pair.second);
    }
……
}

省略次要的程式碼，首先利用LookupClass查詢所需要的類是否被載入，對於此場景所以不符合此條件。然後判斷是否是陣列型別的類，也跳過此分支，進入到我們最感興趣的DefineClass中。

#!java
mirror::Class* ClassLinker::DefineClass(constchar* descriptor,
                                        mirror::ClassLoader* class_loader,
constDexFile&dex_file,
constDexFile::ClassDef&dex_class_def) {
……
SirtRef<mirror::Class>klass(self, NULL);
if (UNLIKELY(!init_done_)) {
// finish up init of hand crafted class_roots_
if (strcmp(descriptor, "Ljava/lang/Object;") == 0) {
klass.reset(GetClassRoot(kJavaLangObject));
    } elseif (strcmp(descriptor, "Ljava/lang/Class;") == 0) {
klass.reset(GetClassRoot(kJavaLangClass));
    } elseif (strcmp(descriptor, "Ljava/lang/String;") == 0) {
klass.reset(GetClassRoot(kJavaLangString));
    } elseif (strcmp(descriptor, "Ljava/lang/DexCache;") == 0) {
klass.reset(GetClassRoot(kJavaLangDexCache));
    } elseif (strcmp(descriptor, "Ljava/lang/reflect/ArtField;") == 0) {
klass.reset(GetClassRoot(kJavaLangReflectArtField));
    } elseif (strcmp(descriptor, "Ljava/lang/reflect/ArtMethod;") == 0) {
klass.reset(GetClassRoot(kJavaLangReflectArtMethod));
    } else {
klass.reset(AllocClass(self, SizeOfClass(dex_file, dex_class_def)));
    }
  } else {
klass.reset(AllocClass(self, SizeOfClass(dex_file, dex_class_def)));
  }
klass->SetDexCache(FindDexCache(dex_file));
LoadClass(dex_file, dex_class_def, klass, class_loader);
……
returnklass.get();
}

揀重要的部分看，這個方法基本上完成了兩個個功能，即從dex檔案載入類和載入過的類插入一個表中，供LookupClass查詢。

我們關注第一個功能，首先是進行一些內建類的判斷，對於自定義的類則是手動分配空間、，然後查詢相關的dex檔案，最後進行載入。

接著看LoadClass方法：

#!java
voidClassLinker::LoadClass(constDexFile&dex_file,
constDexFile::ClassDef&dex_class_def,
SirtRef<mirror::Class>&klass,
                            mirror::ClassLoader* class_loader) {
……
// Load fields fields.
const byte* class_data = dex_file.GetClassData(dex_class_def);
if (class_data == NULL) {
return;  // no fields or methods - for example a marker interface
  }
ClassDataItemIteratorit(dex_file, class_data);
  Thread* self = Thread::Current();
if (it.NumStaticFields() != 0) {
    mirror::ObjectArray<mirror::ArtField>* statics = AllocArtFieldArray(self, it.NumStaticFields());
if (UNLIKELY(statics == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetSFields(statics);
  }
if (it.NumInstanceFields() != 0) {
    mirror::ObjectArray<mirror::ArtField>* fields =
AllocArtFieldArray(self, it.NumInstanceFields());
if (UNLIKELY(fields == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetIFields(fields);
  }
for (size_ti = 0; it.HasNextStaticField(); i++, it.Next()) {
SirtRef<mirror::ArtField>sfield(self, AllocArtField(self));
if (UNLIKELY(sfield.get() == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetStaticField(i, sfield.get());
LoadField(dex_file, it, klass, sfield);
  }
for (size_ti = 0; it.HasNextInstanceField(); i++, it.Next()) {
SirtRef<mirror::ArtField>ifield(self, AllocArtField(self));
if (UNLIKELY(ifield.get() == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetInstanceField(i, ifield.get());
LoadField(dex_file, it, klass, ifield);
  } 

UniquePtr<constOatFile::OatClass>oat_class;
if (Runtime::Current()->IsStarted() && !Runtime::Current()->UseCompileTimeClassPath()) {
oat_class.reset(GetOatClass(dex_file, klass->GetDexClassDefIndex()));
  } 

// Load methods.
if (it.NumDirectMethods() != 0) {
// TODO: append direct methods to class object
    mirror::ObjectArray<mirror::ArtMethod>* directs =
AllocArtMethodArray(self, it.NumDirectMethods());
if (UNLIKELY(directs == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetDirectMethods(directs);
  }
if (it.NumVirtualMethods() != 0) {
// TODO: append direct methods to class object
    mirror::ObjectArray<mirror::ArtMethod>* virtuals =
AllocArtMethodArray(self, it.NumVirtualMethods());
if (UNLIKELY(virtuals == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetVirtualMethods(virtuals);
  }
size_tclass_def_method_index = 0;
for (size_ti = 0; it.HasNextDirectMethod(); i++, it.Next()) {
SirtRef<mirror::ArtMethod>method(self, LoadMethod(self, dex_file, it, klass));
if (UNLIKELY(method.get() == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetDirectMethod(i, method.get());
if (oat_class.get() != NULL) {
LinkCode(method, oat_class.get(), class_def_method_index);
    }
method->SetMethodIndex(class_def_method_index);
class_def_method_index++;
  }
for (size_ti = 0; it.HasNextVirtualMethod(); i++, it.Next()) {
SirtRef<mirror::ArtMethod>method(self, LoadMethod(self, dex_file, it, klass));
if (UNLIKELY(method.get() == NULL)) {
CHECK(self->IsExceptionPending());  // OOME.
return;
    }
klass->SetVirtualMethod(i, method.get());
    DCHECK_EQ(class_def_method_index, it.NumDirectMethods() + i);
if (oat_class.get() != NULL) {
LinkCode(method, oat_class.get(), class_def_method_index);
    }
class_def_method_index++;
  }
……
}

為了弄清這個方法，我們先得看看Class類利用了什麼重要的成員：

#!java
ObjectArray<ArtMethod>* direct_methods_;
// instance fields
// specifies the number of reference fields.
ObjectArray<ArtField>* ifields_;
// For every interface a concrete class implements, we create an array of the concrete vtable_
// methods for the methods in the interface.
IfTable* iftable_;
// Static fields
ObjectArray<ArtField>* sfields_;
// The superclass, or NULL if this is java.lang.Object, an interface or primitive type.
// Virtual methods defined in this class; invoked through vtable.
ObjectArray<ArtMethod>* virtual_methods_;
// Virtual method table (vtable), for use by "invoke-virtual".  The vtable from the superclass is
// copied in, and virtual methods from our class either replace those from the super or are
// appended. For abstract classes, methods may be created in the vtable that aren't in
// virtual_ methods_ for miranda methods.
ObjectArray<ArtMethod>* vtable_;
// Total size of the Class instance; used when allocating storage on gc heap.
// See also object_size_.
size_tclass_size_;

這樣就比較清晰了。LoadClass首先讀取dex檔案中的classdata，然後初始化一個迭代器來對classdata中的資料進行遍歷。接下來分部分進行：

分配一個物件ObjectArray來表示靜態成員，並利用靜態成員的數量初始化，並將這個物件的地址賦值給Class的sfields_成員。

同樣的完成Class的ifields_成員的初始化，用來表示私有資料成員

接下來，遍歷靜態成員，對於每個成員分配一個Object物件，然後將地址放入之前分配的ObjectArray陣列中，並將dex檔案中的相關資訊載入到Object物件中，從而完成了靜態成員資訊的讀取。

同理，完成了私有成員資訊的讀取。

像對於資料成員一樣，分配一個ObjectArray用於表示directmethod，並用於初始化direct_methods_成員。

同理，初始化了virtual_methods_成員。

遍歷directmethod成員，對於每一個directmethod生成一個ArtMethod物件，並在建構函式中透過LoadMethod完成dex檔案中相應資訊的讀取。再將ArtMethod物件放入之前的ObjectArray中，還需要利用LinkCode將實際的方法程式碼起始地址用來初始化ArtMethod的entry_point_from_compiled_code_成員，最後更新每個ArtMethod的method_index_成員用於方法索引查詢。

同樣的過程完成了對於VirtualMethod的處理

最終就完成了類的載入。

下面需要再關注一下一個類例項化的過程。

類的例項化是透過TLS（執行緒區域性儲存）中的一個函式表中的pAllocObject來進行的。pAllocObject這個函式指標被指向了art_quick_alloc_object函式。這個函式是與硬體相關的，實際上它又呼叫了artAllocObjectFromCode函式，又呼叫了AllocObjectFromCode函式，在完成了一系列檢查判斷後呼叫了Class::AllocObject，這個方法很簡單，就是一句話：

returnRuntime::Current()->GetHeap()->AllocObject(self, this, this->object_size_)

其實是在堆上根據之前LoadClass時指定的類物件的大小分配了一塊記憶體，按照一個Object物件指標返回。

可以以圖形來展示一下：

看一下最後呼叫的這個函式：

#!java
mirror::Object* Heap::AllocObject(Thread* self, mirror::Class* c, size_tbyte_count) {
……
obj = Allocate(self, alloc_space_, byte_count, &bytes_allocated);
 ……
if (LIKELY(obj != NULL)) {
obj->SetClass(c);
   ……
returnobj;
  } else {
   ……
}

在這個函式中分配了記憶體空間之後，還呼叫了SetClass這個關鍵的函式，把Object物件中的klass_成員利用LoadClass的結果初始化了。

這樣的話一個完整的類的例項化的記憶體結構就如圖所示了：

0x04 編譯過程

---

關於ART的編譯過程，主要是由dex2oat程式啟動的，所以可以從dex2oat入手，先畫出整個過程的順序圖。

上圖是第一階段的流程，主要是由dex2oat呼叫編譯器的過程。

第二階段主要是進入編譯器的處理流程，透過對dalvik指令進行一次編譯為MIR，然後二次編譯為LIR，最後編譯成ARM指令。

下面擇要對關鍵程式碼進行整理：

#!java
staticintdex2oat(intargc, char** argv){
……
UniquePtr<constCompilerDriver>compiler(dex2oat->CreateOatFile(boot_image_option,
host_prefix.get(),
android_root,
is_host,
dex_files,
oat_file.get(),
bitcode_filename,
image,
image_classes,
dump_stats,
timings));
……
}

在這個函式的呼叫中，主要進行的多執行緒進行編譯

#!java
voidCompilerDriver::CompileAll(jobjectclass_loader,
conststd::vector<constDexFile*>&dex_files,
base::TimingLogger&timings)
{
……
Compile(class_loader, dex_files, *thread_pool.get(), timings);
……
}   

voidCompilerDriver::Compile(jobjectclass_loader,
conststd::vector<constDexFile*>&dex_files,
ThreadPool&thread_pool, base::TimingLogger&timings) {
……
CompileDexFile(class_loader, *dex_file, thread_pool, timings);
……
}

一直到

#!java
voidCompilerDriver::CompileDexFile(jobjectclass_loader,
constDexFile&dex_file,ThreadPool&thread_pool,
base::TimingLogger&timings) {
……
context.ForAll(0, dex_file.NumClassDefs(),
CompilerDriver::CompileClass, thread_count_);
……
}

啟動了多執行緒,執行CompilerDriver::CompileClass函式進行真正的編譯過程。

#!java
voidCompilerDriver::CompileClass(constParallelCompilationManager* manager, size_tclass_def_index) {
……
ClassDataItemIteratorit(dex_file, class_data);
CompilerDriver* driver = manager->GetCompiler();
int64_tprevious_direct_method_idx = -1;
while (it.HasNextDirectMethod()) {
uint32_tmethod_idx = it.GetMemberIndex();
if (method_idx == previous_direct_method_idx) {
it.Next();
continue;
    }
previous_direct_method_idx = method_idx;
driver->CompileMethod(it.GetMethodCodeItem(),
    it.GetMemberAccessFlags(),
    it.GetMethodInvokeType(class_def),class_def_index,
    method_idx, jclass_loader, dex_file,
    dex_to_dex_compilation_level);
it.Next();
  }
int64_tprevious_virtual_method_idx = -1;
while (it.HasNextVirtualMethod()) {
uint32_tmethod_idx = it.GetMemberIndex();
if (method_idx == previous_virtual_method_idx) {
it.Next();
continue;
    }
previous_virtual_method_idx = method_idx;
driver->CompileMethod(it.GetMethodCodeItem(),
    it.GetMemberAccessFlags(),
    it.GetMethodInvokeType(class_def), class_def_index,
    method_idx, jclass_loader, dex_file,
    dex_to_dex_compilation_level);
it.Next();
  }

主要過程就是透過讀取class中的資料，利用迭代器遍歷每個DirectMethod和VirtualMethod，然後分別對每個Method作為單元利用CompilerDriver::CompileMethod進行編譯。

CompilerDriver::CompileMethod函式主要是呼叫了CompilerDriver::CompilerDriver* constcompiler_這個成員變數（函式指標）。

這個變數是在CompilerDriver的建構函式中初始化的，根據不同的編譯器後端選擇不同的實現，不過基本上的流程都是一樣的，透過對Portable後端的分析，可以看到最後呼叫的是static CompiledMethod* CompileMethod函式。

#!java
staticCompiledMethod* CompileMethod(CompilerDriver&compiler,
constCompilerBackendcompiler_backend,
constDexFile::CodeItem* code_item,
uint32_taccess_flags, InvokeTypeinvoke_type,
uint16_tclass_def_idx, uint32_tmethod_idx,
jobjectclass_loader, constDexFile&dex_file
#ifdefined(ART_USE_PORTABLE_COMPILER)
 , llvm::LlvmCompilationUnit* llvm_compilation_unit
#endif
) {
……
    cu.mir_graph.reset(newMIRGraph(&cu, &cu.arena));
    cu.mir_graph->InlineMethod(code_item, access_flags, invoke_type, class_def_idx, method_idx,class_loader, dex_file);
    cu.mir_graph->CodeLayout();
    cu.mir_graph->SSATransformation();
    cu.mir_graph->PropagateConstants();
    cu.mir_graph->MethodUseCount();
    cu.mir_graph->NullCheckElimination();
    cu.mir_graph->BasicBlockCombine();
    cu.mir_graph->BasicBlockOptimization();
    ……
    cu.cg.reset(ArmCodeGenerator(&cu, cu.mir_graph.get(), &cu.arena));
    ……
    cu.cg->Materialize();
    result = cu.cg->GetCompiledMethod();
    returnresult;
}

在這個過程中牽涉了幾種重要的資料結構：

#!java
classMIRGraph {
……
BasicBlock* entry_block_;
BasicBlock* exit_block_;
BasicBlock* cur_block_;
intnum_blocks_;
 ……
}
structBasicBlock {
  ……
MIR* first_mir_insn;
MIR* last_mir_insn;
BasicBlock* fall_through;
BasicBlock* taken;
BasicBlock* i_dom;                // Immediate dominator.
 ……
};
structMIR {
DecodedInstructiondalvikInsn;
……
MIR* prev;
MIR* next;
 ……
};
structDecodedInstruction {
uint32_tvA;
uint32_tvB;
uint64_tvB_wide;        /* for k51l */
uint32_tvC;
uint32_targ[5];         /* vC/D/E/F/G in invoke or filled-new-array */
Instruction::Codeopcode;    

explicitDecodedInstruction(constInstruction* inst) {
inst->Decode(vA, vB, vB_wide, vC, arg);
opcode = inst->Opcode();
  }
};

這幾個資料結構的關係如圖所示：

簡單地說，一個MIRGraph對應著一個編譯單元即一個方法，對一個方法進行控制流分析，劃分出BasicBlock，並在BasicBlock中的fall_through和taken域中指向下一個BasicBlock（適用於分支出口）。每一個BasicBlock包含若干dalvik指令，每一天dalvik指令被翻譯為若干MIR語句，這些MIR結構體之間形成雙向連結串列。每一個BasicBlock也指示了第一條和最後一條MIR語句。

InlineMethod函式主要是解析一個方法，並劃分BasicBlock邊界，但是隻是簡單地把BasicBlock連線成一個連結串列，利用fall_through指示。

在CodeLayout函式中具體地再次遍歷BasicBlock連結串列，並根據每個BasicBlock出口的指令，再次調整taken域和fall_through域，形成完整的控制流圖結構。

SSATransformation函式是對每條指令進行靜態單賦值變換。先對控制流圖進行深度優先遍歷，並計算出BasicBlock之間的支配關係，插入Phi函式，並對變數進行命名更新。

其餘的方法主要是一些程式碼最佳化過程，例如常量傳播、消除空指標檢查；並在BasicBlock組合之後再進行BasicBlock的最佳化，消除冗餘指令。

這樣基本上就完成了MIR的生成過程，在某種程度上，可以認為MIR即為對dalvik指令進行SSA變換之後的指令形態。

接著就呼叫cu.cg->Materialize()用來產生最終程式碼。cu.cg在之前的程式碼被指向了Mir2Lir物件，所以呼叫的是：

#!java
voidMir2Lir::Materialize() {
CompilerInitializeRegAlloc();  // Needs to happen after SSA naming  

/* Allocate Registers using simple local allocation scheme */
SimpleRegAlloc();   

 ……
/* Convert MIR to LIR, etc. */
if (first_lir_insn_ == NULL) {
MethodMIR2LIR();
  } 

/* Method is not empty */
if (first_lir_insn_) {
// mark the targets of switch statement case labels
ProcessSwitchTables();  

/* Convert LIR into machine code. */
AssembleLIR();  

  ……
  }
}

其中重要的兩個呼叫就是MethodMIR2LIR()和AssembleLIR()。

#!java
MethodMIR2LIR將MIR轉化為LIR，遍歷每個BasicBlock，對每個基本塊執行MethodBlockCodeGen，本質上最後是執行了CompileDalvikInstruction。    

voidMir2Lir::CompileDalvikInstruction(MIR* mir, BasicBlock* bb, LIR* label_list) {
  ……
Instruction::Codeopcode = mir->dalvikInsn.opcode;
intopt_flags = mir->optimization_flags;
uint32_tvB = mir->dalvikInsn.vB;
uint32_tvC = mir->dalvikInsn.vC;    

……
switch (opcode) {
case XXX:
GenXXXXXX(……)
default:
LOG(FATAL) <<"Unexpected opcode: "<<opcode;
  }
}  

也就是透過解析指令，然後根據opcode進行分支判斷，呼叫最終不同的指令生成函式。最後將LIR之間也形成一個雙向連結串列。

AssembleLIR最終呼叫的是AssembleInstructions函式。程式中維護了一個編碼指令表ArmMir2Lir::EncodingMap，AssembleInstructions即是透過查詢這個表來進行翻譯，將LIR轉化為了ARM指令，並將所翻譯的指令儲存到CodeBufferMir2Lir::code_buffer_之中。

這樣就完成了一次編譯的完整流程。

0x05 JNI分析

---

ART環境中的JNI介面與Dalvik同樣符合JVM標準，但是其中的實現卻有所不同。以下透過三個過程來進行簡述。

1、類載入初始化

首先觀察一個native的java成員方法透過dex2oat編譯後的結果：

java.lang.Stringcom.example.hellojni.HelloJni.stringFromJNI() (dex_method_idx=9)
    DEX CODE:
    CODE: 0xb6bfd1ac (offset=0x000011ac size=148)...
      0xb6bfd1ac: e92d4de0  stmdbsp!, {r5, r6, r7, r8, r10, r11, lr}
      0xb6bfd1b0: e24dd024  sub     sp, sp, #36
      0xb6bfd1b4: e58d0000  str     r0, [sp, #0]
      0xb6bfd1b8: e58d1044  str     r1, [sp, #68]
      0xb6bfd1bc: e3a0c001  mov    r12, r0, #1
      0xb6bfd1c0: e58dc004  str     r12, [sp, #4]
      0xb6bfd1c4: e599c074  ldr     r12, [r9, #116]  ;top_sirt_
      0xb6bfd1c8: e58dc008  str     r12, [sp, #8]
      0xb6bfd1cc: e28dc004  add    r12, sp, #4
      0xb6bfd1d0: e589c074  str     r12, [r9, #116]  ;top_sirt_
      0xb6bfd1d4: e59dc044  ldr     r12, [sp, #68]
      0xb6bfd1d8: e58dc00c  str     r12, [sp, #12]
      0xb6bfd1dc: e589d01c  strsp, [r9, #28]  ; 28
      0xb6bfd1e0: e3a0c000  mov    r12, r0, #0
      0xb6bfd1e4: e589c020  str     r12, [r9, #32]  ; 32
      0xb6bfd1e8: e1a00009  mov    r0, r9
      0xb6bfd1ec: e590c1b8  ldr  r12, [r0, #440] //qpoints->pJniMethodStart = JniMethodStart
      0xb6bfd1f0: e12fff3c  blx     r12
      0xb6bfd1f4: e58d0010  str     r0, [sp, #16]
      0xb6bfd1f8: e28d100c  add     r1, sp, #12
      0xb6bfd1fc: e5990024  ldr     r0, [r9, #36]  ;jni_env_
      0xb6bfd200: e59dc000  ldr     r12, [sp, #0]
      0xb6bfd204: e59cc048  ldr     r12, [r12, #72]
      0xb6bfd208: e12fff3c  blx     r12    // const void* ArtMethod::native_method_
      0xb6bfd20c: e59d1010  ldr     r1, [sp, #16]
      0xb6bfd210: e1a02009  mov    r2, r9
      0xb6bfd214: e592c1c8  ldr     r12, [r2, #456]
      0xb6bfd218: e12fff3c  blx r12//qpoints->pJniMethodEndWithReference= JniMethodEndWithReference
      0xb6bfd21c: e599c00c  ldr     r12, [r9, #12]  ; exception_
      0xb6bfd220: e35c0000  cmp     r12, #0
      0xb6bfd224: 1a000001  bne     +4 (0xb6bfd230)
      0xb6bfd228: e28dd03c  add     sp, sp, #60
      0xb6bfd22c: e8bd8000  ldmiasp!, {pc}
      0xb6bfd230: e1a0000c  mov     r0, r12
      0xb6bfd234: e599c260  ldr     r12, [r9, #608]  ;pDeliverException
      0xb6bfd238: e12fff3c  blx     r12
      0xb6bfd23c: e1200070  bkpt    #0

可以看到，它沒有對應的dex code。

用偽碼錶示這個過程：

JniMethodStart(Thread*);
ArtMethod ::native_method_(…..);
JniMethodEndWithReference(……);
return;

基本上就是這三個函式的呼叫。

但是從ART的LoadClass的函式來分析，ArtMethod物件與真實執行的程式碼連結的過程主要是透過LinkCode函式執行的。

#!java
staticvoidLinkCode(SirtRef<mirror::ArtMethod>&method, constOatFile::OatClass* oat_class,
uint32_tmethod_index)
SHARED_LOCKS_REQUIRED(Locks::mutator_lock_) {
DCHECK(method->GetEntryPointFromCompiledCode() == NULL);
constOatFile::OatMethodoat_method = oat_class->GetOatMethod(method_index);
oat_method.LinkMethod(method.get());    

Runtime* runtime = Runtime::Current();
boolenter_interpreter = NeedsInterpreter(method.get(), method->GetEntryPointFromCompiledCode());
if (enter_interpreter) {  method->SetEntryPointFromInterpreter(interpreter::artInterpreterToInterpreterBridge);
} else{ method->SetEntryPointFromInterpreter(artInterpreterToCompiledCodeBridge);
 }  

if (method->IsAbstract()) { method->SetEntryPointFromCompiledCode(GetCompiledCodeToInterpreterBridge());
return;
  } 

if (method->IsStatic() && !method->IsConstructor()) {
method->SetEntryPointFromCompiledCode(GetResolutionTrampoline(runtime->GetClassLinker()));
  } elseif (enter_interpreter) {
method->SetEntryPointFromCompiledCode(GetCompiledCodeToInterpreterBridge());
  } 

if (method->IsNative()) {
method->UnregisterNative(Thread::Current());
  } 

runtime->GetInstrumentation()->UpdateMethodsCode(method.get(),
method->GetEntryPointFromCompiledCode());
}

可以看到，在LinkCode的開始就將透過oat_method.LinkMethod(method.get())將物件與程式碼進行了連結，但是在後邊又針對幾種特殊情況做了一些處理，包括解釋執行入口和靜態方法等等。我們主要關注的是JNI方法，即

if (method->IsNative()) {
method->UnregisterNative(Thread::Current());
  }

展開函式：

#!java
voidArtMethod::UnregisterNative(Thread* self) {
CHECK(IsNative()) <<PrettyMethod(this);
RegisterNative(self, GetJniDlsymLookupStub());
}   

extern"C"void* art_jni_dlsym_lookup_stub(JNIEnv*, jobject);
staticinlinevoid* GetJniDlsymLookupStub() {
returnreinterpret_cast<void*>(art_jni_dlsym_lookup_stub);
}   

voidArtMethod::RegisterNative(Thread* self, constvoid* native_method) {
DCHECK(Thread::Current() == self);
CHECK(IsNative()) <<PrettyMethod(this);
CHECK(native_method != NULL) <<PrettyMethod(this);
if (!self->GetJniEnv()->vm->work_around_app_jni_bugs) {
SetNativeMethod(native_method);
  } else {
SetNativeMethod(reinterpret_cast<void*>(art_work_around_app_jni_bugs));
SetFieldPtr<constuint8_t*>(OFFSET_OF_OBJECT_MEMBER(ArtMethod, gc_map_),
reinterpret_cast<constuint8_t*>(native_method), false);
  }
}   

voidArtMethod::SetNativeMethod(constvoid* native_method) {
SetFieldPtr<constvoid*>(OFFSET_OF_OBJECT_MEMBER(ArtMethod, native_method_),
native_method, false);
}

很清晰可以看到，在類載入的時候是把ArtMethod的native_method_成員設定為了art_jni_dlsym_lookup_stub函式，那麼在執行JNI方法的時候就會執行art_jni_dlsym_lookup_stub函式。

2、透過java呼叫JNI方法

從art_jni_dlsym_lookup_stub函式入手，這個函式使用匯編寫的，與具體的平臺相關。

ENTRYart_jni_dlsym_lookup_stub
push   {r0, r1, r2, r3, lr}           @ spillregs
    .save  {r0, r1, r2, r3, lr}
    .pad #20
    .cfi_adjust_cfa_offset20
subsp, #12                        @ padstackpointertoalignframe
    .pad #12
    .cfi_adjust_cfa_offset12
blxartFindNativeMethod
movr12, r0                        @ saveresultinr12
addsp, #12                        @ restorestackpointer
    .cfi_adjust_cfa_offset -12
cbzr0, 1f                         @ ismethodcodenull?
pop    {r0, r1, r2, r3, lr}           @ restoreregs
    .cfi_adjust_cfa_offset -20
bxr12                            @ ifnon-null, tailcalltomethod's code
1:
    .cfi_adjust_cfa_offset 20
pop    {r0, r1, r2, r3, pc}           @ restore regs and return to caller to handle exception
    .cfi_adjust_cfa_offset -20
END art_jni_dlsym_lookup_stub

主要的過程就是先呼叫artFindNativeMethod得到真正的native code的地址，然後在跳轉到相應地址去執行，即對應了

blxartFindNativeMethod
bxr12                            @ ifnon-null, tailcalltomethod's code

兩條指令。

#!java
extern"C"void* artFindNativeMethod() {
Thread* self = Thread::Current();
Locks::mutator_lock_->AssertNotHeld(self);  
ScopedObjectAccesssoa(self);    

mirror::ArtMethod* method = self->GetCurrentMethod(NULL);
DCHECK(method != NULL); 

void* native_code = soa.Vm()->FindCodeForNativeMethod(method);
if (native_code == NULL) {
DCHECK(self->IsExceptionPending());
returnNULL;
  } else {
method->RegisterNative(self, native_code);
returnnative_code;
  }
}   

主要的過程也就是查詢到相應方法的native code，然後再次設定ArtMethod的native_method_成員，這樣以後再執行的時候就直接跳到了native code執行了。

3、Native方法中呼叫java方法

這個主要是透過JNIEnv來間接呼叫的。JNIEnv中維持了許多JNI API可以被native code來使用。C和C++的實現形式略有不同，C++是對C的事先進行了一個簡單的包裝，具體可以參見jni.h。這裡為了便於敘述以C為例。

#!java
typedefconststructJNINativeInterface* JNIEnv;
structJNINativeInterface {
void*       reserved0;
void*       reserved1;
void*       reserved2;
void*       reserved3;
jint        (*GetVersion)(JNIEnv *);
jclass      (*DefineClass)(JNIEnv*, constchar*, jobject, constjbyte*,  jsize);
jclass      (*FindClass)(JNIEnv*, constchar*);
…………
…………
jobject     (*NewDirectByteBuffer)(JNIEnv*, void*, jlong);
void*       (*GetDirectBufferAddress)(JNIEnv*, jobject);
jlong       (*GetDirectBufferCapacity)(JNIEnv*, jobject);
jobjectRefType (*GetObjectRefType)(JNIEnv*, jobject);
};

這些API以函式指標的形式存在，並在libart.so中實現，在整個art的初始化的過程中進行了對應。

在libart.so中的對應：

#!java
constJNINativeInterfacegJniNativeInterface = {
NULL,  // reserved0.
NULL,  // reserved1.
NULL,  // reserved2.
NULL,  // reserved3.
JNI::GetVersion,
JNI::DefineClass,
JNI::FindClass,
…………
…………
JNI::NewDirectByteBuffer,
JNI::GetDirectBufferAddress,
JNI::GetDirectBufferCapacity,
JNI::GetObjectRefType,
};

下面以一個常見的native code呼叫java的過程進行下分析：

(*pEnv)->FindClass(……);
getMethodID(……);
(*pEnv)->CallVoidMethod(……);

即查詢類，得到相應的方法的ID，然後透過此ID去呼叫。

#!java
staticjclassFindClass(JNIEnv* env, constchar* name) {
CHECK_NON_NULL_ARGUMENT(FindClass, name);
Runtime* runtime = Runtime::Current();
ClassLinker* class_linker = runtime->GetClassLinker();
std::stringdescriptor(NormalizeJniClassDescriptor(name));
ScopedObjectAccesssoa(env);
Class* c = NULL;
if (runtime->IsStarted()) {
ClassLoader* cl = GetClassLoader(soa);
      c = class_linker->FindClass(descriptor.c_str(), cl);
    } else {
      c = class_linker->FindSystemClass(descriptor.c_str());
    }
returnsoa.AddLocalReference<jclass>(c);
  } 

可以看到JNI中的FindClass實際呼叫的是ClassLinker::FindClass，這與ART的類載入過程一致。

#!java
staticvoidCallVoidMethod(JNIEnv* env, jobjectobj, jmethodIDmid, ...) {
va_listap;
va_start(ap, mid);
CHECK_NON_NULL_ARGUMENT(CallVoidMethod, obj);
CHECK_NON_NULL_ARGUMENT(CallVoidMethod, mid);
ScopedObjectAccesssoa(env);
InvokeVirtualOrInterfaceWithVarArgs(soa, obj, mid, ap);
va_end(ap);
  }

最後呼叫的是ArtMethod::Invoke()。

可以說如出一轍，即JNI的這些API其實還是做了一遍ART的類載入和初始化及呼叫的過程。

0x06 總結與補充

---

1. oat檔案作為一個靜態庫的形式被載入到zygote程式的空間中，並由libart.so負責虛擬機器的功能，完成對oat檔案的解析，方法的查詢和呼叫，並負責垃圾回收。
2. runtime可以實現在部分未被編譯的方法和已被編譯的方法之前的互動呼叫，為此runtime提供了諸如artInterpreterToInterpreterBridge、artInterpreterToCompiledCodeBridge之類的函式進行銜接。
3. 所有的Java方法在編譯為arm指令後都符合一定的標準。由於是在runtime中執行的，所有的R0暫存器代表著一個隱含的引數，指令當前的ArtMethod物件，R1-R3傳遞前幾個引數（包括this），多餘的引數依靠堆疊傳遞。
4. 系統的啟動類（在環境變數BOOTCLASSPATH中指定）被翻譯為boot.oat，boot.art包含了其載入後的類物件，啟動時以直接被載入程式空間中。
5. 同一個dex檔案中的方法，載入的時候會被直接解析到ArtMethod物件的dex_cache_resolved_methods_成員中，直接透過R0暫存器定址。而系統的API主要是透過找到代表包含API的物件Object例項中的Class域，然後在其中的函式表中查詢解決的；Class例項的初始化，是在載入每個oat檔案解析類資訊時建立的。
6. 一些關鍵的系統呼叫，如分配物件等，是有libart.so來提供的，並且與平臺有相關性，存放在每個Thread物件的quick_entrypoints_域中。
7. dex2oat在兩個時間被執行，一是apk安裝的時候，二是在呼叫DexClassLoader動態載入dex檔案的時候。
8. 具體的說編譯的目標指令為Thumb-2指令集，支援16位指令和32位指令的混合執行。
9. 在編譯boot.art和boot.oat檔案時，不需要其他的支援，但是在編譯其他的dex檔案時需要在虛擬機器環境中載入上述檔案。編譯執行的過程也需要虛擬機器環境的支援，只不過是用於編譯而非執行，這樣可以保證編譯的目標檔案是在虛擬機器環境中的一個完整的映像而不會出現定址錯誤等。
10. 整個編譯過程基本上是依靠dex2oat來載入CompilerDriver，然後逐個方法來進行編譯。將每個方法劃分BasicBlock，繪製MIRGraph（控制流圖），逐個翻譯為以dalvikbtecode的SSA形式為基礎的MIR，然後將MIR解析為LIR，最後翻譯為Thumb-2指令，最後統一寫入一個ELF檔案即oat檔案。