美團Android DEX自動拆包及動態加載簡介

jopen 9年前發布 | 119K 次閱讀 Android Android開發移動開發

概述

作為一個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，filed/class的個數也均有此限制。對于DEX文件，則是將工程所需全部class文件合并且壓縮到一個DEX文件期間，也就是Android打包的DEX過程中，單個DEX文件可被引用的方法總數（自己開發的代碼以及所引用的Android框架、類庫的代碼）被限制為65536；

插件化？ MultiDex？

解決這個問題，一般有下面幾種方案，一種方案是加大Proguard的力度來減小DEX的大小和方法數，但這是治標不治本的方案，隨著業務代碼的添加，方法數終究會到達這個限制，一種比較流行的方案是插件化方案，另外一種是采用google提供的MultiDex方案，以及google在推出MultiDex之前Android Developers博客介紹的通過自定義類加載過程，再就是非死book推出的為Android應用開發的Dalvik補丁，但非死book博客里寫的不是很詳細；我們在插件化方案上也做了探索和嘗試，發現部署插件化方案，首先需要梳理和修改各個業務線的代碼，使之解耦，改動的面和量比較巨大，通過一定的探討和分析，我們認為對我們目前來說采用MultiDex方案更靠譜一些，這樣我們可以快速和簡潔的對代碼進行拆分，同時代碼改動也在可以接受的范圍內；這樣我們采用了google提供的MultiDex方式進行了開發。

插件化方案在業內有不同的實現原理，這里不再一一列舉，這里只列舉下Google為構建超過65K方法數的應用提供官方支持的方案：MultiDex。

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

1.修改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'
}

2.讓應用支持多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 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，則讓其繼承MultiDexApplication即可.

Dex自動拆包及動態加載

MultiDex帶來的問題

在第一版本采用MultiDex方案上線后，在Dalvik下MultiDex帶來了下列幾個問題：

在冷啟動時因為需要安裝DEX文件，如果DEX文件過大時，處理時間過長，很容易引發ANR（Application Not Responding）；
采用MultiDex方案的應用可能不能在低于Android 4.0 (API level 14) 機器上啟動，這個主要是因為Dalvik linearAlloc的一個bug (Issue 22586);
采用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的區別.

MultiDex的基本原理是把通過DexFile來加載Secondary DEX，并存放在BaseDexClassLoader的DexPathList中。

下面代碼片段是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自動拆包及動態加載方案簡介

通過查看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)和限制(Issue 78035)，我們考慮是否可以人工對DEX的拆分進行干預，使每個DEX的大小在一定的合理范圍內，這樣就減少觸發Dalvik linearAlloc的缺陷和限制；為了實現這幾個目的，我們需要解決下面三個問題：

在打包過程中如何產生多個的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運行正常。

隨著第二個問題的迎刃而解，我們來到了比較棘手的第三問題，如果我們在后臺加載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官方說明，這樣在最終打包時Library中的R沒法做到內聯，這樣帶來了R field過多的情況，導致需要拆分多個Secondary DEX，為了解決這個問題我們采用的是在打包過程中利用腳本把Libray中R filed（例如ID、Layout、Drawable等）的引用替換成常量，然后刪去Library中R.class中的相應Field。

總結

上面就是我們在使用MultiDex過程中進化而來的DEX自動化拆包的方案，這樣我們就可以通過腳本控制來進行自動化的拆分DEX，然后在運行時自由的加載Secondary DEX，既能保證冷啟動速度，又能減少運行時的內存占用。

來自：http://tech.meituan.com/mt-android-auto-split-dex.html

本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1434350910895.html

Android Android開發移動開發

美團Android DEX自動拆包及動態加載簡介

概述

插件化？ MultiDex？

Dex自動拆包及動態加載

MultiDex帶來的問題

Dex自動拆包及動態加載方案簡介

總結

相關經驗

相關資訊

相關文檔

目錄