Android dex分包方案和热补丁原理

一、分包的原因：

当一个app的功能越来越复杂，代码量越来越多，也许有一天便会突然遇到下列现象：

1. 生成的apk在2.3以前的机器无法安装，提示INSTALL_FAILED_DEXOPT

2. 方法数量过多，编译时出错，提示：

Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536

出现这种问题的原因是：

1. Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M

2. 一个dex文件最多只支持65536个方法。

针对上述问题，也出现了诸多解决方案，使用的最多的是插件化，即将一些独立的功能做成一个单独的apk，当打开的时候使用DexClassLoader动态加载，然后使用反射机制来调用插件中的类和方法。这固然是一种解决问题的方案：但这种方案存在着以下两个问题：

1. 插件化只适合一些比较独立的模块；

2. 必须通过反射机制去调用插件的类和方法，因此，必须搭配一套插件框架来配合使用；

由于上述问题的存在，通过不断研究，便有了dex分包的解决方案。简单来说，其原理是将编译好的class文件拆分打包成两个dex，绕过dex方法数量的限制以及安装时的检查，在运行时再动态加载第二个dex文件中。faceBook曾经遇到相似的问题，具体可参考：

https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920

文中有这么一段话：

However, there was no way we could break our app up this way--too many of our classes are accessed directly by the Android framework. Instead, we needed to inject our secondary dex files directly into the system class loader。

文中说得比较简单，我们来完善一下该方案：除了第一个dex文件（即正常apk包唯一包含的Dex文件），其它dex文件都以资源的方式放在安装包中，并在Application的onCreate回调中被注入到系统的ClassLoader。因此，对于那些在注入之前已经引用到的类（以及它们所在的jar）,必须放入第一个Dex文件中。

下面通过一个简单的demo来讲述dex分包方案，该方案分为两步执行：

整个demo的目录结构是这样，我打算将SecondActivity，MyContainer以及DropDownView放入第二个dex包中，其它保留在第一个dex包。

二、1、编译时分包

整个编译流程如下：

除了框出来的两Target，其它都是编译的标准流程。而这两个Target正是我们的分包操作。首先来看看spliteClasses target。

由于我们这里仅仅是一个demo,因此放到第二个包中的文件很少，就是上面提到的三个文件。分好包之后就要开始生成dex文件，首先打包第一个dex文件：

由这里将${classes}（该文件夹下都是要打包到第一个dex的文件）打包生成第一个dex。接着生成第二个dex，并将其打包到资资源文件中：

可以看到，此时是将${secclasses}中的文件打包生成dex，并将其加入ap文件（打包的资源文件）中。到此，分包完毕，接下来，便来分析一下如何动态将第二个dex包注入系统的ClassLoader。

2、将dex分包注入ClassLoader

这里谈到注入，就要谈到Android的ClassLoader体系。

由上图可以看出，在叶子节点上，我们能使用到的是DexClassLoader和PathClassLoader，通过查阅开发文档，我们发现他们有如下使用场景：

（1）. 关于PathClassLoader，文档中写到： Android uses this class for its system class loader and for its application class loader(s),

由此可知，Android应用就是用它来加载;

（2） DexClass可以加载apk,jar,及dex文件，但PathClassLoader只能加载已安装到系统中（即/data/app目录下）的apk文件。

知道了两者的使用场景，下面来分析下具体的加载原理，由上图可以看到，两个叶子节点的类都继承BaseDexClassLoader中，而具体的类加载逻辑也在此类中：

BaseDexClassLoader:

1. @Override
2. protected Class<?> findClass(String name) throws ClassNotFoundException {
3. List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
4. Class c = pathList.findClass(name, suppressedExceptions);
5. if (c == null) {
6. ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
7. for (Throwable t : suppressedExceptions) {
8. cnfe.addSuppressed(t);
9. }
10. throw cnfe;
11. }
12. return c;
13. }

由上述函数可知，当我们需要加载一个class时，实际是从pathList中去需要的，查阅源码，发现pathList是DexPathList类的一个实例。ok，接着去分析DexPathList类中的findClass函数，

DexPathList:

