大家好，欢迎来到IT知识分享网。

odex是OptimizedDEX的缩写，是优化过的dex文件

odex两种存在方式:

1． 从apk程序中提取，和apk文件放在一起，后缀 odex，此类文件多是AndroidRom系统文件

2． 在cache/dalvik-cache缓存文件，后缀 dex

a)      Eg：system@app@calcuator.apk@classes.dex 安装在/system/app目录下calcuator.apk程序的odex文件

odex作用：

因为Dalvik每次加载从apk中读取classes.dex文件会消耗cpu时间，odex则已经包含了需要加载的库文件列表，Dalvik虚拟机加载时根据需要加载的库对照dex文件即可。

部分Android系统的ROM将系统odex文件与app放在同一目录，系统在启动加载这些程序会更省时间。

 

一、生成odex文件：

使用Android系统源码工具生成dex

将build/tools/dexpreopt/dexopt-wrapper下的dexopt-wrapper拷入真机adb push命令

给予777权限，将需要生成dex文件拷入到手机cd跳转该目录执行如下命令

adb pull将文件拷出得到odex文件，文件位置默认为此时cmd的路径位置

 

分析odex文件：

文件结构体

Dalvik虚拟机将dex文件映射到内存后

500struct DexFile {

501    /* directly-mapped "opt" header */

502    const DexOptHeader* pOptHeader;          // odex文件头

503

504    /* pointers to directly-mapped structs and arrays in base DEX */

505    const DexHeader*    pHeader;                        

506    const DexStringId*  pStringIds;

507    const DexTypeId*    pTypeIds;

508    const DexFieldId*   pFieldIds;

509    const DexMethodId*  pMethodIds;

510    const DexProtoId*   pProtoIds;

511    const DexClassDef*  pClassDefs;

512    const DexLink*      pLinkData;

513

514    /*

515     * 辅助数据段,记录文件被优化后添加的一些信息

517     */

518    const DexClassLookup* pClassLookup;

519    const void*         pRegisterMapPool;       // RegisterMapClassPool

520

521    /* points to start of DEX file data */

522    const u1*           baseAddr;

523

524    /* track memory overhead for auxillary structures */

525    int                 overhead;

526

527    /* additional app-specific data structures associated with the DEX */

528    //void*               auxData;

529};

DexFile结构中存入其他结构的指针，描述的是加载到内存的数据结构，还有些数据是不会加载到内存的

odex文件结构

struct ODEXFile{

       DexOptHeader  header;// odex文件头

       DEXFile dexfile;// dex文件

       Dependence  deps；//依赖库列表

       ChunkDexClassLoopup       lookup；// 类查询结构

       ChunkRegisterMapPool  mappool；// 映射池

       ChunkEnd     end；// 结束标志

}

 

二、odex文件解析
       DexOptHeader在DexFile.h文件中466/*

467 * Header added by DEX optimization pass.  Values are always written in

468 * local byte and structure padding.  The first field (magic + version)

469 * is guaranteed to be present and directly readable for all expected

470 * compiler configurations; the rest is version-dependent.

471 *

472 * Try to keep this simple and fixed-size.

473 */

474struct DexOptHeader {

475    u1  magic[8];           /* odex版本标示 目前固定“64 65 79 0A 30 33 36 00” dey 036 */

476

477    u4  dexOffset;          /* dex文件头偏移 目前固定为“28 00 00 00”*/

478    u4  dexLength;          /* dex文件总长度 */

479    u4  depsOffset;         /* odex依赖库列表偏移 */

480    u4  depsLength;         /* 依赖库列表总长度 */

481    u4  optOffset;          /* 辅助数据偏移 */

482    u4  optLength;         /* 辅助数据总长度 */

483

484    u4  flags;              /* 标志，标识了Dalvik虚拟机加载odex时的优化与验证选项 */

485    u4  checksum;           /* 依赖库与辅助数据的校验和*/

486

487    /* pad for 64-bit alignment if necessary */

488};

        DexOptheader结构以下为DEXFile。

        DEXFile下为Dependences结构，Dependences结构不会加载到内存，并且Android源码没有明确定义。

整理出来的结构

struct DexOptHeader{

        u4 modWhen;            // 时间戳

        u4 crc;        // 校验

        u4 DALVIK_VM_BUILD;            // Dalvik虚拟机版本号

        u4 numDeps;            // 依赖库的个数

        struct{ 

               u4 len;        // name字符串长度

               u1 name[len];  // 依赖库的名称，依赖库的完整路径

