Android DEX自动拆包及动态加载简介

概述

作为一个android开发者，在开发应用时，随着业务规模发展到一定程度，不断地加入新功能、添加新的类库，代码在急剧的膨胀，相应的apk包的大小也急剧增加，那么终有一天，你会不幸遇到这个错误：

生成的apk在android 2.3或之前的机器上无法安装，提示INSTALL_FAILED_DEXOPT
方法数量过多，编译时出错，提示：

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

而问题产生的具体原因如下：

无法安装（Android 2.3 INSTALL_FAILED_DEXOPT）问题，是由dexopt的LinearAlloc限制引起的，在Android版本不同分别经历了4M/5M/8M/16M限制，目前主流4.2.x系统上可能都已到16M，在Gingerbread或者以下系统LinearAllocHdr分配空间只有5M大小的，高于Gingerbread的系统提升到了8M。Dalvik linearAlloc是一个固定大小的缓冲区。在应用的安装过程中，系统会运行一个名为dexopt的程序为该应用在当前机型中运行做准备。dexopt使用LinearAlloc来存储应用的方法信息。Android 2.2和2.3的缓冲区只有5MB，Android 4.x提高到了8MB或16MB。当方法数量过多导致超出缓冲区大小时，会造成dexopt崩溃。
超过最大方法数限制的问题，是由于DEX文件格式限制，一个DEX文件中method个数采用使用原生类型short来索引文件中的方法，也就是4个字节共计最多表达65536个method，field/class的个数也均有此限制。对于DEX文件，则是将工程所需全部class文件合并且压缩到一个DEX文件期间，也就是Android打包的DEX过程中，单个DEX文件可被引用的方法总数（自己开发的代码以及所引用的Android框架、类库的代码）被限制为65536；

插件化？ MultiDex？

首先使用Android SDK Manager升级到最新的Android SDK Build Tools和Android Support Library。然后进行以下两步操作：

修改Gradle配置文件，启用MultiDex并包含MultiDex支持：

android { 
         compileSdkVersion 21 buildToolsVersion "21.1.0" 
         defaultConfig { 
                ... 
               minSdkVersion 14 
               targetSdkVersion 21 
               ... 

               // Enabling MultiDex support. 
               MultiDexEnabled true 
         } 
          ... 
} 
dependencies { 
         compile 'com.android.support:MultiDex:1.0.0'
}

让应用支持多DEX文件。在官方文档中描述了三种可选方法：
在AndroidManifest.xml的application中声明android.support.MultiDex.MultiDexApplication；
如果你已经有自己的Application类，让其继承MultiDexApplication；
如果你的Application类已经继承自其它类，你不想/能修改它，那么可以重写attachBaseContext()方法：

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

并在Manifest中添加以下声明：

<?xml version="1.0" encoding="utf-8"?> 
    <manifest  package="com.example.android.MultiDex.myapplication"> 
        <application 
        ... 
        android:name="android.support.MultiDex.MultiDexApplication">
        ... 
        </application> 
    </manifest>

如果已经有自己的Application，则让其继承MultiDexApplication即可.

Dex自动拆包及动态加载

MultiDex带来的问题

在第一版本采用MultiDex方案上线后，在Dalvik下带来了下列几个问题：
在冷启动时因为需要安装DEX文件，如果DEX文件过大时，处理时间过长，很容易引发ANR（Application Not Responding）；
采用MultiDex方案的应用可能不能在低于Android 4.0 (API level 14) 机器上启动，这个主要是因为Dalvik linearAlloc的一个bug ();
采用MultiDex方案的应用因为需要申请一个很大的内存，在运行时可能导致程序的崩溃，这个主要是因为Dalvik linearAlloc 的一个限制(). 这个限制在 Android 4.0 (API level 14)已经增加了, 应用也有可能在低于 Android 5.0 (API level 21)版本的机器上触发这个限制；

下面代码片段是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) { 
    }
}

Dex自动拆包及动态加载方案简介

在打包过程中如何产生多个的DEX包？
如果做到动态加载，怎么决定哪些DEX动态加载呢？
如果启动后在工作线程中做动态加载，如果没有加载完而用户进行页面操作需要使用到动态加载DEX中的class怎么办？

我们首先来分析如何解决第一个问题，在使用MultiDex方案时，我们知道BuildTool会自动把代码进行拆成多个DEX包，并且可以通过配置文件来控制哪些代码放到第一个DEX包中，下图是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运行正常。

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;
}

总结

上面就是我们在使用MultiDex过程中进化而来的DEX自动化拆包的方案，这样我们就可以通过脚本控制来进行自动化的拆分DEX，然后在运行时自由的加载Secondary DEX，既能保证冷启动速度，又能减少运行时的内存占用。