[TOC]

错误表现

• app 无法打包，日志为

com.android.dex.DexException：Too many classes in --main-dex-list, main dex capacity exceeded

错误原因

生成的第一个classes.dex中方法数操过65535 也就是 Short.MAX_VALUE

在Android生成APK工具链的 dx 源码中有

dalvik/dx/src/com/android/dx/command/dexer/Main.java

if (args.mainDexListFile != null) {
  // with --main-dex-list
  // ...
  // forced in main dex
  for (int i = 0; i < fileNames.length; i++) {
    // call processClass
    processOne(fileNames[i], mainPassFilter);
  }
  if (dexOutputArrays.size() > 0) {
    throw new DexException("Too many classes in " + Arguments.MAIN_DEX_LIST_OPTION
      + ", main dex capacity exceeded");
  }
}

processClass

private static boolean processClass(String name, byte[] bytes) {
  int numMethodIds = outputDex.getMethodIds().items().size();
  int numFieldIds = outputDex.getFieldIds().items().size();
  int constantPoolSize = cf.getConstantPool().size();
  int maxMethodIdsInDex = numMethodIds + constantPoolSize + cf.getMethods().size() +
  MAX_METHOD_ADDED_DURING_DEX_CREATION;
  int maxFieldIdsInDex = numFieldIds + constantPoolSize + cf.getFields().size() +
  MAX_FIELD_ADDED_DURING_DEX_CREATION;
  if (args.multiDex
    && (outputDex.getClassDefs().items().size() > 0)
    && ((maxMethodIdsInDex > args.maxNumberOfIdxPerDex) ||
      (maxFieldIdsInDex > args.maxNumberOfIdxPerDex))) {
    DexFile completeDex = outputDex;
  createDexFile();
}

createDexFile创建一个新的Byte[]对象放入dexOutputArrays
processAllFiles遇到dexOutputArrays.size > 0就会抛DexException

分包过程解析

分包的原因

Android系统安装运行应用的时候，有一步是对 dex 进行运行优化，增加运行效率
优化过程中，有过处理汇编文件加载的优化叫dexOpt

dexOpt的执行过程
在第一次加载Dex文件的时候执行的，这个过程会生成一个 odex文件，即Optimised dex
odex的用途是分离程序资源和可执行文件、以及做预编译处理
执行 odex处理过的 的效率会比直接执行 dex纯粹jar包 文件的效率要高很多

dexOpt有一个设计，会把每一个类的方法id检索起来，存在一个链表结构里面
这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65536(Short.MAX_VALUE)

• Dalvik 模式下，dexOpt 肯定开启
• ART 模式下，虽然不是JIT，仍然复用了这个优化策略

解决方法数超限的问题，需要将该dex文件拆成两个或多个

google官方文档 https://developer.android.com/tools/building/multidex.html#about

分包过程

• 找出必须优先加载的类在主包
• 其余类按引用顺序，随机到其余包
• 打包构建出APP发布
• 运行分包的APP在 Applicaion 实例化之后，会检查系统版本是否支持 multidex
• 运行加载主包 Dalvik 模式将子包拷贝到应用的沙盒目录 ART 则是运行主包，混合子包生成 oat 文件
• Dalvik 运行时，先运行编译运行主包,然后通过反射将子dex注入到当前的 classloader 中
• ART 模式加载 包含多个dex的 oat 文件，然后解释运行主包，一样通过反射将子dex注入到当前的 classloader 中

Android运行时ART加载OAT文件的过程分析
http://blog.csdn.net/luoshengyang/article/details/39307813

5.0 系统前后分包支持

• Android5.0之前，使用 Dalvik 方式运行，先加载主分包，然后反射加载其余的包
• Android5.0之后，使用 ART 方式运行，ART预编译时，扫描主分包和子包，生成 .oat 文件用于用户运行

分包方案的隐患

• API14 之前的不能支持分包 Dalvik linearalloc bug
• 复杂的依赖的工程，分包后，不同依赖项目间的dex文件函数相互调用，报错找不到方法
• 带有混淆的工程，非常容易出现依赖沾粘(不同依赖项目间的dex文件同一个类定义树)，安装时报告类定义安全检查异常
• 开发过程有分包，导致每一次的模块构建过程都是相当耗时，开发效率低下
• 分包文件过大，安装分割dex文件在某些设备上表现很差，非常容易导致ANR （此问题 5.0 以后的设备表现为安装不成功）
• 分包数量过多引起安装失败，分到第6个以后容易出现，原理同上面一点
• 应用程序使用 multiedex 就大量使用反射，会造成使用比较大的内存，OOM 将会非常容易出现
• 工程过大，且依赖管理混乱时，主分包因为必须加载，方法数还是超过了65536，导致主分包无法生成

解决multiedex隐患思路

• 删除无意义代码，无意义资源
• 删除重复代码轮子
• 拆分重型模块，依赖越多，越成树状越易维护
• 降低工程依赖圈复杂度(不要循环依赖，用反射解耦)
• 分离开发和发布构建，尽量让模块功能最小化，减少模块本身分包可能性
• 活用混淆，降低dex文件大小（混淆实际上起不到安全作用，Dalvik 汇编很容易理解掌握破解混淆）
• 使用二进制优化工具，减小dex的大小
• 业务过于多，做多个 APP 通讯的方式，或者拆分子 app 动态加载
• 优化主分包依赖

主分包详解

主分包在Android编译，发布，运行时地位很高，而主分包的生成是靠分析出的 maindexlist.txt 来生成的

maindexlist.txt 创建分析

源码地址

android gradle plugin
有一个类专门负责创建maindexlist.txt，叫做CreateMainDexList

源码

tools/base/build-system/gradle-core/src/main/groovy/com/android/build/gradle/internal/tasks/multidex/CreateMainDexList.groovy

https://android.googlesource.com/platform/tools/base/+/master/build-system/gradle-core/src/main/groovy/com/android/build/gradle/internal/tasks/multidex/CreateManifestKeepList.groovy

@TaskAction
void output() {
    if (getAllClassesJarFile() == null) {
        throw new NullPointerException("No input file")
    }

    // manifest components plus immediate dependencies must be in the main dex.
    File _allClassesJarFile = getAllClassesJarFile()
    Set<String> mainDexClasses = callDx(_allClassesJarFile, getComponentsJarFile())
    ...
}

callDx最终调用AndroidBuilder.createMainDexList
实际是通过开启后台进程执行ClassReferenceListBuilder.main
分析类的依赖关系，生成一个maindexlist.txt

public void addRoots(ZipFile jarOfRoots) throws IOException {
    ...
    for (Enumeration<? extends ZipEntry> entries = jarOfRoots.entries();
      entries.hasMoreElements();) {
      ZipEntry entry = entries.nextElement();
      String name = entry.getName();
      if (name.endsWith(CLASS_EXTENSION)) {
          DirectClassFile classFile;
          ...
          classFile = path.getClass(name);
          ...
          addDependencies(classFile.getConstantPool());
      }
  }
}

ClassReferenceListBuilder.addRoots通过读文件遍历componentClasses.jar的每个entry
再调用addDependencies分析这个类的依赖关系

private void addDependencies(ConstantPool pool) {
    for (Constant constant : pool.getEntries()) {
        if (constant instanceof CstType) {
            Type type = ((CstType) constant).getClassType();
            String descriptor = type.getDescriptor();
            if (descriptor.endsWith(";")) {
                int lastBrace = descriptor.lastIndexOf('[');
                if (lastBrace < 0) {
                    addClassWithHierachy(descriptor.substring(1, descriptor.length()-1));
                } else {
                    assert descriptor.length() > lastBrace + 3
                    && descriptor.charAt(lastBrace + 1) == 'L';
                    addClassWithHierachy(descriptor.substring(lastBrace + 2,
                            descriptor.length() - 1));
                }
            }
        }
    }
}

addDependencies从ConstantPool得到import类，调用addClassWithHierachy继续分析继承关系

也可以通过javap -verbose先反汇编，再分析匹配”= class”的字符串来获取来调试

依赖关系分析结束后，输出maindexlist.txt

所以一句话 componentClasses.jar最终决定了maindexlist.txt的大小

componentClasses.jar 生成分析

这个中间生成的componentClasses.jar最后会在打包成功后删除

当然出现方法超过的时候，这个包在 moduel/build/intermediates/multi-dex/对应渠道里面

gradle plugin 2.3.0 以后位置有变动，不过一样可以找到

componentClasses.jar 生成任务 proguardComponentsTask

根据manifest_keep.txt从allclasses.jar中抽取生成的，manifest_keep.txt内容一般是

-keep class com.xxx.app.XXXXApplication {
  <init>();
  void attachBaseContext(android.content.Context);
}
-keep class com.xxx.splash.XXXXActivity { <init>(); }
-keep class com.xxx.app.MainActivity { <init>(); }
-keep class com.xxx.login.xxxx.LoginActivity { <init>(); }
-keep class com.xxx.sidebar.account.XXAccountActivity { <init>(); }
...

不难看出manifest_keep.txt是通过CreateManifestKeepList解析AndroidManifest.xml文件得到

./tools/base/build-system/gradle-core/src/main/groovy/com/android/build/gradle/internal/tasks/multidex/CreateManifestKeepList.groovy

    @TaskAction
    void generateKeepListFromManifest() {
        SAXParser parser = SAXParserFactory.newInstance().newSAXParser()
        Writer out = new BufferedWriter(new FileWriter(getOutputFile()))
        try {
            parser.parse(getManifest(), new ManifestHandler(out))
            // add a couple of rules that cannot be easily parsed from the manifest.
            out.write(
"""-keep public class * extends android.app.backup.BackupAgent {
    <init>();
}
-keep public class * extends java.lang.annotation.Annotation {
    *;
}
""")
            if (proguardFile != null) {
                out.write(Files.toString(proguardFile, Charsets.UTF_8))
            }
        } finally {
            out.close()
        }
    }
    ...

CreateManifestKeepList私有内部类ManifestHandler用CreateManifestKeepList.KEEP_SPECS[qName]决定哪些类需要放入manifest_keep.txt

private class ManifestHandler extends DefaultHandler {
    ...
    @Override
    void startElement(String uri, String localName, String qName, Attributes attr) {
        String keepSpec = CreateManifestKeepList.KEEP_SPECS[qName]
        if (keepSpec) {
            boolean keepIt = true
            if (CreateManifestKeepList.this.filter) {
                Map<String, String> attrMap = [:]
                for (int i = 0; i < attr.getLength(); i++) {
                    attrMap[attr.getQName(i)] = attr.getValue(i)
                }
                keepIt = CreateManifestKeepList.this.filter(qName, attrMap)
            }

            if (keepIt) {
                String nameValue = attr.getValue('android:name')
                if (nameValue != null) {
                    out.write((String) "-keep class ${nameValue} $keepSpec\n")
                }

过滤的KEEP_SPECS

    private static String DEFAULT_KEEP_SPEC = "{ <init>(); }"
    private static Map<String, String> KEEP_SPECS = [
        'application' : """{
    <init>();
    void attachBaseContext(android.content.Context);
}""",
        'activity' : DEFAULT_KEEP_SPEC,
        'service' : DEFAULT_KEEP_SPEC,
        'receiver' : DEFAULT_KEEP_SPEC,
        'provider' : DEFAULT_KEEP_SPEC,
        'instrumentation' : DEFAULT_KEEP_SPEC,
    ]

那么至少AndroidManifest.xml中

• application
• activity
• service
• receiver
• provider
• instrumentation

这6种标签的类

以及继承

• java.lang.annotation.Annotation
• android.app.backup.BackupAgent

的类都会会用来产生maindexlist.txt

总结，必须在主分包中的类有

• 基于apk运行的加载机制，Application 中的引用肯定在在主包内
• 开启 MultiDex 分包 那么android.support.multidex 包肯定必须在主包内
• 继承 java.lang.annotation.Annotation android.app.backup.BackupAgent 在主包
• 在 AndroidManifest.xml 注册的四大组件，必须在第一个包
• 使用 instrumentation 测试技术实现的必须在第一个包内