由Android 65K方法數限制引發的思考

前言

沒想到，65536真的很小。

Unable to execute dex: method ID not in [0, 0xffff]: 65536

PS:本文只是純探索一下這個65K的來源，僅此而已。

到底是65k還是64k?

時間點

65536是怎麼算出來的？

65536網上眾說紛紜，有對的，有不全對的，也有錯的。下面將跟蹤最新的AOSP原始碼來順藤摸瓜，但是探索問題必然迂迴冗餘，僅作記錄，讀者可直接跳過看結果。

1. 首先，查詢Dex的結構定義。

/*
 * Direct-mapped "header_item" struct.
 */
struct DexHeader {
    u1  magic[8];
    u4  checksum;
    u1  signature[kSHA1DigestLen];
    u4  fileSize;
    u4  headerSize;
    u4  endianTag;
    u4  linkSize;
    u4  linkOff;
    u4  mapOff;
    u4  stringIdsSize;
    u4  stringIdsOff;
    u4  typeIdsSize;
    u4  typeIdsOff;
    u4  protoIdsSize;
    u4  protoIdsOff;
    u4  fieldIdsSize;
    u4  fieldIdsOff;
    u4  methodIdsSize; // 這裡存放了方法欄位索引的大小，methodIdsSize的型別為u4
    u4  methodIdsOff;
    u4  classDefsSize;
    u4  classDefsOff;
    u4  dataSize;
    u4  dataOff;
};

u4的型別定義如下：

/*
 * These match the definitions in the VM specification.
 */
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;

2. DexOpt優化造成？

這個說法源自：

3. DexMerger的檢測

只能在dalvik目錄下搜尋關鍵字”methid ID not in”，在DexMergger裡找到了丟擲異常的地方：

/**
 * Combine two dex files into one.
  */
public final class DexMerger {

    private void mergeMethodIds() {
        new IdMerger<MethodId>(idsDefsOut) {
            @Override TableOfContents.Section getSection(TableOfContents tableOfContents) {
                return tableOfContents.methodIds;
            }

            @Override MethodId read(Dex.Section in, IndexMap indexMap, int index) {
                return indexMap.adjust(in.readMethodId());
            }

            @Override void updateIndex(int offset, IndexMap indexMap, int oldIndex, int newIndex) {
                if (newIndex < 0 || newIndex > 0xffff) {
                    throw new DexIndexOverflowException(
                            "method ID not in [0, 0xffff]: " + newIndex);
                }
                indexMap.methodIds[oldIndex] = (short) newIndex;
            }

            @Override void write(MethodId methodId) {
                methodId.writeTo(idsDefsOut);
            }
        }.mergeSorted();
    }
}

這裡定義了indexMap的methodIds的單項值要強轉short，所以在存放之前check一下範圍是不是0 ~ 0xffff。我們看看IndexMap的定義：

/**
 * Maps the index offsets from one dex file to those in another. For example, if
 * you have string #5 in the old dex file, its position in the new dex file is
 * {@code strings[5]}.
 */
public final class IndexMap {
    private final Dex target;
    public final int[] stringIds;
    public final short[] typeIds;
    public final short[] protoIds;
    public final short[] fieldIds;
    public final short[] methodIds;

    // ... ...
}

看上去是對了，可是這個DexMerger是合併兩個dex的，預設情況下我們只有一個dex的，那麼這個65k是哪裡限制的呢？再查！

4. 迴歸DexFile

// 原始碼目錄：dalvik/dx
// Main.java
-> main() -> run() -> runMonoDex()(或者runMultiDex()) -> writeDex()
// DexFile
-> toDex() -> toDex0()
// MethodIdsSection extends MemberIdsSection extends UniformItemSection extends  Section
-> prepare() -> prepare0() -> orderItems() -> getTooManyMembersMessage()
// Main.java
-> getTooManyIdsErrorMessage()

最終狐狸的尾巴是在MemberIdsSection漏出來了：

