目錄

1、dex檔案分析

邏輯上，可以把dex檔案分成3個區，標頭檔案、索引區和資料區。索引區的ids字尾為identifiers的縮寫。

header

dex檔案裡的header。除了描述.dex檔案的檔案資訊外，還有檔案裡其他各個區域的索引。

（1）           magic value，這8個位元組一般是常量，為了使.dex檔案能夠被識別出來，它必須出現在.dex檔案的最開頭的位置。

（2）           checksum和signature.檔案校驗碼，使用alder32演算法校驗檔案出去maigc,checksum外餘下的所有檔案區域，用於校驗檔案錯誤。Signature,使用SHA-1演算法hash除去magic,checksum和signature外餘下的所有檔案區域。

（3）           file_size:Dex檔案的大小。

其餘的屬性，因為在加固中沒有用到。這裡就不對它們進行過多解釋。

2、odex檔案

odex是OptimizedDEX的縮寫，表示經過優化的dex檔案。存放在/data/dalvik-cache目錄下。由於Android程式的apk檔案為zip壓縮包格式，Dalvik虛擬機器每次載入它們時需要從apk中讀取classes.dex檔案，這樣會耗費很多cpu時間，而採用odex方式優化的dex檔案，已經包含了載入dex必須的依賴庫檔案列表，Dalvik虛擬機器只需檢測並載入所需的依賴庫即可執行相應的dex檔案，這大大縮短了讀取dex檔案所需的時間。

不過，這個優化過程會根據不同裝置上Dalvik虛擬機器的版本、Framework庫的不同等因素而不同。在一臺裝置上被優化過的ODEX檔案，拷貝到另一臺裝置上不一定能夠執行。

2.1、odex檔案結構

Odex檔案的結構可以理解為dex檔案的一個超集。它的結構如下圖所示，odex檔案在dex檔案頭部添加了一些資料，然後在dex檔案尾部添加了dex檔案的依賴庫以及一些輔助資料。

Dalvik虛擬機器將dex檔案對映到記憶體中後是Dalvik格式，在Android系統原始碼的dalvik/libdex/DexFile.h檔案中它的定義如下。

DexFile結構中存入的多為其他結構的指標。DexFile最前面的DexOptHeader就是odex的頭，DexLink以下的部分被成為auxillary section,即輔助資料段，它記錄了dex檔案被優化後新增的一些資訊。然而，DexFile結構描述的是載入進記憶體的資料結構，還有一些資料是不會載入進記憶體的，經過分析，odex檔案結構定義整理如下.

Struct ODEXFile{

           DexOptHeader             header;    /*odex檔案頭*/

           DEXFile                          dexfile;  /*dex檔案*/

           Dependences              deps;        /*依賴庫列表*/

           ChunkDexClassLookup    lookup;     /*類查詢結構*/

           ChunkRegisterMapPool          mappool; /*對映池*/

           ChunkEnd                            end;    /*結束標誌*/

};

2.2、odex檔案結構分析

         ODEXFile的檔案頭DexOptHeader在DexFile.h檔案中定義如下.

struct DexOptHeader{

         u1  magic[8];                  /*odex版本標識 */

         u4  dexOffset;            /* dex檔案頭偏移*/

         u4  dexLength;      /* dex檔案總長度*/

         u4  depsOffset;      /*odex依賴庫列表偏移*/

         u4  depsLength;     /*依賴庫列表總長度*/

         u4  optOffset;       /*輔助資料偏移*/

         u4  optLength;       /*輔助資料總長度*/

         u4  flags ;                          /*標誌*/

         u4  checksum;        /*依賴庫與輔助資料的校驗和*/

};

3、dex檔案的驗證與優化

