dex文件 一、APK 的結構 二、加密方式 三、Dex格式解析 四、增量更新

Android知識總結

一、APK 的結構

文件

• META-INF ：簽名文件
• res：資源文件

二、加密方式

  對稱加密: 加密和解密的祕鑰使用的是同一個 例如：DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES

  非對稱加密算法: 公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密， 只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用 對應的公開密鑰才能解密。因爲加密和解密使用的是兩個不同的密鑰，所以這種 算法叫作非對稱加密算法

三、Dex格式解析

  dex文件是Android系統的可執行文件，包含應用程序的全部操作指令以及運行時數據。
  當java程序編譯成class後，還需要使用dx工具將所有的class文件整合到一個dex文件，目的是其中各個類能夠共享數據，在一定程度上降低了冗餘，同時也是文件結構更加經湊，實驗表明，dex文件是傳統jar文件大小的50%左右。

1、文件佈局

  dex 文件可以分爲3個模塊，頭文件、索引區、數據區。頭文件概況的描述了整個 dex 文件的分佈，包括每一個索引區的大小跟偏移。索引區表示每個數據的標識，索引區主要是指向數據區的偏移。

我們可以使用16進制查看工具打開一個dex來同步分析。(建議使用010Editor)。

1598320740980

010Editor 中除了數據區(data)沒有顯示出來，其他區段都有顯示，另外 link_data 在此處被定爲 map_list

magic 魔數：表示文件格式、版本
checksum ：校驗碼
signature ：簽名
fileSize ：文件大小

• aapt ：會把 application Resources 編譯成 R.java 和 Compiled Resources。 Compiled Resources 命名爲 .ap_ 文件。
• zipalign(resource mode)：壓縮時會進行 四字節對齊，優點：apk 運行快，RAM 內存減小。

打包流程

• 1、資源文件通過 aapt 工具 生產 R.java 文件，xx.aidl 文件通過 aidl 工具生成 java 文件；
• 2、把 Java 文件和上面生成的 Java 和通過java 編譯工具並並編譯成 class 文件；
• 3、通過 dx.bat 工具把 class 文件生產 dex 文件；
• 4、把資源文件（Resources）包和 dex 文件壓縮成 apk 包；
• 5、最後包壓縮後的 apk 包經過簽名，就成爲可以運行的 apk 包。

2、大小端

文件一般使用小端字節序存儲（Dex文件也不例外），網絡傳輸一般使用大端字節序。

• 大端模式（Big-endian），是指數據的高字節保存在內存的低地址中，而數據的低字節保存在內存的高地址中 。
• 小端模式（Little-endian），是指數據的高字節保存在內存的高地址中，而數據的低字節保存在內存的低地址中 。

3、Dex Header解析示例

  整個dex文件以16進制打開，前112個字節爲頭文件數據。Header描述了 dex 文件信息，和其他各個區的索引。

  此處數據，最開始爲 dex_magic 魔數，數據爲：

uint爲4字節數據

• checksum: 文件校驗碼，使用 alder32 算法校驗文件除去 maigc、checksum 外餘下的所有文件區域，用於檢 查文件錯誤。
• signature: 使用 SHA-1 算法 hash 除去 magic、checksum 和 signature 外餘下的所有文件區域， 用於唯一識別本文件 。
• file_size: dex 文件大小
• header_size: header 區域的大小，固定爲 0x70
• endian_tag: 大小端標籤，dex 文件格式爲小端，固定值爲 0x12345678
• map_off: map_item 的偏移地址，該 item 屬於 data 區裏的內容，值要大於等於 data_off 的大小，處於 dex文件的末端。

其他 xx_off ， xx_size 成對出現，爲對於數據的偏移與數據個數。對應Header數據解析代碼爲：

//dexFile: new File("dex文件地址")
byte[] rawData = FileUtil.readFile(dexFile);
this.data = ByteBuffer.wrap(rawData); //使用ByteBuffer裝載數據
this.data.order(ByteOrder.LITTLE_ENDIAN); //設置爲小端模式
//讀取header
header = Header.readFrom(data);

