Android 突破64K方法數的限制

laphere 8年前發布 | 5K 次閱讀安卓開發 Android開發移動開發

隨著安卓平臺的不斷發展與壯大，市場上大而全的應用比比皆是，產品需求的變更累積和UI交互的極致追求，除了 resources 文件的俱增，在 Android Project 中依賴的 Library 和自己寫的 Java 代碼也會越來越多。這些變化，除了會導致打包出的 APK 文件越來越大之外，當項目中java代碼包含的方法數（method count）超出一個峰值時，編譯過程中就會出現如下錯誤：

較早版本的編譯系統中，錯誤內容如下：

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

較新版本的編譯系統中，錯誤內容如下：

trouble writing output:
Too many field references: 131000; max is 65536.
You may try using --multi-dex option.

盡管在不同版本的編譯系統中顯示的錯誤內容不盡相同，但都提到了一個具體的數字：65536，也就是本文要講到的核心內容，Android 64K Method Counts Limit 的峰值。詳細信息，參考官網用戶指南： Configure Apps with Over 64K Methods

Android 64K Method Counts Limit

Android Project 經過編譯打包，其中的Java代碼（包括Library）轉化為DEX格式的字節碼文件，這是Android 5.0之前的Dalvik虛擬機決定的（5.0之后改為ART虛擬機），并且采用short類型引用DEX文件中的method，這也為method數量的峰值大小埋下了隱患。short類型能夠表示的最大值是65536，也就說單個DEX文件中最多只有65536個method能夠得到引用，如果代碼執行了超出部分的method引用，自然會報錯，如methodNotFound等。1K等于1024，65536剛好是64K，為了便于稱呼和使用，就將這個限制統稱為64K方法數的引用限制。

為了解決64K方法數限制的問題，我們可以在項目中使用multidex配置，當項目中的方法數（包括：Android framework，library和我們自己寫的代碼）超過64K時，編譯系統會自動編譯出多個DEX文件。

Multidex Support

Android 5.0之前，安卓系統采用的是Dalvik虛擬機，采用的是JIT技術（Just-in-time compilation，即時編譯，運行時編譯DEX字節碼文件，這也是以前為什么安卓手機用戶總是詬病Android系統比iOS系統運行卡頓的原因），限制每個APK文件只能包含一個DEX文件（即 classes.dex ）。為了繞開這個限制，Google給我們提供了 multidex support library 兼容包，幫助我們實現應用程序加載多個DEX文件，并且這個兼容包作為程序的主DEX文件，管理者其他DEX文件的訪問。

注意：由于 Instant Run 機制利用的就是multidex原理，當項目中 minSdkVersion 參數設置為20或者更小，并且運行在Android 4.4 (API level 20)或更低版本的設備中時， Instant Run 將失效。

Android 5.0之后，安卓系統改用了ART虛擬機（Android RunTime），采用的是OAT技術（Ahead-of-time，預編譯，在應用安裝的時候掃描應用中的所有DEX文件，并編譯成一個 .oat 格式的文件供安卓設備執行，所以相比Dalvik虛擬機下的應用，安裝時間較長）。因此可以理解為，使用ART虛擬機下的安卓系統自動支持APK文件中多個DEX的加載。

注意：使用 Instant Run 時，如果項目中的 minSdkVersion 參數設為21或更高版本，Android Studio編譯運行時會自動使應用支持multidex。但 Instant Run 僅僅作用于debug版本，我們依然需要給release版本配置multidex來避開64K方法數的限制。

Config for Multidex With Gradle

Android Gradle 插件在 Android SDK Build Tools 21.1 及更高版本的編譯工具上支持multidex作為編譯配置的一部分，所以確保我們的Android SDK Build Tools tools已經更新至21.1或更高版本，然后再來配置應用的multidex部分。

第一步，修改 app/build.grale 文件，使項目能夠使用multidex：

android {

    compileSdkVersion 21
    buildToolsVersion "21.1.0"

    defaultConfig {
        ...

        // Enabling multidex support.
        multiDexEnabled true
    }
    ...
}

dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

第二步，修改 AndroidManifest.xml 文件，引用 MultiDexApplication 類：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.yifeng.mdstudysamples">
    <application
        ...
        android:name="android.support.multidex.MultiDexApplication">
        ...
    </application>
</manifest>

添加這些配置后，編譯工具會構建出一個主DEX文件（classes.dex）和其他DEX文件（classes2.dex，classes3.dex等，如果需要的話），編譯系統會將他們打包到APK文件中。

注意：一般我們會在項目中自定義一個繼承自 Application 的類，此時就需要重寫 attachBaseContext() 方法，并在該方法里面調用 MultiDex.install(this) 來支持multidex，

Optimizing Multidex Development Builds

multidex配置下的應用，編譯系統需要經過復雜的DEX分割運算，導致增加項目的編譯時間，從而影響開發人員的開發效率。我們可以使用 productFlavors 構建開發環境和正式環境的不同flavors來優化multidex的長時間編譯問題。

對于development flavor，設置 minSdkVersion 值為21，運行在Android 5.0以上版本的設備中，使用ART-supported格式生成multidex的速度要快得多。對于release flavor， minSdkVersion 值則設為應用實際支持的版本，編譯系統耗費較長的時間來生成適配多設備的multidex APK文件。如：

android {
    productFlavors {
        // Define separate dev and prod product flavors.
        dev {
            // dev utilizes minSDKVersion = 21 to allow the Android gradle plugin
            // to pre-dex each module and produce an APK that can be tested on
            // Android Lollipop without time consuming dex merging processes.
            minSdkVersion 21
        }
        prod {
            // The actual minSdkVersion for the application.
            minSdkVersion 14
        }
    }
          ...
    buildTypes {
        release {
            runProguard true
            proguardFiles getDefaultProguardFile('proguard-android.txt'),
                                                 'proguard-rules.pro'
        }
    }
}
dependencies {
  compile 'com.android.support:multidex:1.0.0'
}

這樣，在開發階段，使用devDebug類型的變種app，取消混淆，支持multidex，并且運行在5.0及以上版本的設備中，能夠加快編譯過程。

Methods Count Statistics

盡管安卓系統支持multidex，我們還是要學會分析我們的應用，查看各個部分的方法數，減少冗余方法。這里推薦幾個工具，幫助我們分析。

Library Methods count

一個在線統計 Android Library 方法數的網站，能夠統計出Android領域常見libraries的方法數、JAR文件和DEX文件大小，并且能夠選擇不同版本，以圖表的形式展示出來。

該網站也提供了Android Studio的插件，幫助我們分析項目中所依賴的libraries的方法數，如圖所示：

methodscount-samples-02.png

methodscount-samples-03.png

Apk Method Count

一個在線統計 APK 文件方法數的開源項目，只需要將需要分析的APK文件拖拽上傳至此，即可得到分析結果，如圖：

apk-method-count-samples.png

Android Studio APK Analyzer

最后，要重磅推薦Android Studio自帶的APK Analyzer，功能齊全，使用方便，絕對是安卓開發人員分析應用的不二選擇。使用 Android Studio APK Analyzer ，我們至少能夠做到：

查看APK壓縮文件中各個子文件的大小（如DEX和resource文件）
理解DEX文件的結構
快速查看APK文件的版本信息（直接查看 AndroidManifest.xml 內容）
直觀地比較兩個APK文件內容

Android-Studio-APK-Analyzer-Samples.png

開發階段使用Android Studio打開一個項目時，有三種方式使用APK Analyzer工具：

直接拖拽APK文件到Android Studio的編輯窗口
雙擊打開項目目錄 app/build/outputs/apk/ 下的APK文件
點擊菜單欄 Build->Analyse APK... 并選擇APK文件

來自：http://www.jianshu.com/p/dc5658c23a0b

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

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

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

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

安卓開發 Android開發移動開發