1. public Class findClass(String name, List<Throwable> suppressed) {
2. for (Element element : dexElements) {
3. DexFile dex = element.dexFile;
4. if (dex != null) {
5. Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
6. if (clazz != null) {
7. return clazz;
8. }
9. }
10. }
11. if (dexElementsSuppressedExceptions != null) {
12. suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
13. }
14. return null;
15. }

上述函数的大致逻辑为：遍历一个装在dex文件（每个dex文件实际上是一个DexFile对象）的数组（Element数组，Element是一个内部类），然后依次去加载所需要的class文件，直到找到为止。

看到这里，注入的解决方案也就浮出水面，假如我们将第二个dex文件放入Element数组中，那么在加载第二个dex包中的类时，应该可以直接找到。

带着这个假设，来完善demo。

在我们自定义的BaseApplication的onCreate中，我们执行注入操作：

1. public String inject(String libPath) {
2. boolean hasBaseDexClassLoader = true;
3. try {
4. Class.forName("dalvik.system.BaseDexClassLoader");
5. } catch (ClassNotFoundException e) {
6. hasBaseDexClassLoader = false;
7. }
8. if (hasBaseDexClassLoader) {
9. PathClassLoader pathClassLoader = (PathClassLoader)sApplication.getClassLoader();
10. DexClassLoader dexClassLoader = new DexClassLoader(libPath, sApplication.getDir("dex", 0).getAbsolutePath(), libPath, sApplication.getClassLoader());
11. try {
12. Object dexElements = combineArray(getDexElements(getPathList(pathClassLoader)), getDexElements(getPathList(dexClassLoader)));
13. Object pathList = getPathList(pathClassLoader);
14. setField(pathList, pathList.getClass(), "dexElements", dexElements);
15. return "SUCCESS";
16. } catch (Throwable e) {
17. e.printStackTrace();
18. return android.util.Log.getStackTraceString(e);
19. }
20. }
21. return "SUCCESS";
22. }

这是注入的关键函数，分析一下这个函数：

参数libPath是第二个dex包的文件信息（包含完整路径，我们当初将其打包到了assets目录下），然后将其使用DexClassLoader来加载（这里为什么必须使用DexClassLoader加载，回顾以上的使用场景），然后通过反射获取PathClassLoader中的DexPathList中的Element数组（已加载了第一个dex包，由系统加载），以及DexClassLoader中的DexPathList中的Element数组（刚将第二个dex包加载进去），将两个Element数组合并之后，再将其赋值给PathClassLoader的Element数组，到此，注入完毕。

现在试着启动app，并在TestUrlActivity（在第一个dex包中）中去启动SecondActivity（在第二个dex包中），启动成功。这种方案是可行。

但是使用dex分包方案仍然有几个注意点：

1. 由于第二个dex包是在Application的onCreate中动态注入的，如果dex包过大，会使app的启动速度变慢，因此，在dex分包过程中一定要注意，第二个dex包不宜过大。

2. 由于上述第一点的限制，假如我们的app越来越臃肿和庞大，往往会采取dex分包方案和插件化方案配合使用，将一些非核心独立功能做成插件加载，核心功能再分包加载。

Android开发者应该都遇到了64K最大方法数限制的问题，针对这个问题，google也推出了multidex分包机制，在生成apk的时候，把整个应用拆成n个dex包（classes.dex、classes2.dex、classes3.dex），每个dex不超过64k个方法。使用multidex，在5.0以前的系统，应用安装时只安装main dex（包含了应用启动需要的必要class），在应用启动之后，需在Application的attachBaseContext中调用MultiDex.install(base)方法，在这时候才加载第二、第三…个dex文件，从而规避了64k问题。 
当然，在attachBaseContext方法中直接install启动second dex会有一些问题，比如install方法是一个同步方法，当在主线程中加载的dex太大的时候，耗时会比较长，可能会触发ANR。不过这是另外一个问题了，解决方法可以参考：Android最大方法数和解决方案 http://blog.csdn.net/shensky711/article/details/52329035。

本文主要分析的是MultiDex.install()到底做了什么，如何把secondary dexes中的类动态加载进来。

MultiDex使用到的路径解析

