ODEX格式及生成過程

Apk在安裝(installer)時,就會進行驗證和優化,目的是為了校驗代碼合法性及優化代碼執行速度,參見Dalvik Optimization and Verification Withdexopt。

驗證和優化后,會產生ODEX文件,運行Apk的時候,直接加載ODEX,避免重復驗證和優化,加快了Apk的響應時間。

先來看一張ODEX文件的結構圖:

ODEX文件的結構圖

下面將圍繞這張圖,結合dexopt的代碼,說明ODEX的生成過程。

一. 首先將一個空的DexOptHeader寫入ODEX文件

dexOptCreateEmptyHeader(cacheFd)

二. 從Apk中提取classes.dex,追加到ODEX文件

dexZipExtractEntryToFile(&zippy, zipEntry, cacheFd)

此時文件結構是這樣的:

三. 修改Dex內容

rewriteDex(((u1*) mapAddr) + dexOffset, dexLength, doVerify, doOpt, &pClassLookup, NULL)

這一步是驗證和優化的核心,具體見:

verifyAndOptimizeClasses(pDvmDex->pDexFile, doVerify, doOpt)... verifyAndOptimizeClass(pDexFile, clazz, pClassDef, doVerify, doOpt)...dvmVerifyClass(clazz)...dvmOptimizeClass(clazz, false)

其中dvmVerifyClass和dvmOptimizeClass都是針對類中的方法,具體做了哪些事情參考源碼。

四. 因為3修改了Dex內容,所以要重新計算Dex的checksum

updateChecksum(dexAddr, dexLength, pHeader)

五. 往ODEX文件后面追加Dependenices內容

writeDependencies(fd, modWhen, crc)

所謂的Dependenicies,是指Dex文件之間的依賴,比如App會依賴于framework的Dex。當framework的Dex發生變化時,App的ODEX文件將失效,需要重新生成。 writeDependencies中將bootclasspath下的dex文件都加入到依賴中。 此時文件結構是這樣的:

六. 將優化的其他內容追加到ODEX文件

writeOptData(fd, pClassLookup, pRegMapBuilder)

其中按照不同類型的內容,分為三個chunk寫入:

writeChunk(fd, (u4) kDexChunkClassLookup, pClassLookup, pClassLookup->size)writeChunk(fd, (u4) kDexChunkRegisterMaps,  pRegMapBuilder->data, pRegMapBuilder->size)writeChunk(fd, (u4) kDexChunkEnd, NULL, 0)

此時的文件結構是這樣的:

其中:

dexCreateClassLookup(pDvmDex->pDexFile)

此處根據Dex生成了pClassLookup,pClassLookup你可以簡單理解為一張hash表,里面保存了classDescriptor到classDef的映射。

dvmGenerateRegisterMaps(pDvmDex)

此處根據DvmDex生成了RegisterMaps,RegisterMaps的作用是為了標記方法中寄存器引用的對象,在快速GC時,不會釋放這些對象。具體參考Dalvik虛擬機中RegisterMap結構解析

七. 根據所有的內容,改寫第一步中DexOptHeader的相關字段值。

至此,ODEX文件完整生成。

參考資料:

1. Dalvik Optimization and Verification Withdexopt
2. Android系統ODEX文件格式解析
3. Dalvik虛擬機中RegisterMap結構解析