#### **背景** 随着应用不断迭代，业务线的扩展,应用越来越大(比如集成了各种第三方sdk或者公共支持的jar包,项目耦合性高，重复作用的类越来越多)，相信很多人都遇到过如下的错误: ~~~ UNEXPECTED TOP-LEVEL EXCEPTION: java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536 at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:501) at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:282) at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:490) at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:167) at com.android.dx.merge.DexMerger.merge(DexMerger.java:188) at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439) at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287) at com.android.dx.command.dexer.Main.run(Main.java:230) at com.android.dx.command.dexer.Main.main(Main.java:199) at com.android.dx.command.Main.main(Main.java:103) ~~~ 没错，**你的应用中的Dex 文件方法数超过了最大值65536的上限,简单来说，应用爆棚了**。 那么让我们看一下为什么会引起这种错误: 在Android系统中，一个App的所有代码都在一个Dex文件里面。Dex是一个类似Jar的存储了多有Java编译字节码的归档文件。因为Android系统使用Dalvik虚拟机，所以需要把使用Java Compiler编译之后的class文件转换成Dalvik能够执行的class文件。这里需要强调的是，Dex和Jar一样是一个归档文件，里面仍然是Java代码对应的字节码文件。当Android系统启动一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。 但是在早期的Android系统中，DexOpt的LinearAlloc存在着限制: Android 2.2和2.3的缓冲区只有5MB，Android 4.x提高到了8MB或16MB。**当方法数量过多（方法数可能并没有超过65536上限）导致超出缓冲区大小时，会造成dexopt崩溃,导致无法安装**。 另外由于DEX文件格式限制，一个DEX文件中method个数采用使用原生类型short来索引文件中的方法，也就是最多表达65536个method，field/class的个数也均有此限制。对于DEX文件，则是将工程所需全部class文件合并且压缩到一个DEX文件期间，也就是**Android打包的DEX过程中， 单个DEX文件可被引用的方法总数被限制为65536（自己开发以及所引用的Android Framework和第三方类库的代码）**。 #### **解决方案** 目前比较常用的方法： (1) 应用插件化,比如使用[任玉刚](http://blog.csdn.net/singwhatiwanna)参与开发的插件化框架 :[DL : Apk动态加载框架](https://github.com/singwhatiwanna/dynamic-load-apk ) (2) 分割Dex,多工程: 把所需要的.class文件或者是Jar文件和一些源码一起编译生成一个Jar文件。然后使用Android SDK提供的dx工具把Jar文件转成Dex文件。(可参考facebook：[Under the Hood: Dalvik patch for Facebook for Android](https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920)，这里边还可以看到在2.3上动态改变LinearAlloc缓冲的解决思路) 这两种方法并不冲突,**插件化除了解决应用爆棚，还有很多其他的优点**。 当然,Google看来也意识到了目前应用方法数爆棚的问题, 目前在已经在API 21（Android 5.0）中提供了通用的解决方案，那就是android-support-multidex.jar. 这个jar包最低可以支持到API 4的版本(Android L及以上版本会默认支持mutidex). #### **Dex自动拆包及动态加载** **MultiDex带来的问题** 在第一版本采用MultiDex方案上线后，在Dalvik下[MultiDex](https://android.googlesource.com/platform/frameworks/MultiDex/)带来了下列几个问题： 1. 在冷启动时因为需要安装DEX文件，如果DEX文件过大时，处理时间过长，很容易引发ANR（Application Not Responding）； 2. 采用MultiDex方案的应用可能不能在低于Android 4.0 (API level 14) 机器上启动，这个主要是因为Dalvik linearAlloc的一个bug (Issue 22586); 3. 采用MultiDex方案的应用因为需要申请一个很大的内存，在运行时可能导致程序的崩溃，这个主要是因为Dalvik linearAlloc 的一个限制(Issue 78035). 这个限制在 Android 4.0 (API level 14)已经增加了, 应用也有可能在低于 Android 5.0 (API level 21)版本的机器上触发这个限制； 而在ART下MultiDex是不存在这个问题的，这主要是因为ART下采用Ahead-of-time (AOT) compilation技术，系统在APK的安装过程中会使用自带的dex2oat工具对APK中可用的DEX文件进行编译并生成一个可在本地机器上运行的文件，这样能提高应用的启动速度，因为是在安装过程中进行了处理这样会影响应用的安装速度，对ART感兴趣的可以参考一下[ART和Dalvik的区别](https://source.android.com/devices/tech/dalvik/index.html). MultiDex的基本原理是把通过DexFile来加载Secondary DEX，并存放在BaseDexClassLoader的DexPathList中。 **BaseDexClassLoader：findClass** ~~~ @Override 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中： **下面的这个方法暂时还没有找到出处，不知道是不是美团的Robust框架中** ~~~ 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) { } } ~~~ **Dex自动拆包及动态加载方案简介** 通过查看MultiDex的源码，我们发现MultiDex在冷启动时容易导致ANR的瓶颈， 在2.1版本之前的Dalvik的VM版本中， MultiDex的安装大概分为几步，第一步打开apk这个zip包，第二步把MultiDex的dex解压出来（除去Classes.dex之外的其他DEX，例如：classes2.dex， classes3.dex等等)，因为android系统在启动app时只加载了第一个Classes.dex，其他的DEX需要我们人工进行安装，第三步通过反射进行安装，这三步其实都比较耗时， 为了解决这个问题我们**考虑是否可以把DEX的加载放到一个异步线程中，这样冷启动速度能提高不少，同时能够减少冷启动过程中的ANR，对于Dalvik linearAlloc的一个缺陷([Issue 22586](http://b.android.com/22586))和限制([Issue 78035](http://b.android.com/78035))，我们考虑是否可以人工对DEX的拆分进行干预，使每个DEX的大小在一定的合理范围内，这样就减少触发Dalvik linearAlloc的缺陷和限制**； 为了实现这几个目的，我们需要解决下面三个问题： 1. 在打包过程中如何产生多个的DEX包？ 2. 如果做到动态加载，怎么决定哪些DEX动态加载呢？ 3. 如果启动后在工作线程中做动态加载，如果没有加载完而用户进行页面操作需要使用到动态加载DEX中的class怎么办？ 我们首先来分析如何解决第一个问题，在使用MultiDex方案时，我们知道BuildTool会自动把代码进行拆成多个DEX包，并且可以通过配置文件来控制哪些代码放到第一个DEX包中， 下图是Android的打包流程示意图：  图 1 Android的打包流程示意图 为了实现产生多个DEX包，我们可以在生成DEX文件的这一步中， 在Ant或gradle中自定义一个Task来干预DEX产生的过程，从而产生多个DEX，下图是在ant和gradle中干预产生DEX的自定task的截图: ~~~ tasks.whenTaskAdded { task -> if (task.name.startsWith('proguard') && (task.name.endsWith('Debug') || task.name.endsWith('Release'))) { task.doLast { makeDexFileAfterProguardJar(); } task.doFirst { delete "${project.buildDir}/intermediates/classes-proguard"; String flavor = task.name.substring('proguard'.length(), task.name.lastIndexOf(task.name.endsWith('Debug') ? "Debug" : "Release")); generateMainIndexKeepList(flavor.toLowerCase()); } } else if (task.name.startsWith('zipalign') && (task.name.endsWith('Debug') || task.name.endsWith('Release'))) { task.doFirst { ensureMultiDexInApk(); } } } ~~~ 上一步解决了如何打包出多个DEX的问题了，那我们**该怎么该根据什么来决定哪些class放到Main DEX，哪些放到Secondary DEX呢**（这里的Main DEX是指在2.1版本的Dalvik VM之前由android系统在启动apk时自己主动加载的Classes.dex，而**Secondary DEX是指需要我们自己安装进去的DEX，例如：Classes2.dex, Classes3.dex等）**， 这个需要分析出**放到Main DEX中的class依赖，需要确保把Main DEX中class所有的依赖都要放进来，否则在启动时会发生ClassNotFoundException**, 这里我们的**方案是把Service、Receiver、Provider涉及到的代码都放到Main DEX中，而把Activity涉及到的代码进行了一定的拆分，把首页Activity、Laucher Activity、欢迎页的Activity、城市列表页Activity等所依赖的class放到了Main DEX中，把二级、三级页面的Activity以及业务频道的代码放到了Secondary DEX中，为了减少人工分析class的依赖所带了的不可维护性和高风险性，我们编写了一个能够自动分析Class依赖的脚本， 从而能够保证Main DEX包含class以及他们所依赖的所有class都在其内，这样这个脚本就会在打包之前自动分析出启动到Main DEX所涉及的所有代码，保证Main DEX运行正常。** 随着第二个问题的迎刃而解，我们来到了比较棘手的**第三问题，如果我们在后台加载Secondary DEX过程中，用户点击界面将要跳转到使用了在Secondary DEX中class的界面， 那此时必然发生ClassNotFoundException**, 那怎么解决这个问题呢，在所有的Activity跳转代码处添加判断Secondary DEX是否加载完成？这个方法可行，但工作量非常大； 那有没有更好的解决方案呢？我们**通过分析Activity的启动过程，发现Activity是由ActivityThread 通过Instrumentation来启动的，我们是否可以在Instrumentation中做一定的手脚呢？通过分析代码ActivityThread和Instrumentation发现，Instrumentation有关Activity启动相关的方法大概有：execStartActivity、newActivity等等，这样我们就可以在这些方法中添加代码逻辑进行判断这个Class是否加载了，如果加载则直接启动这个Activity，如果没有加载完成则启动一个等待的Activity显示给用户，然后在这个Activity中等待后台Secondary DEX加载完成，完成后自动跳转到用户实际要跳转的Activity；这样在代码充分解耦合，以及每个业务代码能够做到颗粒化的前提下，我们就做到Secondary DEX的按需加载了**， 下面是Instrumentation添加的部分关键代码： ~~~ public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode) { ActivityResult activityResult = null; String className; if (intent.getComponent() != null) { className = intent.getComponent().getClassName(); } else { ResolveInfo resolveActivity = who.getPackageManager().resolveActivity(intent, 0); if (resolveActivity != null && resolveActivity.activityInfo != null) { className = resolveActivity.activityInfo.name; } else { className = null; } } if (!TextUtils.isEmpty(className)) { boolean shouldInterrupted = !MeituanApplication.isDexAvailable(); if (MeituanApplication.sIsDexAvailable.get() || mByPassActivityClassNameList.contains(className)) { shouldInterrupted = false; } if (shouldInterrupted) { Intent interruptedIntent = new Intent(mContext, WaitingActivity.class); activityResult = execStartActivity(who, contextThread, token, target, interruptedIntent, requestCode); } else { activityResult = execStartActivity(who, contextThread, token, target, intent, requestCode); } } else { activityResult = execStartActivity(who, contextThread, token, target, intent, requestCode); } return activityResult; } public Activity newActivity(Class<?> clazz, Context context, IBinder token, Application application, Intent intent, ActivityInfo info, CharSequence title, Activity parent, String id, Object lastNonConfigurationInstance) throws InstantiationException, IllegalAccessException { String className = ""; Activity newActivity = null; if (intent.getComponent() != null) { className = intent.getComponent().getClassName(); } boolean shouldInterrupted = !MeituanApplication.isDexAvailable(); if (MeituanApplication.sIsDexAvailable.get() || mByPassActivityClassNameList.contains(className)) { shouldInterrupted = false; } if (shouldInterrupted) { intent = new Intent(mContext, WaitingActivity.class); newActivity = mBase.newActivity(clazz, context, token, application, intent, info, title, parent, id, lastNonConfigurationInstance); } else { newActivity = mBase.newActivity(clazz, context, token, application, intent, info, title, parent, id, lastNonConfigurationInstance); } return newActivity; } ~~~ 实际应用中我们还遇到另外一个比较棘手的问题， 就是**Field的过多的问题**，Field过多是由我们目前采用的代码组织结构引入的，我们为了方便多业务线、多团队并发协作的情况下开发，我们采用的aar的方式进行开发，并同时在aar依赖链的最底层引入了一个通用业务aar，而这个通用业务aar中包含了很多资源，而ADT14以及更高的版本中对Library资源处理时，Library的R资源不再是static final的了，[详情请查看google官方说明](http://tools.android.com/tips/non-constant-fields)，这样在最终打包时Library中的R没法做到内联，这样**带来了R field过多的情况，导致需要拆分多个Secondary DEX**，**为了解决这个问题**我们采用的是**在打包过程中利用脚本把Libray中R field（例如ID、Layout、Drawable等）的引用替换成常量，然后删去Library中R.class中的相应Field**。 #### **总结** 上面就是我们在使用MultiDex过程中进化而来的DEX自动化拆包的方案， 这样我们就可以通过脚本控制来进行自动化的拆分DEX，然后在运行时自由的加载Secondary DEX，既能保证冷启动速度，又能减少运行时的内存占用。 #### **参考文章** [美团Android DEX自动拆包及动态加载简介](https://tech.meituan.com/mt-android-auto-split-dex.html) [Android 使用android-support-multidex解决Dex超出方法数的限制问题,让你的应用不再爆棚](http://blog.csdn.net/t12x3456/article/details/40837287) [使用Multidex来解决方法数越界](https://www.kancloud.cn/alex_wsc/artist/481985) [Google官网——配置方法数超过 64K 的应用](https://developer.android.com/tools/building/multidex.html#mdex-gradle) [Multi-dex to rescue from the infamous 65536 methods limit](http://blog.osom.info/2014/10/multi-dex-to-rescue-from-infamous-65536.html) [dex分包变形记](http://dev.qq.com/topic/5913db5c29d8be2a14b64da8) [Android拆分与加载Dex的多种方案对比](http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207151651&idx=1&sn=9eab282711f4eb2b4daf2fbae5a5ca9a&3rd=MzA3MDU4NTYzMw==&scene=6#rd)