• ApplicationInfo.sourceDir:apk的安装路径，如/data/app/com.hanschen.multidex-1.apk
• Context.getFilesDir()：返回/data/data/<packagename>/files目录，一般通过openFileOutput方法输出文件到该目录
• ApplicationInfo.dataDir: 返回/data/data/<packagename>目录

源码分析

代码入口

代码入口很简单，简单粗暴，就调用了一个静态方法MultiDex.install(base);，传入一个Context对象

    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(base);
    }

MultiDex.install分析

下面是主要的代码

    public static void install(Context context) {
        Log.i("MultiDex", "install");
        if (IS_VM_MULTIDEX_CAPABLE) {
            //VM版本大于2.1时，IS_VM_MULTIDEX_CAPABLE为true，这时候MultiDex.install什么也不用做，直接返回。因为大于2.1的VM会在安装应用的时候，就把多个dex合并到一块
        } else if (VERSION.SDK_INT < 4) {
            //Multi dex最小支持的SDK版本为4
            throw new RuntimeException("Multi dex installation failed. SDK " + VERSION.SDK_INT + " is unsupported. Min SDK version is " + 4 + ".");
        } else {
            try {
                ApplicationInfo e = getApplicationInfo(context);
                if (e == null) {
                    return;
                }
                Set var2 = installedApk;
                synchronized (installedApk) {
                    String apkPath = e.sourceDir;
                    //检测应用是否已经执行过install()了，防止重复install
                    if (installedApk.contains(apkPath)) {
                        return;
                    }
                    installedApk.add(apkPath);
                    //获取ClassLoader，后面会用它来加载second dex
                    DexClassLoader classLoader;
                    ClassLoader loader;
                    try {
                        loader = context.getClassLoader();
                    } catch (RuntimeException var9) {
                        return;
                    }
                    if (loader == null) {
                        return;
                    }
                    //清空目录：/data/data/<packagename>/files/secondary-dexes/，其实我没搞明白这个的作用，因为从后面的代码来看，这个目录是没有使用到的
                    try {
                        clearOldDexDir(context);
                    } catch (Throwable var8) {
                    }
                    File dexDir = new File(e.dataDir, "code_cache/secondary-dexes");
                    //把dex文件缓存到/data/data/<packagename>/code_cache/secondary-dexes/目录，[后有详细分析]
                    List files = MultiDexExtractor.load(context, e, dexDir, false);
                    if (checkValidZipFiles(files)) {
                        //进行安装，[后有详细分析]
                        installSecondaryDexes(loader, dexDir, files);
                    } else {
                        //文件无效，从apk文件中再次解压secondary dex文件后进行安装
                        files = MultiDexExtractor.load(context, e, dexDir, true);
                        if (!checkValidZipFiles(files)) {
                            throw new RuntimeException("Zip files were not valid.");
                        }
                        installSecondaryDexes(loader, dexDir, files);
                    }
                }
            } catch (Exception var11) {
                throw new RuntimeException("Multi dex installation failed (" + var11.getMessage() + ").");
            }
        }
    }

这段代码的主要逻辑整理如下：

1. VM版本检测，如果大于2.1就什么都不做(系统在安装应用的时候已经帮我们把dex合并了)，如果系统SDK版本小于4就抛出运行时异常
2. 把apk中的secondary dexes解压到缓存目录，并把这些缓存读取出来。应用第二次启动的时候，会尝试从缓存目录中读取，除非读取出的文件校验失败，否则不再从apk中解压dexes
3. 根据当前的SDK版本，执行不同的安装方法

先来看看MultiDexExtractor.load(context, e, dexDir, false)

    /**
     * 解压apk文件中的classes2.dex、classes3.dex等文件解压到dexDir目录中
     *
     * @param dexDir      解压目录
     * @param forceReload 是否需要强制从apk文件中解压，否的话会直接读取旧文件
     * @return 解压后的文件列表
     * @throws IOException
     */
    static List<File> load(Context context,
                           ApplicationInfo applicationInfo,
                           File dexDir,
                           boolean forceReload) throws IOException {
        File sourceApk = new File(applicationInfo.sourceDir);
        long currentCrc = getZipCrc(sourceApk);
        List files;
        if (!forceReload && !isModified(context, sourceApk, currentCrc)) {
            try {
                //从缓存目录中直接查找缓存文件，跳过解压
                files = loadExistingExtractions(context, sourceApk, dexDir);
            } catch (IOException var9) {
                files = performExtractions(sourceApk, dexDir);
                putStoredApkInfo(context, getTimeStamp(sourceApk), currentCrc, files.size() + 1);
            }
        } else {
            //把apk中的secondary dex文件解压到缓存目录，并把解压后的文件返回
            files = performExtractions(sourceApk, dexDir);
            //把解压信息保存到sharedPreferences中
            putStoredApkInfo(context, getTimeStamp(sourceApk), currentCrc, files.size() + 1);
        }
        return files;
    }