Android提供了一個專門驗證與優化dex檔案的工具dexopt。其原始碼位於Android系統原始碼的dalvik/dexopt目錄下，Dalvik虛擬機器在載入一個dex檔案時，通過指定的驗證與優化選項來呼叫dexopt進行相應的驗證與優化操作。

         dexopt的主程式為OptMain.cpp，其中處理apk/jar/zip檔案中的classes.dex的函式為extractAndProcessZip(),extractAndProcessZip()首先通過dexZipFindEntry()函式檢查目標檔案中是否擁有class.dex，如果沒有就失敗返回，成功的話就呼叫dexZipGetEntryInfo()函式來讀取classes.dex的時間戳與crc校驗值，如果這一步沒有問題，接著呼叫dexZipExtractEntryTo-File()函式釋放classes.dex為快取檔案，然後開始解析傳遞過來的驗證與優化選項，驗證選項使用“v=”指出，優化選項使用“o=”指出。所有的預備工作都做完後，呼叫dvmPrepForDexOpt()函式啟動一個虛擬機器程序，在這個函式中，優化選項dexOptMode與驗證選項varifyMode被傳遞到了全域性DvmGlobals結構gDvm的dexOptMode與classVerifyMode欄位中。這時候所有的初始化工作已經完成，dexopt呼叫dvmContinueOptimization()函式開始真正的驗證和優化工作。

         dvmContinueOptimization()函式的呼叫鏈比較長。首先從OptMain.cpp轉移到、dalvik/vm/analysis/DexPrepare.cpp,因為這裡有dvmContinueOptimization()函式的實現。函式首先對dex檔案做簡單的檢查，確保傳遞進來的目標檔案屬於dex或odex,接著呼叫mmap()函式將整個檔案對映到記憶體中，然後根據gDvm的dexOptMode與classVerifyMode欄位來設定doVarify與doOpt兩個布林值，接著呼叫rewriteDex()函式來重寫dex檔案，這裡的重寫內容包括字元調整、結構重新對齊、類驗證資訊以及輔助資料。rewriteDex()函式呼叫dexSwapAndVerify()調整位元組序，接著呼叫dvmDexFileOpenPartial()建立DexFile結構，dvmDexFileOpenPartial()函式的實現在Android系統原始碼dalvik/vm/DvmDex.cpp檔案中，該函式呼叫dexFileParse()函式解析dex檔案，dexFileParse()函式讀取dex檔案的頭部，並根據需要呼叫驗證dexComputeChecksum()函式或呼叫dexComputeOptChecksum()函式來驗證dex或odex檔案愛你頭的checksum與signature欄位。

         接著回到DvmDex.cpp檔案繼續看程式碼，當驗證成功後，dvmDexFileOpenPartial()函式呼叫allocateAuxStructures()函式設定DexFile結構輔助資料的相關欄位，最後執行完後返回到rewriteDex()函式。rewriteDex()接下來呼叫loadAllClasses()載入dex檔案中所有的類，如果這一步失敗了，程式等不到後面的優化與驗證就退出了，如果沒有錯誤發生，會呼叫verifyAndOptimizeClasses()函式進行真正的驗證工作，這個函式會呼叫verifyAndOptimizeClass()函式來優化與驗證具體的類，而verifyAndOptimizeClass()函式會細分這些工作，呼叫dvmVerifyClass()函式進行驗證，再呼叫dvmOptimizeClass()函式進行優化。

         dvmVerifyClass()函式的實現程式碼位於Android系統原始碼的dalvik/vm/analysis/DexVerify.cpp檔案中。這個函式呼叫verifyMethod()函式對類的所有直接方法與虛方法進行驗證，verifyMethod()函式具體的工作是先呼叫verifyInstructions()函式來驗證方法中的指令及其資料的正確性，再呼叫dvmVerifyCodeFlow()函式來驗證程式碼流的正確性。

         dvmOptimizeClass()函式的實現程式碼位於Android系統原始碼的dalvik/vm/analysis/Optimize.cpp檔案愛你中。這個函式呼叫optimizeMethod()函式對類的所有直接方法與虛方法進行優化，優化的主要工作是進行“指令替換”，替換原則的優先順序為“volatile”替換-正確性替換-高效能替換。比如指令iget-wide會根據優先順序替換為“volatile”形式的iget-wide-volatile，而不是高效能的iget-wide-quick.

         rewriteDex函式返回後，會再次呼叫dvmDexFileOpenPartial()來驗證odex檔案，接著呼叫dvmGenerateRegisterMaps()函式來填充輔助資料區結構，填充結構完成後，接下來呼叫updateChecksum()函式重寫dex檔案愛你的checksum值，再往下就是writeDependencies()與writeOptData()了。

3.2 dex檔案優化載入流程圖