Se la tua app ha un minSdk
di API 20 o versioni precedenti e l'app e le
librerie a cui fa riferimento superano i 65.536 metodi,si verifica il seguente errore di build, che
indica che la tua app ha raggiunto il limite dell'architettura della build Android:
trouble writing output: Too many field references: 131000; max is 65536. You may try using --multi-dex option.
Le versioni precedenti del sistema di build segnalano un errore diverso, che indica lo stesso problema:
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536
Queste condizioni di errore mostrano un numero comune: 65536. Questo numero rappresenta il numero totale di riferimenti che possono essere richiamati dal codice all'interno di un singolo file bytecode Dalvik Executable (DEX). In questa pagina viene spiegato come superare questa limitazione abilitando una configurazione dell'app nota come multidex, che consente all'app di generare e leggere più file DEX.
Informazioni sul limite di 64.000 riferimenti
I file di app per Android (APK) contengono file bytecode eseguibili sotto forma di file Dalvik Executable (DEX), che contengono il codice compilato utilizzato per eseguire la tua app. La specifica Dalvik Executable limita a 65.536 il numero totale di metodi a cui è possibile fare riferimento all'interno di un singolo file DEX, inclusi i metodi framework Android, i metodi di libreria e i metodi nel tuo codice.
Nel contesto dell'informatica, il termine kilo o K indica 1024 (ovvero 2^10). Poiché 65.536 corrisponde a 64 x 1024, questo limite è indicato come limite di riferimento di _64.000_.Supporto di Multidex prima di Android 5.0
Le versioni della piattaforma precedenti ad Android 5.0 (livello API 21) utilizzano il runtime Dalvik
per l'esecuzione del codice dell'app. Per impostazione predefinita, Dalvik limita le app a un singolo
file bytecode classes.dex
per APK. Per aggirare questo limite, aggiungi la libreria multidex al file build.gradle
o build.gradle.kts
a livello di modulo:
Alla moda
dependencies { def multidex_version = "2.0.1" implementation "androidx.multidex:multidex:$multidex_version" }
Kotlin
dependencies { val multidex_version = "2.0.1" implementation("androidx.multidex:multidex:$multidex_version") }
Questa libreria diventa parte del file DEX principale della tua app e quindi gestisce l'accesso ai file DEX aggiuntivi e al codice che contengono. Per visualizzare le versioni correnti di questa libreria, vedi versioni multidex.
Per ulteriori dettagli, consulta la sezione su come configurare la tua app per multidex.Supporto di Multidex per Android 5.0 e versioni successive
Android 5.0 (livello API 21) e versioni successive utilizzano un runtime chiamato ART che
supporta in modo nativo il caricamento di più file DEX dai file APK. ART esegue la precompilazione al momento dell'installazione dell'app, analizzando i file classesN.dex
e compilandoli in un unico file OAT per l'esecuzione da parte del dispositivo Android. Pertanto, se il tuo minSdkVersion
è 21 o superiore, il multidex è abilitato per impostazione predefinita e non è necessaria la libreria multidex.
Per maggiori informazioni sul runtime di Android 5.0, leggi Android Runtime (ART) e Dalvik.
Nota: quando esegui la tua app utilizzando Android Studio, la build è ottimizzata per i dispositivi di destinazione su cui esegui il deployment. È inclusa l'attivazione del multidex quando i dispositivi di destinazione eseguono Android 5.0 e versioni successive. Poiché questa ottimizzazione viene applicata solo quando esegui il deployment dell'app usando Android Studio, potresti comunque dover configurare la build della release per multidex per evitare il limite di 64.000.
Evita il limite di 64.000
Prima di configurare l'app in modo da consentire l'uso di almeno 64.000 riferimenti ai metodi, segui le istruzioni per ridurre il numero totale di riferimenti richiamati dal codice dell'app, inclusi i metodi definiti dal codice dell'app o le librerie incluse.
Le seguenti strategie possono aiutarti a evitare di raggiungere il limite di riferimenti DEX:
- Rivedi le dipendenze dirette e transitive della tua app
- Valuta se il valore di qualsiasi dipendenza dalla libreria di grandi dimensioni che includi nella tua app supera la quantità di codice aggiunta all'app. Un pattern comune, ma problematico, è includere una libreria molto grande, perché alcuni metodi di utilità sono stati utili. Spesso, ridurre le dipendenze del codice dell'app può aiutarti a evitare il limite dei riferimenti DEX.
- Rimuovi il codice inutilizzato con R8
- Abilita la riduzione del codice per eseguire R8 per le build di release. Attiva la riduzione per assicurarti di non spedire codice inutilizzato con i tuoi APK. Se la riduzione del codice è configurata correttamente, può anche rimuovere codice e risorse inutilizzati dalle tue dipendenze.
L'utilizzo di queste tecniche può aiutarti a ridurre le dimensioni complessive dell'APK ed evitare di utilizzare il multidex nell'app.
Configura la tua app per Multidex
Nota: se il tuominSdkVersion
è impostato su 21 o superiore, il multidex è abilitato per impostazione predefinita
e non hai bisogno della libreria multidex.
Se minSdkVersion
è impostato su 20 o su un valore inferiore, devi utilizzare la libreria multidex e apportare le seguenti modifiche al progetto dell'app:
-
Modifica il file
build.gradle
a livello di modulo per abilitare multidex e aggiungi la libreria multidex come dipendenza, come mostrato qui:Alla moda
android { defaultConfig { ... minSdkVersion 15 targetSdkVersion 33 multiDexEnabled true } ... } dependencies { implementation "androidx.multidex:multidex:2.0.1" }
Kotlin
android { defaultConfig { ... minSdk = 15 targetSdk = 33 multiDexEnabled = true } ... } dependencies { implementation("androidx.multidex:multidex:2.0.1") }
- A seconda che tu stia eseguendo l'override della classe
Application
, esegui una delle seguenti operazioni:Se non esegui l'override della classe
Application
, modifica il file manifest per impostareandroid:name
nel tag<application>
come segue:<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp"> <application android:name="androidx.multidex.MultiDexApplication" > ... </application> </manifest>
Se esegui l'override della classe
Application
, modificala per estendereMultiDexApplication
, come segue:Kotlin
class MyApplication : MultiDexApplication() {...}
Java
public class MyApplication extends MultiDexApplication { ... }
Se esegui l'override della classe
Application
ma non è possibile modificare la classe di base, sostituisci il metodoattachBaseContext()
e chiamaMultiDex.install(this)
per abilitare multidex:Kotlin
class MyApplication : SomeOtherApplication() { override fun attachBaseContext(base: Context) { super.attachBaseContext(base) MultiDex.install(this) } }
Java
public class MyApplication extends SomeOtherApplication { @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); } }
Attenzione: non eseguire
MultiDex.install()
o qualsiasi altro codice tramite riflessioni o JNI prima del completamento diMultiDex.install()
. Il tracciamento multidex non seguirà queste chiamate, causandoClassNotFoundException
o verifica errori a causa di una partizione di classe errata tra i file DEX.
Ora, quando crei la tua app, gli strumenti di creazione di Android creano un file DEX principale (classes.dex
) e i file DEX di supporto (classes2.dex
, classes3.dex
e così via) a seconda delle esigenze.
Il sistema di compilazione pacchettizza quindi tutti i file DEX nell'APK.
In fase di runtime, invece di cercare solo nel file classes.dex
principale, le API multidex utilizzano uno speciale caricatore di classi per cercare in tutti i file DEX disponibili per i tuoi metodi.
Limitazioni della libreria multidex
La libreria multidex presenta alcune limitazioni note. Quando incorpori la libreria nella configurazione della build dell'app, considera quanto segue:
- L'installazione di file DEX durante l'avvio sulla partizione dati di un dispositivo è complessa e può causare errori ANR (Application Not Responding) se i file DEX secondari sono di grandi dimensioni. Per evitare questo problema, attiva la riduzione del codice per ridurre al minimo le dimensioni dei file DEX e rimuovere le parti inutilizzate del codice.
- Quando vengono eseguite versioni precedenti ad Android 5.0 (livello API 21), l'utilizzo
di multidex non è sufficiente per aggirare il limite di linearalloc (problema 37008143). Questo limite è stato aumentato in
Android 4.0 (livello API 14), ma il problema non è stato completamente risolto.
Nelle versioni precedenti ad Android 4.0, potresti raggiungere il limite di linearalloc prima di raggiungere il limite dell'indice DEX. Pertanto, se scegli come target livelli API inferiori a 14, esegui test approfonditi su queste versioni della piattaforma, perché la tua app potrebbe presentare problemi all'avvio o al caricamento di determinati gruppi di classi.
La riduzione del codice può ridurre o probabilmente eliminare questi problemi.
Dichiara le classi richieste nel file DEX principale
Quando si crea ogni file DEX per un'app multidex, gli strumenti di creazione eseguono
un processo decisionale complesso per determinare quali classi sono necessarie nel file DEX principale
in modo che l'app possa iniziare correttamente. Se una classe necessaria
durante l'avvio non viene fornita nel file DEX principale, l'app ha un arresto anomalo
con l'errore java.lang.NoClassDefFoundError
.
Gli strumenti di creazione riconoscono i percorsi del codice a cui si accede direttamente dal codice dell'app. Tuttavia, questo problema può verificarsi quando i percorsi del codice sono meno visibili, ad esempio quando una libreria che utilizzi ha dipendenze complesse. Ad esempio, se il codice utilizza l'introspezione o il richiamo di metodi Java dal codice nativo, queste classi potrebbero non essere riconosciute come richieste nel file DEX principale.
Se ricevi java.lang.NoClassDefFoundError
, devi specificare manualmente le classi aggiuntive richieste nel file DEX principale dichiarandole con la proprietà multiDexKeepProguard
nel tipo di build. Se nel file multiDexKeepProguard
viene trovata una corrispondenza con una classe, questa viene aggiunta al file DEX principale.
proprietà multiDexKeepProguard
Il file multiDexKeepProguard
utilizza lo stesso formato di ProGuard e supporta l'intera grammatica di ProGuard. Per ulteriori informazioni su come personalizzare gli elementi da conservare nell'app, vedi
Personalizzare il codice da conservare.
Il file specificato in multiDexKeepProguard
deve contenere -keep
opzioni in qualsiasi sintassi ProGuard valida. Ad esempio,
-keep com.example.MyClass.class
. Puoi creare un file denominato
multidex-config.pro
simile al seguente:
-keep class com.example.MyClass -keep class com.example.MyClassToo
Se vuoi specificare tutte le classi di un pacchetto, il file sarà simile al seguente:
-keep class com.example.** { *; } // All classes in the com.example package
Quindi puoi dichiarare quel file per un tipo di build, come segue:
Alla moda
android { buildTypes { release { multiDexKeepProguard file('multidex-config.pro') ... } } }
Kotlin
android { buildTypes { getByName("release") { multiDexKeepProguard = file("multidex-config.pro") ... } } }
Ottimizza multidex nelle build di sviluppo
Una configurazione multidex richiede un tempo di elaborazione della build notevolmente aumentato, perché il sistema di compilazione deve prendere decisioni complesse su quali classi devono essere incluse nel file DEX principale e quali classi possono essere incluse nei file DEX secondari. Ciò significa che le build incrementali che utilizzano multidex in genere richiedono più tempo e possono potenzialmente rallentare il processo di sviluppo.
Per ridurre tempi di build incrementali più lunghi, utilizza il
pre-dexing per riutilizzare l'output multidex tra le build.
Il pre-dexing si basa su un formato ART disponibile solo su Android 5.0
(livello API 21) e versioni successive. Se usi Android Studio, l'IDE utilizza automaticamente il pre-dexing
durante il deployment della tua app su un dispositivo con Android 5.0 (livello API 21) o versioni successive.
Tuttavia, se esegui build di Gradle dalla riga di comando, devi impostare
minSdkVersion
su 21 o versioni successive per abilitare il pre-dexing.
minSdkVersion
, come mostrato di seguito:
Alla moda
android { defaultConfig { ... multiDexEnabled true // The default minimum API level you want to support. minSdkVersion 15 } productFlavors { // Includes settings you want to keep only while developing your app. dev { // Enables pre-dexing for command-line builds. When using // Android Studio 2.3 or higher, the IDE enables pre-dexing // when deploying your app to a device running Android 5.0 // (API level 21) or higher, regardless of minSdkVersion. minSdkVersion 21 } prod { // If you've configured the defaultConfig block for the production version of // your app, you can leave this block empty and Gradle uses configurations in // the defaultConfig block instead. You still need to include this flavor. // Otherwise, all variants use the "dev" flavor configurations. } } buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { implementation "androidx.multidex:multidex:2.0.1" }
Kotlin
android { defaultConfig { ... multiDexEnabled = true // The default minimum API level you want to support. minSdk = 15 } productFlavors { // Includes settings you want to keep only while developing your app. create("dev") { // Enables pre-dexing for command-line builds. When using // Android Studio 2.3 or higher, the IDE enables pre-dexing // when deploying your app to a device running Android 5.0 // (API level 21) or higher, regardless of minSdkVersion. minSdk = 21 } create("prod") { // If you've configured the defaultConfig block for the production version of // your app, you can leave this block empty and Gradle uses configurations in // the defaultConfig block instead. You still need to include this flavor. // Otherwise, all variants use the "dev" flavor configurations. } } buildTypes { getByName("release") { isMinifyEnabled = true proguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro") } } } dependencies { implementation("androidx.multidex:multidex:2.0.1") }
Per scoprire di più sulle strategie che consentono di migliorare la velocità delle build da Android Studio o dalla riga di comando, leggi Ottimizzare la velocità di compilazione. Per saperne di più sull'utilizzo delle varianti di build, consulta Configurare le varianti di build.
Suggerimento: se hai varianti di build diverse per esigenze multidex diverse, puoi fornire un file manifest diverso per ogni variante, in modo che solo il file per il livello API 20 e per quelle inferiori modifichi il nome del tag <application>
. Puoi anche creare una sottoclasse Application
diversa per ogni variante, in modo che solo la sottoclasse per il livello API 20 o inferiore espanda la classe MultiDexApplication
o chiama MultiDex.install(this)
.
Testa le app multidex
Quando scrivi test di strumentazione per app multidex, non è necessaria alcuna configurazione aggiuntiva se utilizzi una strumentazione
MonitoringInstrumentation
o
AndroidJUnitRunner
. Se utilizzi un altro
Instrumentation
,
devi eseguire l'override del metodo onCreate()
con il seguente codice:
Kotlin
fun onCreate(arguments: Bundle) { MultiDex.install(targetContext) super.onCreate(arguments) ... }
Java
public void onCreate(Bundle arguments) { MultiDex.install(getTargetContext()); super.onCreate(arguments); ... }