public class Header {
    //固定112個字節
    public static final int SIZE_OF_HEADER = 112;
    public int stringIdsSize;
    public int stringidsOff;
    public int typeIdsSize;
    public final int typeIdsOff;
    public final int protoIdsSize;
    public final int protoIdsOff;
    public final int fieldIdsSize;
    public final int fieldIdsOff;
    public final int methodIdsSize;
    public final int methodIdsOff;
    public final int classDefsSize;
    public final int classDefsOff;
    public final int dataSize;
    public final int dataOff;
    public int mapOff;
    public int fileSize;
    
    public Header(ByteBuffer data) {
        byte[] magic = BufferUtil.readBytes(data, 8); //魔數：文件格式、版本
        int checksum = data.getInt(); //校驗碼
        byte[] signature = BufferUtil.readBytes(data, 20); //簽名
        fileSize = data.getInt();
        int headerSize = data.getInt(); //一定是112
        int endianTag = data.getInt(); //一定是 0x12345678
        int linkSize = data.getInt();
        int linkOff = data.getInt();
//mapList部分偏移
        mapOff = data.getInt();
        stringIdsSize = data.getInt();
        stringidsOff = data.getInt();
        typeIdsSize = data.getInt();
        typeIdsOff = data.getInt();
        protoIdsSize = data.getInt();
        protoIdsOff = data.getInt();
        fieldIdsSize = data.getInt();
        fieldIdsOff = data.getInt();
        methodIdsSize = data.getInt();
        methodIdsOff = data.getInt();
        classDefsSize = data.getInt();
        classDefsOff = data.getInt();
        dataSize = data.getInt();
        dataOff = data.getInt();
    }
    public static Header readFrom(ByteBuffer in) {
//拷貝一份ByteBuffer
        ByteBuffer sectionData = in.duplicate();
        sectionData.order(ByteOrder.LITTLE_ENDIAN);//小端序
        sectionData.position(0);
//可操作數據長度爲 112字節
        sectionData.limit(SIZE_OF_HEADER);
        return new Header(sectionData);
    }
}

在解析完 Header 之後，就能夠獲得接下來數據的偏移與長度，按照對應的值定位位置解析。

4、StringIds

string_ids 區段描述了 dex 文件中所有的字符串。記錄的數據只有一個偏移量，偏移量指向了 數據區Data中 的一個字符串：stringids
根據 Header 解析結果得知，StringIds中有15個數據。

//dex對應的ByteBuffer、stringids個數與stringids數據區域偏移
string_ids = StringIdItem.readFrom(data, header.stringIdsSize, header.stringidsOff);
    
public static Map<Integer, StringIdItem> readFrom(ByteBuffer in, int size, int off) throws UTFDataFormatException {
        ByteBuffer sectionData = in.duplicate();
        sectionData.order(ByteOrder.LITTLE_ENDIAN);
        sectionData.position(off); //偏移此處爲stringids
        Map<Integer, StringIdItem> map = new HashMap<>();
        for (int i = 0; i < size; i++) {
            //字符串數據內容偏移
            int string_data_off = sectionData.getInt();
            int position = sectionData.position();
            //定位到數據內容對應偏移
            sectionData.position(string_data_off);
            //解析字符串數據 ： 下面說明
            int utf16_size = BufferUtil.readUnsignedLeb128(sectionData);
            String data = BufferUtil.readMutf8(sectionData, utf16_size);
            sectionData.position(position);
            StringIdItem stringItem = new StringIdItem(string_data_off, utf16_size, data);
            map.put(i, stringItem);
        }
        return map;
}

四、增量更新

  自從 Android 4.1 開始， Google Play 引入了應用程序的增量更新功能，App使用該升級方式，可節省約2/3的流量。現在國內主流的應用市場也都支持應用的增量更新。
  增量更新的關鍵在於增量一詞。平時我們的開發過程，往往都是今天在昨天的基礎上修改一些代碼，app的更新也是類似的：往往都是在舊版本的app上進行修改。這樣看來，增量更新就是原有app的基礎上只更新發生變化的地方，其餘保持原樣。
  與之前每次更新都要下載完整apk包的做法相比，這樣做的好處顯而易見：每次變化的地方總是比較少，因此更新包的體積就會小很多。比某APK的體積在60m左右，如果不採用增量更新，用戶每次更新都需要下載大約60m左右的安裝包，而採用增量更新這種方案之後每次只需要下載2m左右的更新包即可，相比原來做法大大減少了用戶下載等待的時間和流量，同時也可以因爲更新變得更簡單也能夠縮短產品版本覆蓋週期。