也来看看Android的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開始：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | 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中。
| 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 28 29 30 31 | 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方法：
| 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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 | voidClassLinker::LoadClass(constDexFile&dex_file, constDexFile::ClassDef&dex_class_def, SirtRef<mirror::Class>&klass, ????????????????????????????mirror::ClassLoader* class_loader) { …… // Load fields fields. constbyte* 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類利用了什么重要的成員：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | 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，這個方法很簡單，就是一句話：
| 1 | returnRuntime::Current()->GetHeap()->AllocObject(self,this,this->object_size_) |
其實是在堆上根據之前LoadClass時指定的類對象的大小分配了一塊內存，按照一個Object對象指針返回。
可以以圖形來展示一下：
看一下最后調用的這個函數：
| 1234567891011 | 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指令。
下面擇要對關鍵代碼進行整理：
| 123456789101112131415 | 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));……} |
在這個函數的調用中，主要進行的多線程進行編譯
| 12345678910111213141516 | 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);……} |
一直到
| 12345678 | 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函數進行真正的編譯過程。
| 12345678910111213141516171819202122232425262728293031323334 | 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函數。
| 123456789101112131415161718192021222324252627 | 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;} |
在這個過程中牽涉了幾種重要的數據結構：
| 12345678910111213141516171819202122232425262728293031323334353637 | 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對象，所以調用的是：
| 1234567891011121314151617181920212223 | 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 labelsProcessSwitchTables();?/* Convert LIR into machine code. */AssembleLIR();???……??}} |
其中重要的兩個調用就是MethodMIR2LIR()和AssembleLIR()。
| 1234567891011121314151617 | 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) {caseXXX: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編譯后的結果：
| 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 28 29 30 31 32 33 34 35 36 37 38 39 40 | java.lang.Stringcom.example.hellojni.HelloJni.stringFromJNI()(dex_method_idx=9) ????DEX?CODE: ????CODE:0xb6bfd1ac?(offset=0x000011acsize=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。
用偽碼表示這個過程：
| 1234 | JniMethodStart(Thread*);ArtMethod?::native_method_(…..);JniMethodEndWithReference(……);return; |
基本上就是這三個函數的調用。
但是從ART的LoadClass的函數來分析，ArtMethod對象與真實執行的代碼鏈接的過程主要是通過LinkCode函數執行的。
| 123456789101112131415161718192021222324252627282930 | 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方法，即
| 1 2 3 | if(method->IsNative()){ method->UnregisterNative(Thread::Current()); ??} |
展開函數：
| 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 | 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函數入手，這個函數使用匯編寫的，與具體的平臺相關。
| 123456789101112131415161718192021 | ENTRYart_jni_dlsym_lookup_stubpush???{r0,r1,r2,r3,lr}??????????@?spillregs????.save??{r0,r1,r2,r3,lr}????.pad#20????.cfi_adjust_cfa_offset20subsp,#12????????????????????????@padstackpointertoalignframe????.pad#12????.cfi_adjust_cfa_offset12blxartFindNativeMethodmovr12,r0????????????????????????@saveresultinr12addsp,#12????????????????????????@restorestackpointer????.cfi_adjust_cfa_offset-12cbzr0,1f????????????????????????@?ismethodcodenull?pop????{r0,r1,r2,r3,lr}??????????@?restoreregs????.cfi_adjust_cfa_offset-20bxr12????????????????????????????@ifnon-null,tailcalltomethod'scode1:????.cfi_adjust_cfa_offset20pop????{r0,r1,r2,r3,pc}??????????@?restoreregs?andreturn?tocaller?tohandle?exception????.cfi_adjust_cfa_offset-20ENDart_jni_dlsym_lookup_stub |
主要的過程就是先調用artFindNativeMethod得到真正的native code的地址，然后在跳轉到相應地址去執行，即對應了
| 1 2 | blxartFindNativeMethod bxr12????????????????????????????@ifnon-null,tailcalltomethod'scode |
兩條指令。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | 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為例。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | 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中的對應：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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的過程進行下分析：
| 1 2 3 | (*pEnv)->FindClass(……); getMethodID(……); (*pEnv)->CallVoidMethod(……); |
即查找類，得到相應的方法的ID，然后通過此ID去調用。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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的類加載過程一致。
| 1 2 3 4 5 6 7 8 9 | 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 總結與補充
總結
以上是生活随笔為你收集整理的也来看看Android的ART运行时的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 安卓代码跟踪方式学习笔记
- 下一篇： 安卓APP动态调试技术