Android之Multidex分包配置以及原理分析

2017-09-21 本文已影响235人喜欢丶下雨天

引言

如果App引用的库太多，方法数超过65536后无法编译。这是因为单个dex里面不能有超过65536个方法。为什么有最大的限制呢，因为android会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的， short占两个字节（保存-2的15次方到2的15次方-1，即-32768~32767），最大保存的数量就是65536。新版本的Android系统中修复了这个问题，但是我们仍然需要对低版本的Android系统做兼容。
解决方法有如下几个： 1.精简方法数量,删除没用到的类、方法、第三方库。 2.使用ProGuard去掉一些未使用的代码 3.复杂模块采用jni的方式实现，也可以对边缘模块采用本地插件化的方式。 4.分割Dex。本文介绍最后一种方法。

配置操作

dex文件拆成两个或多个，为此谷歌官方推出了multidex兼容包，配合AndroidStudio实现了一个APK包含多个dex的功能。 Android 的 Gradle插件在 Android Build Tool 21.1开始就支持使用multidex了。

修改Gradle的配置，支持multidex:

android {
    compileSdkVersion 22
    buildToolsVersion "25.0.0"
    defaultConfig {
        ...
        minSdkVersion 14
        targetSdkVersion 22
        ...
        // Enabling multidex support.
        multiDexEnabled true  //这里
    }
    ...
}
dependencies {
  compile 'com.android.support:multidex:1.0.1' // 还有这里
}

你可以在Gradle配置文件中的defaultConfig、 buildType、productFlavor中设置 multiDexEnabled true。

第二步分三种情况：

如果没有重写Application,在manifest文件中，在application标签下添加MultidexApplication Class的引用，看配置：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.android.multidex.myapplication">
    <application
        ...
        android:name="android.support.multidex.MultiDexApplication">
        ...
    </application>
</manifest>

如果重写了Application，可以让自定义Applicationd继承android.support.multidex.MultiDexApplication。

图.png

看看里MultiDexApplication里有什么：

MultiDexApplication.png

如果重写了Application并且已经继承了其他Application类，可以重写attachBaseContext()方法，并添加语句MultiDex.install(this)；看代码：

public class MyApplication extends BaseApplication{
    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(this);
    }
}

没什么特别问题，到这里就可以了，你的分包就完成了。
注意事项:Application 中的静态全局变量会比MutiDex的 install()方法优先加载，所以建议避免在Application类中使用静态变量引用 main classes.dex文件以外dex文件中的类。

Multidex的局限

官方文档中提到了Multidex有局限性：

如果第二个(或其他个)dex文件很大的话，安装.dex文件到data分区时可能会导致ANR(应用程序无响应)。
由于Dalvik linearAlloc的bug的关系，使用了multidex的应用可能无法在Android 4.0 (API level 14)或之前版本的设备上运行。
由于Dalvik linearAlloc的限制，使用了multidex的应用会请求非常大的内存分配，从而导致程序奔溃。Dalvik linearAlloc是一个固定大小的缓冲区。在应用的安装过程中，系统会运行一个名为dexopt的程序为该应用在当前机型中运行做准备。dexopt使用LinearAlloc来存储应用的方法信息。 Android 2.2和2.3的缓冲区只有5MB，Android 4.x提高到了8MB或16MB。当方法数量过多导致超出缓冲区大小时，会造成dexopt崩溃。
在Dalvik运行时中，某些类的方法必须要放在主dex中，Android构建工具可能无法确保所有有此要求的类被编译进主dex中。

下面的问题也非常值得我们关注：

一些在二级Dex加载之前,可能会被调用到的类(比如静态变量的类),需要放在主Dex中.否则会ClassNotFoundError. 通过修改Gradle,可以显式的把一些类放在Main Dex中。

afterEvaluate {
    tasks.matching {
        it.name.startsWith('dex')
    }.each { dx ->
        if (dx.additionalParameters == null) {
            dx.additionalParameters = []
        }
        dx.additionalParameters += '--multi-dex'
        dx.additionalParameters += "--main-dex-list=$projectDir/<filename>".toString()
    }
}