               kSHA1DigestLen signature;      // SHA-1 哈希值

        }table[numDeps];       // numDeps决定了table连续的个数

};

        Dependences结构的具体操作函数位置 dalvik\vm\analysis\DexPrepare.cpp 中的writeDependencies()1358/*

1359 * Write the dependency info to "fd" at the current file position.

1360 */

1361static int writeDependencies(int fd, u4 modWhen, u4 crc)

1362{

1363    u1* buf = NULL;

1364    int result = -1;

1365    ssize_t bufLen;

1366    ClassPathEntry* cpe;

1367    int numDeps;

1368

1369    /*

1370     * Count up the number of completed entries in the bootclasspath.

1371     */

1372    numDeps = 0;

1373    bufLen = 0;

1374    for (cpe = gDvm.bootClassPath; cpe->ptr != NULL; cpe++) {

1375        const char* cacheFileName =

1376            dvmPathToAbsolutePortion(getCacheFileName(cpe));

1377        assert(cacheFileName != NULL); /* guaranteed by Class.c */

1378

1379        ALOGV("+++ DexOpt: found dep '%s'", cacheFileName);

1380

1381        numDeps++;

1382        bufLen += strlen(cacheFileName) +1;

1383    }

1384

1385    bufLen += 4*4 + numDeps * (4+kSHA1DigestLen);

1386

1387    buf = (u1*)malloc(bufLen);

1388

1389    set4LE(buf+0, modWhen);              // 写入时间戳                  注意：modWhenhe和crc通过

1390    set4LE(buf+4, crc);                  // 写入crc校验         dexZipGetEntryInfo()获取的     

1391    set4LE(buf+8, DALVIK_VM_BUILD);      // 写入Dalvik虚拟机版本号

1392    set4LE(buf+12, numDeps);             // 写入依赖库的个数

1393

1394    // TODO: do we want to add dvmGetInlineOpsTableLength() here?  Won't

1395    // help us if somebody replaces an existing entry, but it'd catch

1396    // additions/removals.

1397

1398    u1* ptr = buf + 4*4;                 // 跳过前四个字段

1399    for (cpe = gDvm.bootClassPath; cpe->ptr != NULL; cpe++) {           // 循环写入依赖库

1400        const char* cacheFileName =

1401            dvmPathToAbsolutePortion(getCacheFileName(cpe));

1402        assert(cacheFileName != NULL); /* guaranteed by Class.c */

1403

1404        const u1* signature = getSignature(cpe);      // 计算SHA-1 哈希值

1405        int len = strlen(cacheFileName) +1;

1406

1407        if (ptr + 4 + len + kSHA1DigestLen > buf + bufLen) {

1408            ALOGE("DexOpt: overran buffer");

1409            dvmAbort();

1410        }

1411

1412        set4LE(ptr, len);

1413        ptr += 4;

1414        memcpy(ptr, cacheFileName, len);         // 写入依赖库的名字

1415        ptr += len;

1416        memcpy(ptr, signature, kSHA1DigestLen);          // 写入SHA-1哈希值

1417        ptr += kSHA1DigestLen;

1418    }

1419

1420    assert(ptr == buf + bufLen);

1421

1422    result = sysWriteFully(fd, buf, bufLen, "DexOpt dep info");

1423

1424    free(buf);

1425    return result;

1426}

    dexZipGetEntryInfo()函数位于 /dalvik/libdex/ZipArchive.cpp       根据结构体分析二进制即可

       Dalvik版本号：Android2.2.3            19

                             Android2.3~2.3.7 23   

                             Android4.0~4.1          27

    Dependences结构下有3个Chunk块。由/dalvik/vm/analysis/DexPrepare.cpp中的writeOptData()写入1474

1475 * Write opt data.

1476 *

1477 * We have different pieces, some of which may be optional.  To make the

1478 * most effective use of space, we use a "chunk" format, with a 4-byte

1479 * type and a 4-byte length.  We guarantee 64-bit alignment for the data,

1480 * so it can be used directly when the file is mapped for reading.

1481 */

1482static bool writeOptData(int fd, const DexClassLookup* pClassLookup,

1483    const RegisterMapBuilder* pRegMapBuilder)

