2020-10-27（dex文件解析）
一張圖搞懂dex
大圖這里
當然也可以通過下面的圖12 DexFile的文件格式，了解更清楚。
DEX文件詳解
什么是dex文件？
如何生成一個dex文件
dex文件的作用
dex文件格式詳解
什么是dex文件？
dex文件是Android系統中的一種文件，是一種特殊的數據格式，和APK、jar 等格式文件類似。
能夠被DVM識別，加載并執行的文件格式。
簡單說就是優化后的android版.exe。每個apk安裝包里都有。包含應用程序的全部操作指令以及運行時數據。
相對于PC上的java虛擬機能運行.class；android上的Davlik虛擬機能運行.dex。
當java程序編譯成class后，還需要使用dx工具將所有的class文件整合到一個dex文件，目的是其中各個類能夠共享數據，在一定程度上降低了冗余，同時也是文件結構更加經湊，實驗表明，dex文件是傳統jar文件大小的50%左右
圖2 apk中的dex文件
為何要研究dex格式？因為dex里面包含了所有app代碼，利用反編譯工具可以獲取java源碼。理解并修改dex文件，就能更好的apk破解和防破解。
使用dex文件的最大目的是實現安全管理，但在追求安全的前提下，一定要注意對dex文件實現優化處理。
注意：并不是只有Java才可以生成dex文件，C和C++也可以生成dex文件
如何生成一個dex文件？
通過IDE自動幫我們build生成
手動通過dx命令去生成dex文件
在待測試的class文件目錄下（我將TestMain.class放到了F盤根目錄下）,執行命令dx --dex --output TestMain.dex TestMain.class,就會生成TestMain.dex文件。
手動運行dex文件在手機
在待測試的dex文件目錄下（我將TestMain.class放到了F盤根目錄下），通過adb push TestMain.dex /storage/emulated/0命令，然后通過adb shell命令進入手機，后執行dalvikvm -cp /sdcard/TestMain.dex TestMain，就會打印出
Hello World!
如下圖3所示（使用AS的終端，沒有用Windows的cmd命令）
圖3 手動運行dex文件
注意：
環境變量的配置，dex在SDK目錄下的build-tools目錄下有很多版本，這里可以選擇最新版本目錄下dx.bat配置到環境變量path路徑下；同樣，adb命令也同樣配置。
運行完dex文件，可以通過exit退出手機，電腦本地盤符
查看dex文件
大圖這里
圖4 dex文件概貌
通過010Editor工具（圖片來自網絡）
大圖這里
圖5 注：圖片來自網絡
下圖6是TestMain.dex通過010Editor工具得到的
大圖這里
圖6 010Editor 檢測TestMain.dex結果
圖7是通過010Editor工具檢測TestMain.dex得到的 Template Result結果
大圖這里
圖7 010Editor檢測TemplateResult結果
通過dexdump 命令查看（注意）
利用build-tools 下的dexdump 命令查看，dexdump -d -l plain TestMain.dex，得到下面的結果
registers:Dalvik 最初目標是運行在以ARM 做CPU 的機器上的，ARM 芯片的一個主要特點是寄存器多。寄存器多的話有好處，就是可以把操作數放在寄存器里，而不是像傳統VM 一樣放在棧中。自然，操作寄存器是比操作內存（棧嘛，其實就是一塊內存區域）快。registers 變量表示該方法運行過程中會使用多少個寄存器。
ins：輸入參數對應的個數
outs：此函數內部調用其他函數，需要的參數個數。
insns size：以4 字節為單位，代表該函數字節碼的長度（類似Class 文件的code[]數組）
更多內容參考：官網介紹----->Dalvik 可執行文件格式
dex文件的作用
記錄整個工程中所有類的信息，記住的整個工程所有類的信息
dex文件格式詳解
一種8位字節的二進制流文件
各個數據按順序緊密的排列，無間隙
整個應用中所有的Java源文件都放在一個dex中
大圖這里
圖8 dex文件結構
上圖中的文件頭部分，記錄了dex文件的信息，所有字段大致的一個分部；索引區部分，主要包含字符串、類型、方法原型、域、方法的索引；索引區最終又被存儲在數據區，其中鏈接數據區，主要存儲動態鏈接庫，so庫的信息。
源碼：/dalvik/libdex/DexFile.h:DexFile
struct DexFile {/* directly-mapped "opt" header */const DexOptHeader* pOptHeader;/* pointers to directly-mapped structs and arrays in base DEX */const DexHeader* pHeader;const DexStringId* pStringIds;const DexTypeId* pTypeIds;const DexFieldId* pFieldIds;const DexMethodId* pMethodIds;const DexProtoId* pProtoIds;const DexClassDef* pClassDefs;const DexLink* pLinkData; };具體可查看Android源碼官網的關于dex文件結構的詳解，如下圖9（大圖這里）
圖9 dex文件結構詳解
總結：
數據名稱 解釋
header dex 文件頭部，記錄整個dex文件的相關屬性
string_ids 字符串數據索引，記錄了每個字符串在數據區的偏移量
type_ids
| header dex | 文件頭部，記錄整個dex文件的相關屬性 |
| string_ids | 字符串數據索引，記錄了每個字符串在數據區的偏移量 |
| type_ids | 類似數據索引，記錄了每個類型的字符串索引 |
| proto_ids | 原型數據索引，記錄了方法聲明的字符串，返回類型字符串，參數列表 |
| field_ids | 字段數據索引，記錄了所屬類，類型以及方法名 |
| method_ids | 類方法索引，記錄方法所屬類名，方法聲明以及方法名等信息 |
| class_defs | 類定義數據索引，記錄指定類各類信息，包括接口，超類，類數據偏移量 |
| data | 數據區，保存了各個類的真是數據 |
| link_data | 連接數據區 |
DEX 文件中會出現的數據類型
類型 含義
u1 等同于uint8_t，表示 1 字節的無符號 數
u2 等同于 uint16_t，表示 2 字節的無符號數
u4 等同于 uint32_t，表示 4 字節的無符號數
u8 等同于 uint64_t，表示 8 字節的無符號數
sleb128 有符號 LEB128，可變長度 1~5 字節
uleb128 無符號 LEB128，可變長度 1~5 字節
uleb128p1 無符號 LEB128 值加1，可變長 1~5 字節
/dalvik/libdex/DexFile.h中定義如下
typedef uint8_t u1;
typedef uint16_t u2;
typedef uint32_t u4;
typedef uint64_t u8;
typedef int8_t s1;
typedef int16_t s2;
typedef int32_t s4;
typedef int64_t s8;
LEB128
LEB128（“Little-Endian Base 128”）表示任意有符號或無符號整數的可變長度編碼。該格式借鑒了 DWARF3 規范。在 .dex 文件中，LEB128 僅用于對 32 位數字進行編碼。
每個 LEB128 編碼值均由 1-5 個字節組成，共同表示一個 32 位的值。每個字節均已設置其最高有效位（序列中的最后一個字節除外，其最高有效位已清除）。每個字節的剩余 7 位均為有效負荷，即第一個字節中有 7 個最低有效位，第二個字節中也是 7 個，依此類推。對于有符號 LEB128 (sleb128)，序列中最后一個字節的最高有效負荷位會進行符號擴展，以生成最終值。在無符號情況 (uleb128) 下，任何未明確表示的位都會被解譯為 0。
大圖這里
圖10 雙字節 LEB128 值的按位圖
變量 uleb128p1 用于表示一個有符號值，其表示法是編碼為 uleb128 的值加 1。這使得編碼 -1（或被視為無符號值 0xffffffff）成為一個單字節（但沒有任何其他負數），并且該編碼在下面這些明確說明的情況下非常實用：所表示的數值必須為非負數或 -1（或 0xffffffff）；不允許任何其他負值（或不太可能需要使用較大的無符號值）。
以下是這類格式的一些示例：
編碼序列 As sleb128 As uleb128 As uleb128p1
00 0 0 -1
01 1 1 0
7f -1 127 126
80 7f -128 16256
dex文件頭
Dex文件頭主要包括校驗和以及其他結構的偏移地址和長度信息。
源碼位于 /dalvik/libdex/DexFile.h:DexHeader
具體詳解如下圖5所示
大圖這里
圖11 dex文件頭信息
各個字段詳解摘要
mapOff 字段
指定 DexMapList 結構距離 Dex 頭的偏移
DexMapList 結構體：
struct DexMapList
{
u4 size; // DexMapItem 的個數
DexMapItem list[1]; // DexMapItem 結構
};
size：表示接下來有多少個 DexMapItem
list：是一個 DexMapItem 結構體數組
DexMapItem 結構體：
struct DexMapItem
{
u2 type; // kDexType 開頭的類型
u2 unused; // 未使用，用于對齊
u4 size; // 指定類型的個數
u4 offset; // 指定類型數據的文件偏移
};
type：一個枚舉常量
enum
{
kDexTypeHeaderItem = 0x0000, // 對應 DexHeader
kDexTypeStringIdItem = 0x0001, // 對應 stringIdsSize 與 stringIdsOff 字段
kDexTypeTypeIdItem = 0x0002, // 對應 typeIdsSize 與 typeIdsOff 字段
kDexTypeProtoIdItem = 0x0003, // 對應 protoIdsSize 與 protoIdsOff 字段
kDexTypeFieldIdItem = 0x0004, // 對應 fieldIdsSize 與 fieldIdsOff 字段
kDexTypeMethodIdItem = 0x0005, // 對應 methodIdsSize 與 methodIdsOff 字段
kDexTypeClassDefItem = 0x0006, // 對應 classDefsSize 與 classDefsOff 字段
kDexTypeMapList = 0x1000,
kDexTypeTypeList = 0x1001,
kDexTypeAnnotationSetRefList = 0x1002,
kDexTypeAnnotationSetItem = 0x1003,
kDexTypeClassDataItem = 0x2000,
kDexTypeCodeItem = 0x2001,
kDexTypeStringDataItem = 0x2002,
kDexTypeDebugInfoItem = 0x2003,
kDexTypeAnnotationItem = 0x2004,
kDexTypeEncodeArrayItem = 0x2005,
kDexTypeAnnotationsDirectoryItem = 0x2006
};
size：指定類型的個數
offset：指定類型數據的偏移
DexStringId 結構體（stringIdsSize 與 stringIdsOff 字段）
typedef struct _DexStringId
{
u4 stringDataOff; // 指向 MUTF-8 字符串的偏移
}DexStringId, *PDexStringId;
MUTF-8 編碼：
使用 1~3 字節編碼長度
大于 16 位的 Unicode 編碼 U+10000~U+10FFFF 使用 3 字節來編碼
U+0000 采用 2 字節編碼
采用空字符 null 作為結尾
第一個字節存放字節個數（不包含自已）
DexTypeId 結構體（typeIdsSize 與 typeIdsOff 字段）
是一個類型結構體
typedef struct _DexTypeId
{
u4 descriptorIdx; // 指向 DexStringId 列表的索引
}DexTypeId, *PDexTypeId;
descriptorIdx：指向 DexStringId 列表的索引，它對應的字符串代表了具體類的類型
DexProtoId 結構體（protoIdsSize 與 protoIdsOff 字段）
是一個方法聲明結構體，方法聲明 = 返回類型 + 參數列表
typedef struct _DexProtoId
{
u4 shortyIdx; // 方法聲明字符串，指向 DexStringId 列表的索引
u4 returnTypeIdx; // 方法返回類型字符串，指向 DexStringId 列表的索引
u4 parametersOff; // 方法的參數列表，指向 DexTypeList 結構體的偏移
}DexProtoId, *PDexProtoId;
shortyIdx：方法聲明字符串，方法聲明 = 返回類型 + 參數列表
returnTypeIdx：方法返回類型字符串
parametersOff：指向一個 DexTypeList 結構體，存放了方法的參數列表
DexTypeList 結構體：
typedef struct _DexTypeList
{
u4 size; // 接下來 DexTypeItem 的個數
DexTypeItem* list; // DexTypeItem 結構
}DexTypeList, *PDexTypeList;
size：接下來 DexTypeItem 的個數
list：是一個 DexTypeItem 結構體數組
DexTypeItem 結構體：
typedef struct _DexTypeItem
{
u2 typeIdx; // 指向 DexTypeId 列表的索引
}DexTypeItem, *PDexTypeItem;
typeIdx：DexTypeId 列表的索引
DexFieldId 結構體（fieldIdsSize 與 fieldIdsOff 字段）
指明了字段所有的類、字段的類型以及字段名
typedef struct _DexFieldId
{
u2 classIdx; // 類的類型，指向 DexTypeId 列表的索引
u2 typeIdx; // 字段的類型，指向 DexTypeId 列表的索引
u4 nameIdx; // 字段名，指向 DexStringId 列表的索引
}DexFieldId, *PDexFieldId;
classIdx：類的類型
typeIdx：字段的類型
nameIdx：字段名
DexMethodId 結構體（methodIdsSize 與 methodIdsOff 字段）
方法結構體
typedef struct _DexMethodId
{
u2 classIdx; // 類的類型，指向 DexTypeId 列表的索引
u2 protoIdx; // 聲明的類型，指向 DexProtoId 列表的索引
u4 nameIdx; // 方法名，指向 DexStringId 列表的索引
}DexMethodId, *PDexMethodId;
classIdx：類的類型
protoIdx：聲明的類型
nameIdx：方法名
DexClassDef 結構體（classDefsSize 和 classDefsOff 字段）
類結構體
typedef struct _DexClassDef
{
u4 classIdx; // 類的類型，指向 DexTypeId 列表的索引
u4 accessFlags; // 訪問標志
u4 superclassIdx; // 父類類型，指向 DexTypeId 列表的索引
u4 interfacesOff; // 接口，指向 DexTypeList 的偏移，否則為0
u4 sourceFileIdx; // 源文件名，指向 DexStringId 列表的索引
u4 annotationsOff; // 注解，指向 DexAnnotationsDirectoryItem 結構，或者為 0
u4 classDataOff; // 指向 DexClassData 結構的偏移，類的數據部分
u4 staticValuesOff; // 指向 DexEncodedArray 結構的偏移，記錄了類中的靜態數據，主要是靜態方法
}DexClassDef, *PDexClassDef;
classIdx：類的類型，指向 DexTypeId 列表的索引
accessFlags：訪問標志，它是以ACC_開頭的枚舉值
superclassIdx：父類類型，指向 DexTypeId 列表的索引
interfacesOff：接口，指向 DexTypeList 的偏移，如果沒有，則為 0
sourceFileIdx：源文件名，指向 DexStringId 列表的索引
annotationsOff：注解，指向 DexAnnotationsDirectoryItem 結構，或者為 0
classDataOff：指向 DexClassData 結構的偏移，類的數據部分
staticValuesOff：指向 DexEncodeArray 結構的偏移，記錄了類中的靜態數據，沒有則為 0
DexClassData 結構體：
typedef struct _DexClassData
{
DexClassDataHeader header; // 指定字段與方法的個數
DexField* staticFields; // 靜態字段，DexField 結構
DexField* instanceFields; // 實例字段，DexField 結構
DexMethod* directMethods; // 直接方法，DexMethod 結構
DexMethod* virtualMethods; // 虛方法，DexMethod 結構
}DexClassData, *PDexClassData;
header：DexClassDataHeader 結構體，指定字段與方法的個數
staticFields：靜態字段，DexField 結構體數組
instanceFields：實例字段，DexField 結構體數組
directMethods：直接方法，DexMthod 結構體數組
virtualMethods：虛方法，DexMethod 結構體數組
DexClassDataHeader 結構體：
typedef struct _DexClassDataHeader
{
uleb128 staticFieldsSize; // 靜態字段個數
uleb128 instanceFieldsSize; // 實例字段個數
uleb128 directMethodsSize; // 直接方法個數
uleb128 virtualMethodsSize; // 虛方法個數
}DexClassDataHeader, *PDexClassDataHeader;
staticFieldsSize：靜態字段個數
instanceFieldsSize：實例字段個數
directMethodsSize：直接方法個數
virtualMethodsSize：虛方法個數
DexField 結構體：
typedef struct _DexField
{
uleb128 fieldIdx; // 指向 DexFieldId 的索引
uleb128 accessFlags; // 訪問標志
}DexField, *PDexField;
fieldIdx：字段描述，指向 DexFieldId 的索引
accessFlags：訪問標志
DexMethod 結構體：
typedef struct _DexMethod
{
uleb128 methodIdx; // 指向 DexMethodId 的索引
uleb128 accessFlags; // 訪問標志
uleb128 codeOff; // 指向 DexCode 結構的偏移
}DexMethod, *PDexMethod;
methodIdx：方法描述，指向 DexMethodId 的索引
accessFlags：訪問標志
codeOff：指向 DexCode 結構的偏移
DexCode 結構體：
typedef struct _DexCode
{
u2 registersSize; // 使用的寄存器個數
u2 insSize; // 參數個數
u2 outsSize; // 調用其他方法時使用的寄存器個數
u2 triesSize; // Try/Catch 個數
u4 debbugInfoOff; // 指向調試信息的偏移
u4 insnsSize; // 指令集個數，以 2 字節為單位
u2* insns; // 指令集
}DexCode, *PDexCode;
還有一些不太常見的結構體，要用的時候再去看看就行了。Dex 文件的整體結構就這樣，就是一個多層索引的結構。
string_ids（字符串索引）
這一區域存儲的是Dex文件字符串資源的索引信息，該索引信息是目標字符串在Dex文件數據區所在的真實物理偏移量。
源碼位于 /dalvik/libdex/DexFile.h:DexStringId
struct DexStringId {
u4 stringDataOff; /* file offset to string_data_item */
};
stringDataOff記錄了目標字符串在Dex文件中的實際偏移量，虛擬機想讀取該字符串時，只需將Dex文件在內存中的起始地址加上stringDataOff所指的偏移量，就是該字符串在內存中的實際物理地址。
在Dex文件中，每個每個字符串對應一個DexStringId,大小4B。另外虛擬機通過DexHeader中的String_ids_size獲得當前Dex文件中的字符串的總數,通過乘法就可對該索引資源進行訪問。
DexLink
struct DexLink {
u1 bleargh;
};
DexFile 在內存中的映射
在Android系統中， java 源文件會被編譯為“ .jar ” 格式的dex類型文件， 在代碼中稱為dexfile 。在加載Class 之前， 必先讀取相應的jar文件。通常我們使用read（）函數來讀取文件中的內容。但在Dalvik中使用mmap（） 函數。和read（）不同， mmap（）函數會將dex文件映射到內存中，這樣通過普通的內存讀取操作即可訪問dexfile中的內容。
Dexfile的文件格式如圖12 所示， 主要有三部分組成：頭部，索引，數據。通過頭部可知索引的位置和數同，可知數據區的起始位置。其中classDefsOff 指定了ClassDef 在文件的起始位置， dataOff 指定了數據在文件的起始位置， ClassDef 即可理解為Class 的索引。通過讀取ClassDef 可獲知Class 的基本信息，其中classDataOff 指定了Class 數據在數據區的位置。
大圖這里
圖12 DexFile的文件格式
在將dexfile文件映射到內存后，會調用dexFileParse（）函數對其分析，分析的結果存放于名為DexFile的數據結構中。DexFile 中的baseAddr指向映射區的起始位置， pClassDefs 指向ClassDefs（即class索引）的起始位置。由于在查找class 時，都是使用class的名字進行查找的，所以為了加快查找速度， 創建了一個hash表。在hash表中對class 名字進行hash，并生成index。這些操作都是在對文件解析時所完成的，這樣雖然在加載過程中比較耗時，但是在運行過程中可節省大量查找時間。
解析完后， 接下來開始加載class文件。在此需要將加載類用ClassObject來保存，所以在此需要先分析和ClassObject 相關的幾個數據結構。
首先在文件Object.h 中可以看到如下對結構體Object 的定義。（android2.3.7源碼）
typedef struct Object {
/* ptr to class object /
ClassObject clazz;
} Object;
通過結構體Object定義了基本類的實現，這里有如下兩個變量。
lock ： 對應Obejct 對象中的鎖實現，即notify wait 的處理。
clazz ： 是結構體指針，姑且不看結構體內容，這里用了指針的定義。
下面會有更多的結構體定義：
struct DataObject {
Object obj; /* MUST be first item /
/ variable #of u4 slots; u8 uses 2 slots /
u4 instanceData[1];
};
struct StringObject {
Object obj; / MUST be first item /
/ variable #of u4 slots; u8 uses 2 slots */
u4 instanceData[1];
};
我們看到最熟悉的一個詞StringObject ，把這個結構體展開后是下面的樣子。
struct StringObject {
/* ptr t o class object /
ClassObject clazz ;
/* variable #of u4 slots; u8 uses 2 slots */
u4 lock;
u4 instanceData[1];
};
由此不難發現， 任何對象的內存結構體中第一行都是Object結構體，而這個結構體第一個總是一個ClassObejct，第二個總是lock 。按照C++中的技巧，這些結構體可以當成Object結構體使用，因此所有的類在內存中都具有“對象”的功能，即可以找到一個類（ClassObject），可以有一個鎖(lock） 。
StringObject是對String類進行管理的數據對象，ArrayObejct是數據相關的管理。
ClassObject-Class 在加載后的表現形式
在解析完文件后， 接下來需要加載Class 的具體內容。在Dalvik中， 由數據結構ClassObject負責存放加載的信息。如圖13所示，加載過程會在內存中alloc幾個區域，分別存放directMethods 、virtualMethods 、sfields 、ifields 。這些信息是從dex 文件的數據區中讀取的，首先會讀取Class 的詳細信息，從中獲得directMethod 、virtua!Method 、sfield 、ifield 等的信息，然后再讀取。在此需要注意， 在C lassObj ect 結構中有個名為super 的成員，通過super成員可以指向它的超類。
大圖這里
圖13 加載過程
Android dex 文件優化
對Android dex 文件進行優化來說， 需要注意的一點是dex文件的結構是緊湊的，但是我們還是要想方設法地進行提高程序的運行速度，我們就仍然需要對dex文件進行進一步優化。
調整所有字段的字節序（ LITTLE_ENDIAN），和對齊結構中的每一個域來驗證dex文件中的所有類，并對一些特定的類進行優化或對方法里的操作碼進行優化。優化后的文件大小會有所增加， 大約是原Android dex文件的1～4 倍。
優化時機
優化發生的時機有兩個：
對于預置應用來說，可以在系統編譯后，生成優化文件，以ODEX 結尾。這樣在發布時除APK文件（不包含dex）以外，還有一個相應的Android dex 文件。
對于非預置應用， 包含在APK文件里的dex 文件會在運行時被優化，優化后的文件將被保存在緩存中。
如下圖14所示代碼調用流程
圖14 代碼調用流程
每一個Android應用都運行在一個Dalvik虛擬機實例里，而每一個虛擬機實例都是一個獨立的進程空間。虛擬機的線程機制，內存分配和管理， Mutex等都是依賴底層操作系統而實現的。
所有Android應用的線程都對應一個Linux線程（可參考----理解Android線程創建流程），虛擬機因而可以更多地依賴操作系統的線程調度和管理機制。不同的應用在不同的進程空間里運行，加之對不同來源的應用都使用不同的Linux用戶來運行，可以最大限度地保護應用的安全和獨立運行。
Zygote是一個虛擬機進程，同時也是一個虛擬機實例的孵化器，每當系統要求執行一個Android應用程序，Zygote就會孵化出一個子進程來執行該應用程序。這樣做的好處顯而易見：Zygote進程是在系統啟動時產生的，它會完成虛擬機的初始化，庫的載，預置類庫的加載和初始化等操作，而在系統需要一個新的虛擬機實例時，Zygote通過復制自身，最快速地提供一個虛擬機實例。另外，對于一些只讀的系統庫，所有虛擬機實例都和Zygote 共享一塊內存區域，大大節省了內存開銷。
Android 應用所使用的編程語言是Java語言，和Java SE 一樣，編譯時使用Oracle JDK 將Java源程序編程成標準的Java 字節碼文件（. class 文件）。而后通過工具軟件DX 把所有的字節碼文件轉成Android dex 文件（classes . dex） 。最后使用Android 打包工具（aapt）將dex 文件、資源文件以及AndroidManifest.xml 文件（二進制格式）組合成一個應用程序包（APK） 。應用程序包可以被發布到手機上運行。
圖15 Android應用編譯及運行流程
odex 介紹
odex 是Optimized dex 的簡寫，也就是優化后的dex 文件。為什么要優化呢？主要還是為了提高Dalvik 虛擬機的運行速度。但是odex 不是簡單的、通用的優化，而是在其優化過程中，依賴系統已經編譯好的其他模塊，簡單點說：
從Class 文件到dex 文件是針對Android 平臺的一種優化，是一種通用的優化。優化過程中，唯一的輸入是Class 文件。
odex 文件就是dex 文件具體在某個系統（不同手機，不同手機的OS，不同版本的OS 等）上的優化。odex 文件的優化依賴系統上的幾個核心模塊（ 由BOOTCLASSPATH 環境變量給出， 一般是/system/framework/下的jar 包，尤其是core.jar）。odex 的優化就好像是把中那些本來需要在執行過程中做的類校驗、調用其他類函數時的解析等工作給提前處理了。
通過利用dexopt得到test.odex，接著利用dexdump得到其內容，最后可以利用Beyond Compare比較這兩個文件的差異。
如下圖所示
圖16 test.dex 和test.odex 差異
圖16中，綠色框中是test.dex的內容，紅色框中是test.odex的內容，這也是兩個文件的差異內容：
test.dex中，TestMain類僅僅是PUBLIC的，但test.odex則增加了VERIFIED和OPTIMIZED兩項。VERIFIED是表示該類被校驗過了，至于校驗什么東西，以后再說。
然后就是一些方法的不同了。優化后的odex文件，一些字節碼指令變成了xxx-quick。比如圖中最后一句代碼對于的字節碼中，未優化前invoke-virtual指令表示從method table指定項（圖中是0002）里找到目標函數，而優化后的odex使用了invoke-virtual-quick表示從vtable中找到目標函數（圖中是000b）。
vtable是虛表的意思，一般在OOP實現中用得很多。vtable一定比methodtable快么？那倒是有可能。我個人猜測：
method表應該是每個dex文件獨有的，即它是基于dex文件的。
根據odex文件的生成方法（后面會講），我覺得vtable恐怕是把dex文件及依賴的類（比如Java基礎類，如Object類等）放一起進行了處理，最終得到一張大的vtable。這個odex文件依賴的一些函數都放在vtable中。運行時直接調用指定位置的函數就好，不需要再解析了。以上僅是我的猜測。
注意：
odex文件由dexopt生成，這個工具在SDK里沒有，只能由源碼生成。odex文件的生成有三種方式：
preopt：即OEM廠商（比如手機廠商），在制作鏡像的時候，就把那些需要放到鏡像文件里的jar包，APK等預先生成對應的odex文件，然后再把classes.dex文件從jar包和APK中去掉以節省文件體積。
installd：當一個apk安裝的時候，PackageManagerService會調用installd的服務，將apk中的class.dex進行處理。當然，這種情況下，APK中的class.dex不會被剔除。
dalvik VM：preopt是廠商的行為，可做可不做。如果沒有做的話，dalvik VM在加載一個dex文件的時候，會先生成odex。所以，dalvik VM實際上用得是odex文件。以后我們研究dalvik VM的時候會看到這部分內容。
實際上dex轉odex是利用了dalvik vm，里邊也會運行dalvik vm的相關方法。
總結：
以標準角度來看，Class文件是由Java VM規范定義的，所以通用性更廣。dex或者是odex只不過是規范在Android平臺上的一種具體實現罷了，而且dex/odex在很多地方也需要遵守規范。因為dex文件的來源其實還是Class文件。
對于初學者而言，我建議了解Class文件的結構為主。另外，關于dex/odex的文件結構，除非有明確需求（比如要自己修改字節碼等），否則以了解原理就可以。而且，將來我們看到dalvik vm的實際代碼后，你會發現dex的文件內容還是會轉換成代碼里的那些你很熟悉的類型，數據結構。比如dex存儲字符串是一種優化后的方法，但是到vm代碼中，還不是只能用字符串來表示嗎？
另外，你還會發現，Class、dex還是odex文件都存儲了很多源碼中的信息，比如類名、函數名、參數信息、成員變量信息等，而且直接用得是字符串。這和Native的二進制比起來，就容易看懂多了。
參考鏈接
深入理解Android之Java虛擬機Dalvik
Androidsource之Dalvik 字節碼
Androidsource之Dalvik 可執行文件格式（dex文件）
Android安全–Dex文件格式詳解
詳細描述了dex/odex指令的格式----->Dalvik opcodes
解釋器中對 標號 的使用
A deep dive into DEX file format
Dex文件格式詳解
android中Dex文件結構詳解
Dex文件及Dalvik字節碼格式解析
Dex 文件格式詳解
Dex文件格式詳解
Android關于Dex拆分(MultiDex)技術詳解
總結
以上是生活随笔為你收集整理的2020-10-27（dex文件解析）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2020-10-30（smali复杂类解
- 下一篇： 2020-10-30（APK-逆向2）