Android應用解決65K方法數限制

InfoQ - 梅雪松發表於2015-01-20
Android

近日，Android Developers在Google+上宣佈了新的Multidex支援庫，為方法總數超過65K的Android應用提供了官方支援。

如果你是一名幸運的Android應用開發者，正在開發一個前景廣闊的應用，不斷地加入新功能、新增新的類庫，那麼終有一天，你會不幸遇到這個錯誤：

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

這個錯誤是Android應用的方法總數限制造成的。Android平臺的Java虛擬機器Dalvik在執行DEX格式的Java應用程式時，使用原生型別short來索引DEX檔案中的方法。這意味著單個DEX檔案可被引用的方法總數被限制為65536。通常APK包含一個classes.dex檔案，因此Android應用的方法總數不能超過這個數量，這包括Android框架、類庫和你自己開發的程式碼。

這個問題可以通過將一個DEX檔案分拆成多個DEX檔案解決。Facebook介紹了為Android應用開發的Dalvik補丁；Android Developers部落格介紹了通過自定義類載入過程的方法來解決此問題。但這些方法有些複雜而且並不優雅。

隨著新的MultiDex支援庫釋出，Google正式為解決此問題提供官方支援。構建超過65K方法數的應用介紹瞭如何使用Gradle構建多DEX應用。

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

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檔案。在MultiDexApplication JavaDoc中描述了三種可選方法：

  • 在AndroidManifest.xml的application中宣告android.support.multidex.MultiDexApplication；
  • 如果你已經有自己的Application類，讓其繼承MultiDexApplication；
  • 如果你的Application類已經繼承自其它類，你不想/能修改它，那麼可以重寫attachBaseContext()方法：
@Override 
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base); MultiDex.install(this);
}

經過以上步驟，你的應用已經可以實現多個DEX檔案了。當應用構建時，構建工具會分析哪些類必須放在第一個DEX檔案，哪些類可以放在附加的DEX檔案中。當它建立了第一個DEX檔案（classes.dex）後，如果有必要會繼續建立附加的DEX檔案，如classes2.dex, classes3.dex。Multidex的支援類庫將被包含在應用的第一個DEX檔案中，幫助實現對其它DEX檔案的訪問。

文中還介紹了在開發多DEX應用時，通過設定productFlavors提高開發效率以及多DEX應用的測試方法。

Android 5.0和更高版本使用名為ART的執行時，它原生支援從APK檔案載入多個DEX檔案。在應用安裝時，它會執行預編譯，掃描classes(..N).dex檔案然後將其編譯成單個.oat檔案用於執行。瞭解更多關於ART的資訊。

雖然Google解決了應用總方法數限制的問題，但並不意味著開發者可以任意擴大專案規模。Multidex仍有一些限制：

  1. DEX檔案安裝到裝置的過程非常複雜，如果第二個DEX檔案太大，可能導致應用無響應。此時應該使用ProGuard減小DEX檔案的大小。
  2. 由於Dalvik linearAlloc的Bug，應用可能無法在Android 4.0之前的版本啟動，如果你的應用要支援這些版本就要多執行測試。
  3. 同樣因為Dalvik linearAlloc的限制，如果請求大量記憶體可能導致崩潰。Dalvik linearAlloc是一個固定大小的緩衝區。在應用的安裝過程中，系統會執行一個名為dexopt的程式為該應用在當前機型中執行做準備。dexopt使用LinearAlloc來儲存應用的方法資訊。Android 2.2和2.3的緩衝區只有5MB，Android 4.x提高到了8MB或16MB。當方法數量過多導致超出緩衝區大小時，會造成dexopt崩潰。
  4. Multidex構建工具還不支援指定哪些類必須包含在首個DEX檔案中，因此可能會導致某些類庫（例如某個類庫需要從原生程式碼訪問Java程式碼）無法使用。

避免應用過大、方法過多仍然是Android開發者要注意的問題。Mihai Parparita的開源專案dex-method-counts可以用於統計APK中每個包的方法數量。

通常開發者自己的程式碼很難達到這樣的方法數量限制，但隨著第三方類庫的加入，方法數就會迅速膨脹。因此選擇合適的類庫對Android開發者來說尤為重要。

開發者應該避免使用Google Guava這樣的類庫，它包含了13000多個方法。儘量使用專為移動應用設計的Lite/Android版本類庫，或者使用小類庫替換大類庫，例如用Google-gson替換Jackson JSON。而對於Google Protocol Buffers這樣的資料交換格式，其標準實現會自動生成大量的方法。採用Square Wire的實現則可以很好地解決此問題。

相關文章