首先判断以下是否需要强制从apk文件中解压，再进行下CRC校验，如果不需要从apk重新解压，就直接从缓存目录中读取已解压的文件返回，否则解压apk中的classes文件到缓存目录，再把相应的文件返回。这个方法再往下的分析就不贴出来了，不复杂，大家可以自己去看看。读取后会把解压信息保存到sharedPreferences中，里面会保存时间戳、CRC校验和dex数量。

得到dex文件列表后，要做的就是把dex文件关联到应用，这样应用findclass的时候才能成功。这个主要是通过installSecondaryDexes方法来完成的

    /**
     * 安装dex文件
     *
     * @param loader 类加载器
     * @param dexDir 缓存目录，用以存放opt之后的dex文件
     * @param files  需要安装的dex
     * @throws IllegalArgumentException
     * @throws IllegalAccessException
     * @throws NoSuchFieldException
     * @throws InvocationTargetException
     * @throws NoSuchMethodException
     * @throws IOException
     */
    private static void installSecondaryDexes(ClassLoader loader,
                                              File dexDir,
                                              List<File> files) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
        if (!files.isEmpty()) {
            //对不同版本的SDK做不同处理
            if (VERSION.SDK_INT >= 19) {
                MultiDex.V19.install(loader, files, dexDir);
            } else if (VERSION.SDK_INT >= 14) {
                MultiDex.V14.install(loader, files, dexDir);
            } else {
                MultiDex.V4.install(loader, files);
            }
        }
    }