package com.android.dx.dex.file;

import com.android.dex.DexException;
import com.android.dex.DexFormat;
import com.android.dex.DexIndexOverflowException;
import com.android.dx.command.dexer.Main;

import java.util.Formatter;
import java.util.Map;
import java.util.TreeMap;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * Member (field or method) refs list section of a {@code .dex} file.
 */
public abstract class MemberIdsSection extends UniformItemSection {

    /**
     * Constructs an instance. The file offset is initially unknown.
     *
     * @param name {@code null-ok;} the name of this instance, for annotation
     * purposes
     * @param file {@code non-null;} file that this instance is part of
     */
    public MemberIdsSection(String name, DexFile file) {
        super(name, file, 4);
    }

    /** {@inheritDoc} */
    @Override
        protected void orderItems() {
            int idx = 0;

            if (items().size() > DexFormat.MAX_MEMBER_IDX + 1) {
                throw new DexIndexOverflowException(getTooManyMembersMessage());
            }

            for (Object i : items()) {
                ((MemberIdItem) i).setIndex(idx);
                idx++;
            }
        }

    private String getTooManyMembersMessage() {
        Map<String, AtomicInteger> membersByPackage = new TreeMap<String, AtomicInteger>();
        for (Object member : items()) {
            String packageName = ((MemberIdItem) member).getDefiningClass().getPackageName();
            AtomicInteger count = membersByPackage.get(packageName);
            if (count == null) {
                count = new AtomicInteger();
                membersByPackage.put(packageName, count);
            }
            count.incrementAndGet();
        }

        Formatter formatter = new Formatter();
        try {
            String memberType = this instanceof MethodIdsSection ? "method" : "field";
            formatter.format("Too many %s references: %d; max is %d.%n" +
                    Main.getTooManyIdsErrorMessage() + "%n" +
                    "References by package:",
                    memberType, items().size(), DexFormat.MAX_MEMBER_IDX + 1);
            for (Map.Entry<String, AtomicInteger> entry : membersByPackage.entrySet()) {
                formatter.format("%n%6d %s", entry.getValue().get(), entry.getKey());
            }
            return formatter.toString();
        } finally {
            formatter.close();
        }
    }

}

裡面有一段：

// 如果方法數大於0xffff就提示65k錯誤
if (items().size() > DexFormat.MAX_MEMBER_IDX + 1) {
    throw new DexIndexOverflowException(getTooManyMembersMessage());
}

// 這個DexFormat.MAX_MEMBER_IDX就是0xFFFF
/**
 * Maximum addressable field or method index.
 * The largest addressable member is 0xffff, in the "instruction formats" spec as field@CCCC or
 * meth@CCCC.
 */
public static final int MAX_MEMBER_IDX = 0xFFFF;

至此，真相大白！

5. 根本原因

6. 回顧

我好像明白了什麼：

1. 65k問題是dx打包單個Dex時報的錯，所以只要用dx打包單個dex就可能有這個問題。
2. 不僅方法數，欄位數也有65k問題。
3. 目前來說，65k問題和系統無關。
4. 目前來說，65k問題和art無關。
5. 即使分包MultiDex，當主Dex的方法數超過65k依然會報錯。
6. MultiDex方案不是從根本上解決了65k問題，但是大大緩解甚至說基本解決了65k問題。

新的Jack能否解決65k問題？

據說Jack的方式把class打包成.jack檔案。所以我認為，Jack具備解決65k問題的條件：

1. 打包：新的jack檔案肯定是拋棄了dalvik的相容性，這也註定我們們這兩年可能還用不了。
2. 虛擬機器：完全採用新的ART虛擬機器，把class轉化成本地機器碼，就能避開dalvik bytecode的16位限制。
3. 上面兩條屬於廢話，說白了，完全不用dalvik虛擬機器了，同時也就完全不用dx了，如此，當然就不存在65k問題了。

以上純屬我個人推測，一切以科學分析為準。