1484{

1485    /* pre-computed class lookup hash table */

1486    if (!writeChunk(fd, (u4) kDexChunkClassLookup,

1487            pClassLookup, pClassLookup->size))

1488    {

1489        return false;

1490    }

1491

1492    /* register maps (optional) */

1493    if (pRegMapBuilder != NULL) {

1494        if (!writeChunk(fd, (u4) kDexChunkRegisterMaps,

1495                pRegMapBuilder->data, pRegMapBuilder->size))

1496        {

1497            return false;

1498        }

1499    }

1500

1501    /* write the end marker */

1502    if (!writeChunk(fd, (u4) kDexChunkEnd, NULL, 0)) {

1503        return false;

1504    }

1505

1506    return true;

1507}

        数据是通过writeChunk()写入的，writeChunk()源码1429/*

1430 * Write a block of data in "chunk" format.

1431 *

1432 * header结构体占8字节，type字段为1一个kDexChunk开头的常量

1433 * 

1434 */

1435static bool writeChunk(int fd, u4 type, const void* data, size_t size)

1436{

1437    union {             /* save a syscall by grouping these together */

1438        char raw[8];

1439        struct {

1440            u4 type;

1441            u4 size;

1442        } ts;

1443    } header;

1444

1445    assert(sizeof(header) == 8);

1446

1447    ALOGV("Writing chunk, type=%.4s size=%d", (char*) &type, size);

1448

1449    header.ts.type = type;

1450    header.ts.size = (u4) size;

1451    if (sysWriteFully(fd, &header, sizeof(header),

1452            "DexOpt opt chunk header write") != 0)

1453    {

1454        return false;

1455    }

1456

1457    if (size > 0) {

1458        if (sysWriteFully(fd, data, size, "DexOpt opt chunk write") != 0)

1459            return false;

1460    }

1461

1462    /* if necessary, pad to 64-bit alignment */

1463    if ((size & 7) != 0) {

1464        int padSize = 8 - (size & 7);

1465        ALOGV("size was %d, inserting %d pad bytes", size, padSize);

1466        lseek(fd, padSize, SEEK_CUR);

1467    }

1468

1469    assert( ((int)lseek(fd, 0, SEEK_CUR) & 7) == 0);

1470

1471    return true;

1472}

    writeChunk()方法中传入的type字段

188/* auxillary data section chunk codes */

189enum {

190    kDexChunkClassLookup            = 0x434c4b50,   /* CLKP */

191    kDexChunkRegisterMaps           = 0x524d4150,   /* RMAP */

192

193    kDexChunkEnd                    = 0x41454e44,   /* AEND */

194};

    writeOptData ()方法中传入DexClassLookup结构指针，Dalvik虚拟机通过DexClassLookup结构检索dex文件中的类

447/*

448 * Lookup table for classes.  It provides a mapping from class name to

449 * class definition.  Used by dexFindClass().

450 *

451 * We calculate this at DEX optimization time and embed it in the file so we

452 * don't need the same hash table in every VM.  This is slightly slower than

453 * a hash table with direct pointers to the items, but because it's shared

454 * there's less of a penalty for using a fairly sparse table.

455 */

456struct DexClassLookup {

457    int     size;                       // 本结构的字节数

458    int     numEntries;                 // 接下来table结构的项数，通常值为2

459    struct {

460        u4      classDescriptorHash;    // 类的哈希值

461        int     classDescriptorOffset;  // 类的描述

462        int     classDefOffset;         // 指向DexClassDef结构的指针

463    } table[1];// 用来描述类的信息

464};

465

 

       根据上述源码总结出的ChunkDexClassLookup结构声明：

struct ChunkDexClassLookup{

       Header header;

       DexClassLookup lookup;

}

 

ChunkRegisterMapPool的结构体是writeOptData()函数向writeChunk()函数传递1个RegisterMapBuilder结构体指针。

RegisterMapBuilder结构体通过dvmGenerateRegisterMaps()函数填充。

dvmGenerateRegisterMaps()调用writeMapsAllClasses()填充所有类的映射信息，

writeMapsAllClasses()调用writeMapsAllMethods()填充所有方法映射信息

writeMapsAllMethods()调用writeMapForMethod()依次填充每个方法的映射信息

并调用computeRegisterMapSize()函数计算填充的每个方法映射信息的长度，用来循环遍历所有的方法

struct ChunkRegisterMapPool{

       Header header;

       struct{

              struct RegisterMapClassPool{

                     u4 numClasses;

                     u4 classDataOffset[1];

              }classpool;

              struct RegisterMapMethodPool{

                     u2 methodCount;

                     u4 methodData[1];

              };

       }lookup;

};

      

写ChunkEnd结构时，writeOptData()向writeChunk()传递了一个null指针，根据传递的kDexChunkEnd类型来判断。

odex文件最后的8个字节固定为“44 4E 45 41 00 00 00 00”

struct ChunkEnd{

       Header header;

}