可以看到，对于不同的SDK版本，分别采用了不同的处理方法，我们主要分析SDK>=19的情况，其他情况大同小异，读者可以自己去分析。

    private static final class V19 {
        private V19() {
        }
        /**
         * 安装dex文件
         *
         * @param loader                     类加载器
         * @param additionalClassPathEntries 需要安装的dex
         * @param optimizedDirectory         缓存目录，用以存放opt之后的dex文件
         * @throws IllegalArgumentException
         * @throws IllegalAccessException
         * @throws NoSuchFieldException
         * @throws InvocationTargetException
         * @throws NoSuchMethodException
         */
        private static void install(ClassLoader loader,
                                    List<File> additionalClassPathEntries,
                                    File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException {
            //通过反射获取ClassLoader对象中的pathList属性，其实是ClassLoader的父类BaseDexClassLoader中的成员
            Field pathListField = MultiDex.findField(loader, "pathList");
            //通过属性获取该属性的值，该属性的类型是DexPathList
            Object dexPathList = pathListField.get(loader);
            ArrayList suppressedExceptions = new ArrayList();
            //通过反射调用dexPathList的makeDexElements返回Element对象数组。方法里面会读取每一个输入文件，生成DexFile对象，并将其封装进Element对象
            Object[] elements = makeDexElements(dexPathList, new ArrayList(additionalClassPathEntries), optimizedDirectory, suppressedExceptions);
            //将elements数组跟dexPathList对象的dexElements数组合并，并把合并后的数组作为dexPathList新的值
            MultiDex.expandFieldArray(dexPathList, "dexElements", elements);
            //处理异常
            if (suppressedExceptions.size() > 0) {
                Iterator suppressedExceptionsField = suppressedExceptions.iterator();
                while (suppressedExceptionsField.hasNext()) {
                    IOException dexElementsSuppressedExceptions = (IOException) suppressedExceptionsField.next();
                    Log.w("MultiDex", "Exception in makeDexElement", dexElementsSuppressedExceptions);
                }
                Field suppressedExceptionsField1 = MultiDex.findField(loader, "dexElementsSuppressedExceptions");
                IOException[] dexElementsSuppressedExceptions1 = (IOException[]) ((IOException[]) suppressedExceptionsField1.get(loader));
                if (dexElementsSuppressedExceptions1 == null) {
                    dexElementsSuppressedExceptions1 = (IOException[]) suppressedExceptions.toArray(new IOException[suppressedExceptions
                            .size()]);
                } else {
                    IOException[] combined = new IOException[suppressedExceptions.size() + dexElementsSuppressedExceptions1.length];
                    suppressedExceptions.toArray(combined);
                    System.arraycopy(dexElementsSuppressedExceptions1, 0, combined, suppressedExceptions.size(), dexElementsSuppressedExceptions1.length);
                    dexElementsSuppressedExceptions1 = combined;
                }
                suppressedExceptionsField1.set(loader, dexElementsSuppressedExceptions1);
            }
        }
        private static Object[] makeDexElements(Object dexPathList,
                                                ArrayList<File> files,
                                                File optimizedDirectory,
                                                ArrayList<IOException> suppressedExceptions) throws IllegalAccessException, InvocationTargetException, NoSuchMethodException {
            Method makeDexElements = MultiDex.findMethod(dexPathList, "makeDexElements", new Class[]{ArrayList.class, File.class, ArrayList.class});
            return (Object[]) ((Object[]) makeDexElements.invoke(dexPathList, new Object[]{files, optimizedDirectory, suppressedExceptions}));
        }
    }

在Android中，有两个ClassLoader，分别是DexClassLoader和PathClassLoader，它们的父类都是BaseDexClassLoader，DexClassLoader和PathClassLoader的实现都是在BaseDexClassLoader之中，而BaseDexClassLoader的实现又基本是通过调用DexPathList的方法完成的。DexPathList里面封装了加载dex文件为DexFile对象（调用了native方法，有兴趣的童鞋可以继续跟踪下去）的方法。 
上述代码中的逻辑如下：

1. 通过反射获取pathList对象
2. 通过pathList把输入的dex文件输出为elements数组，elements数组中的元素封装了DexFile对象
3. 把新输出的elements数组合并到原pathList的dexElements数组中
4. 异常处理

当把dex文件加载到pathList的dexElements数组之后，整个multidex.install基本上就完成了。 
但可能还有些童鞋还会有些疑问，仅仅只是把Element数组合并到ClassLoader就可以了吗？还是没有找到加载类的地方啊？那我们再继续看看，当用到一个类的时候，会用ClassLoader去加载一个类，加载类会调用类加载器的findClass方法

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
        //调用pathList的findClass方法
        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;
    }

于是继续跟踪：

    public Class findClass(String name, List<Throwable> suppressed) {
        //遍历dexElements数组
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;
            if (dex != null) {
                //继续跟踪会发现调用的是一个native方法
                Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        if (dexElementsSuppressedExceptions != null) {
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }

到现在就清晰了，当加载一个类的时候，会遍历dexElements数组，通过native方法从Element元素中加载类名相应的类

总结下整个multidex.install流程，其实很简单，就做了一件事情，把apk中的secondary dex文件通过ClassLoader转换成Element数组，并把输出的数组合与ClassLoader的Element数组合并。

通常情况下，dexElements数组中只会有一个元素，就是apk安装包中的classes.dex 
而我们则可以通过反射，强行的将一个外部的dex文件添加到此dexElements中，这就是dex的分包原理了。 
这也是热补丁修复技术的原理。

三、热补丁修复技术的原理

上面的源码，我们注意到一点，如果两个dex中存在相同的class文件会怎样？ 
先从第一个dex中找，找到了直接返回，遍历结束。而第二个dex中的class永远不会被加载进来。 
简而言之，两个dex中存在相同class的情况下，dex1的class会覆盖dex2的class。 
盗一下QQ空间的图，如图：classes1.dex中的Qzone.class并不会被加载 

而热补丁技术则利用了这一特性，当一个app出现bug的时候，我们就可以将出现那个bug的类修复后，重新编译打包成dex，插入到dexElements的前面，那么出现bug的类就会被覆盖，app正常运行，这就是热修复的原理了。