应用方法数超过65535-Multidex的解决方案

Multidex的解决方案

今天写的内容主要是针对公司的项目中，方法数超过65535的问题，并给出解决方案。
本文是在前人的基础上稍作总结，具体见文末。

multidex起因

应用中的Dex 文件方法数超过了最大值65536的上限,简单来说，应用爆棚了，报错如下：

UNEXPECTED TOP-LEVEL EXCEPTION:java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536

排查过程

出现这个问题很自然的想到了google给提出的补丁方案（本地由源码的话，在把网址改成sdk对应路径即可，例如：file:///C:/Android/sdk/docs/tools/building/multidex.html）

第一步：添加gradle配置(引入的multidex包，如果没网的情况下，请下载引入)：

defaultConfig {    applicationId "com.rytong.app.bankhx"    minSdkVersion 8    targetSdkVersion 8    multiDexEnabled true}dependencies {    compile 'com.android.support:multidex:1.0.1'}

第二步：在Application中重写attachBaseContext方法，具体代码如下：

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

到这个时候，我发现，运行项目app百分百ANR，百度后认为是google官方的补丁方案的bug，于是进行下面的第三步。

第三步：官方文档中提到的补丁方案的局限

大致意思如下：
1. 在安卓应用时，如果应用比较大，第二个dex文件过大，可能会导致ANR，请用ProGuard优化代码；
2. 使用了multidex的app可能在系统版本在4.0以下的手机启动失败，请多多测试，并使用ProGuard优化代码减少bug发生的几率；
3. 使用了mulitDex的App在runtime期间有可能因为Dalvik linearAlloc limit Crash。该内存分配限制在 4.0版本被增大，但是5.0以下的机器上的Apps依然会存在这个限制；
4. 在主dex执行时，需要保证一些类必须在主dex中，build tools 可以搞定这个问题。但是如果你代码存在反射和native的调用也不保证100%正确。

第四步：基于官方的文档中的限制，4.0以下的手机暂不做处理，4.0以上，5.0以下采用网上的方案，加载classes2.dex（原因是Facebook、美团、微信等团队实践后都认为在启动过程中classes2.dex加载占用时间过长），因此采用以下的方案，解决该问题。

由于代码较多，在本文档中不做过多阐述，以附件形式提供。在application启动时，启动一个新的activity加载classes2.dex，加载完之后再调用Application的onCreate方法启用应用。

具体流程图如下：

关键代码如下：

 @Overrideprotected void attachBaseContext(Context base) {    super .attachBaseContext(base);    Log.e( "attachBaseContext", "App attachBaseContext ");    if (!quickStart() && Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) {//>=5.0的系统默认对dex进行oat优化        if (needWait(base)){            Log.e( "attachBaseContext", "needWait");            waitForDexopt(base);        }        Log.e( "attachBaseContext", "MultiDex.install");        MultiDex.install (this );    } else {        return;    }}public void waitForDexopt(Context base) {    Intent intent = new Intent();    ComponentName componentName = new            ComponentName( "com.rytong.app.bankhx", "com.rytong.newengine.LoadResActivity");//                ComponentName( "com.bank.hx", LoadResActivity.class.getName());    intent.setComponent(componentName);    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);    base.startActivity(intent);    long startWait = System.currentTimeMillis ();    long waitTime = 10 * 1000 ;    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB_MR1 ) {        waitTime = 20 * 1000 ;//实测发现某些场景下有些2.3版本有可能10s都不能完成optdex    }    while (needWait(base)) {        try {            long nowWait = System.currentTimeMillis() - startWait;            Log.d("loadDex" , "wait ms :" + nowWait);            if (nowWait >= waitTime) {                return;            }            Thread.sleep(200);        } catch (InterruptedException e) {            e.printStackTrace();        }    }}//neead wait for dexopt ?private boolean needWait(Context context){    String flag = get2thDexSHA1(context);    Log.d( "loadDex", "dex2-sha1 "+flag);    SharedPreferences sp = context.getSharedPreferences(            PackageUtil.getPackageInfo(context). versionName, MODE_MULTI_PROCESS);    String saveValue = sp.getString(KEY_DEX2_SHA1, "");    Log.e( "needWait", flag+"..."+saveValue);    if (!TextUtils.isEmpty(flag)) {        return !flag.equals(saveValue);    }else if(!TextUtils.isEmpty(saveValue)){        return !saveValue.equals(flag);    }    return true;}/** * Get classes.dex file signature * @param context * @return */private String get2thDexSHA1(Context context) {    ApplicationInfo ai = context.getApplicationInfo();    String source = ai.sourceDir;    try {        JarFile jar = new JarFile(source);        Manifest mf = jar.getManifest();        Map<String, Attributes> map = mf.getEntries();        Attributes a = map.get("classes2.dex");        return a.getValue("SHA1-Digest");    } catch (Exception e) {        e.printStackTrace();    }    return null ;}public boolean quickStart() {    if (!TextUtils.isEmpty(getCurProcessName(this))) {        Log.d( "loadDex", ":mini start!");        return getCurProcessName(this).contains(":mini");    }    return false ;}public static String getCurProcessName(Context context) {    try {        int pid = android.os.Process.myPid();        ActivityManager mActivityManager = (ActivityManager) context                .getSystemService(Context. ACTIVITY_SERVICE);        for (ActivityManager.RunningAppProcessInfo appProcess : mActivityManager                .getRunningAppProcesses()) {            if (appProcess.pid == pid) {                return appProcess. processName;            }        }    } catch (Exception e) {        // ignore    }    return null ;}

验证结果

第一步：在做完以上操作后，发现启动华夏银行app仍然100%ANR，我在想是不是因为我的方案没作用？因为我都输出日志了，并且执行到了MultiDex.install (this)，报文都打印出来后ANR的。

第二步：排查应用启动Activity中是否做了阻塞线程的操作。

经排查发现，在启动Activity里面做了很多内容的初始化，比如

• 初始化统计的接口
• 开启推送服务
• 开启hce推送
• 注册广播或者一些监听
• 打开ViewServer等

我将其中一部分注释掉后，app正常运行。在4.0以上5.0以下手机上，第一次安装或者覆盖安装第一次启动会显示loading页面3s左右，所以，能不用该方案则不用。（multidex方案大同小异，没有任何方案一点牺牲都不做的。）

结论　

在经过此番排查后发现其实我们只需要按照google的标准做法即可，优化启动Activity中阻塞线程操作，就不会出现ANR（也就是说这个方案有可能都用不上）。
如果有65535问题，则建议项目上如此处理：
1. 按照google官方文档添加配置，在Application中添加相应代码；
2. 优化启动Activity中的阻塞线程操作，关闭或者放到异步线程执行。

附录

1. 其实你不知道MultiDex到底有多坑：http://blog.zongwu233.com/the-touble-of-multidex
2. 美团Android DEX自动拆包及动态加载简介：http://tech.meituan.com/mt-android-auto-split-dex.html
3. Android拆分与加载Dex的多种方案对比：http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207151651&idx=1&sn=9eab282711f4eb2b4daf2fbae5a5ca9a&3rd=MzA3MDU4NTYzMw==&scene=6#rd