注意上面是修改后的Gradle,其中是一个文本文件的文件名,存放在和这个build.gradle脚本同一级的文件目录下,而不是项目根目录。可以把这个文本文件起名为multidex.keep，内容如下.实际就是把需要放在Main Dex的类罗列出来。

android/support/multidex/BuildConfig/class
android/support/multidex/MultiDex$V14/class
android/support/multidex/MultiDex$V19/class
android/support/multidex/MultiDex$V4/class
android/support/multidex/MultiDex/class
android/support/multidex/MultiDexApplication/class
android/support/multidex/MultiDexExtractor$1/class
android/support/multidex/MultiDexExtractor/class
android/support/multidex/ZipUtil$CentralDirectory/class
android/support/multidex/ZipUtil/class

project.afterEvaluate标签在特定的project配置完成后运行，而gradle.projectsEvaluated在所有projects配置完成后运行。注意afterEvaluate需要放在android{}里，不可放外面。

这样做了之后并不一定解压apk之后会出现多个dex文件，可能仍然只有一个dex。因为只有必须分包的时候才会分，如果不需要就不会。如果要强制分dex，还需要加上dx.additionalParameters += ‘–minimal-main-dex’。完整的配置如下：

 afterEvaluate {
        tasks.matching {
            it.name.startsWith('dex')
        }.each { dx ->
            if (dx.additionalParameters == null) {
                dx.additionalParameters = []
            }
            dx.additionalParameters += '--multi-dex'

            // 设置multidex.keep文件中class为第一个dex文件中包含的class，如果没有下一项设置此项无作用
            dx.additionalParameters += "--main-dex-list=$projectDir/multidex.keep".toString()

            //此项添加后第一个classes.dex文件只能包含-main-dex-list列表中class  
            dx.additionalParameters += '--minimal-main-dex'
        }
    }

这样配置了之后就按照multidex.keep里面的内容拆分出了第一个dex文件。其他内容在第二个里面。那么如何把需要的类放在multidex.keep文件里呢？其实不用手动一个类一个类写，我们进入这个文件：项目\build\intermediates\multi-dex\release（或debug）\maindexlist.txt。将maindexlist.txt中没有在application中初始化的类删除一部分之后，剩余的复制到multidex.keep文件中就可以了。当然也可以自行增加没有被包含进去的类，因为不直接引用的类都不在maindexlist.txt中。注意，如果需要混淆的话需要写混淆之后的 class 。

如果需要配置每一个dex最大的方法数，可以如下配置：

afterEvaluate {
        tasks.matching {
            it.name.startsWith('dex')
        }.each { dx ->
            if (dx.additionalParameters == null) {
                dx.additionalParameters = []
            }
            dx.additionalParameters += '--set-max-idx-number=48000'
        }
    }

通过上面的number参数代表每个Dex文件中的最大id数，默认是65535，通过修改这个值可以减少Main Dex文件的大小和个数。这样可以拆分出多个dex。但是这个number不可设置的太小，因为主dex需要加载足够app启动需要的类，太小则无法加载完，直接报错。

如果用使用其他Lib,要保证这些Lib没有被preDex,否则可能会抛出下面的异常：

UNEXPECTED TOP-LEVEL EXCEPTION:
    com.android.dex.DexException: Library dex files are not supported in multi-dex mode
        at com.android.dx.command.dexer.Main.runMultiDex(Main.java:337)
        at com.android.dx.command.dexer.Main.run(Main.java:243)
        at com.android.dx.command.dexer.Main.main(Main.java:214)
        at com.android.dx.command.Main.main(Main.java:106)

遇到这个异常,需要在Gradle中修改,让它不要对Lib做preDexing

android {
    //  ...
        dexOptions {
            preDexLibraries = false
        }
    }

MultiDex实现原理

下面从DEX自动拆包和动态加载两方面来分析。

Dex 拆分

dex拆分步骤分为:

自动扫描整个工程代码得到main-dex-list；
根据main-dex-list对整个工程编译后的所有class进行拆分，将主、从dex的class文件分开；
用dx工具对主、从dex的class文件分别打包成 .dex文件，并放在apk的合适目录。

怎么自动生成 main-dex-list？ Android SDK 从 build tools 21 开始提供了 mainDexClasses 脚本来生成主 dex 的文件列表。查看这个脚本的源码，可以看到它主要做了下面两件事情:

1）调用 proguard 的 shrink 操作来生成一个临时 jar 包； 2）将生成的临时 jar 包和输入的文件集合作为参数，然后调用com.android.multidex.MainDexListBuilder 来生成主 dex 文件列表。

Proguard的官网执行步骤如下：

img158.jpg

在 shrink 这一步，proguard 会根据 keep 规则保留需要的类和类成员，并丢弃不需要的类和类成员。也就是说，上面 shrink 步骤生成的临时 jar 包里面保留了符合 keep 规则的类，这些类是需要放在主 dex 中的入口类。

但是仅有这些入口类放在主 dex 还不够，还要找出入口类引用的其他类，不然仍然会在启动时出现 NoClassDefFoundError。而找出这些引用类，就是调用的 com.android.multidex.MainDexListBuilder，它的部分核心代码如下：

img159.jpg

在调用 com.android.multidex.MainDexListBuilder 之后，符合 keep 规则的主 dex 文件列表就生成了。

Dex加载
因为Android系统在启动应用时只加载了主dex（Classes.dex），其他的 dex 需要我们在应用启动后进行动态加载安装。 Google 官方方案是如何加载的呢,Google官方支持Multidex 的 jar 包是 android-support-multidex.jar，该 jar 包从 build tools 21.1 开始支持。这个 jar 加载 apk 中的从 dex 流程如下：

img160.jpg

此处主要的工作就是从 apk 中提取出所有的从 dex（classes2.dex，classes3.dex，…），然后通过反射依次安装加载从dex，并合并到放在BaseDexClassLoader的DexPathList的 Element数组。

BaseDexClassLoader findClass的过程如下:

    protected Class<?> findClass(String name) throws ClassNotFoundException {
        List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
        Class c = pathList.findClass(name, suppressedExceptions);
        if (c == null) {
            ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList); 
            for (Throwable t : suppressedExceptions) {
                cnfe.addSuppressed(t);
            }
            throw cnfe;
        }
        return c;
    }

下面代码说明了怎么通过DexFile来加载Secondary DEX并放到BaseDexClassLoader的DexPathList中:

    private static void install(ClassLoader loader, List<File> additionalClassPathEntries,
                                File optimizedDirectory)
            throws IllegalArgumentException, IllegalAccessException,
            NoSuchFieldException, InvocationTargetException, NoSuchMethodException {
        /* The patched class loader is expected to be a descendant of
         * dalvik.system.BaseDexClassLoader. We modify its
         * dalvik.system.DexPathList pathList field to append additional DEX
         * file entries.
         */
        Field pathListField = findField(loader, "pathList");
        Object dexPathList = pathListField.get(loader);
        ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
        expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList,
                new ArrayList<File>(additionalClassPathEntries), optimizedDirectory,
                suppressedExceptions));
        try {
            if (suppressedExceptions.size() > 0) {
                for (IOException e : suppressedExceptions) {
                    //Log.w(TAG, "Exception in makeDexElement", e);
                }
                Field suppressedExceptionsField =
                        findField(loader, "dexElementsSuppressedExceptions");
                IOException[] dexElementsSuppressedExceptions =
                        (IOException[]) suppressedExceptionsField.get(loader);
                if (dexElementsSuppressedExceptions == null) {
                    dexElementsSuppressedExceptions =
                            suppressedExceptions.toArray(
                                    new IOException[suppressedExceptions.size()]);
                } else {
                    IOException[] combined =
                            new IOException[suppressedExceptions.size() +
                                    dexElementsSuppressedExceptions.length];
                    suppressedExceptions.toArray(combined);
                    System.arraycopy(dexElementsSuppressedExceptions, 0, combined,
                            suppressedExceptions.size(), dexElementsSuppressedExceptions.length);
                    dexElementsSuppressedExceptions = combined;
                }
                suppressedExceptionsField.set(loader, dexElementsSuppressedExceptions);
            }
        } catch(Exception e) {
        }
    }

Android之Multidex分包配置以及原理分析

引言

配置操作

Multidex的局限

MultiDex实现原理

猜你喜欢

热点阅读