Android: come risolvere l'errore del superamento del limite dei 64K metodi

Android come tutti gli ambienti basati sulla mentalità open source è in continua crescita sia come SDK sia come strumenti che vengono offerti a corredo da Google o da realtà di terze parti. Oltre a ciò, l’introduzione di Gradle come strumento di build automation in Android Studio ha portato con sé un ottimo sistema di risoluzione delle dipendenze: quando abbiamo bisogno di nuove funzionalità non dobbiamo far altro che richiedere l’integrazione di una qualche libreria nel progetto.

La convergenza di questi fattori ha prodotto, nel tempo, applicazioni che crescono sempre più fino all’apparizione di uno strano messaggio nella fase di build che, nel tempo, si è manifestato in varie forme ma il cui significato non è mai cambiato: l’app contiene troppi metodi e soprattutto la loro quantità supera il limite di 65.536 o meglio 64K come piace dire agli informatici.

Il limite dei 64K

Il problema nasce dal fatto che all’interno di un APK – il pacchetto di installazione di un’app Android – esiste un archivio in formato DEX (destinato a Dalvik, la macchina virtuale di Android) che non può indirizzare più di 65.536 metodi, compresi quelli già esistenti nella piattaforma. Sempre più spesso succede quindi che, al momento del build, l’inclusione di nuove librerie o anche solo l’aggiornamento di una di esse ad una versione più recente (pensiamo a come crescono i Google Play Services) improvvisamente renda la nostra app non più compilabile impedendoci di andare avanti con il lavoro. Visto che non è stato possibile aumentare il numero di metodi integrabili in un archivio DEX, l’unica alternativa è inserire più di uno di questi all’interno dell’APK passando ad una configurazione multidex.

Configurazione multidex

Per passare ad una configurazione multidex è necessario agire su due file del progetto, quelli che classicamente regoliamo per ottenere il nostro risultato finale:

nel file build.gradle (a livello di modulo) andiamo ad attivare il supporto multidex inserendo tra le dipendenze la direttiva:

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

e attivando il supporto:

 defaultConfig {
        ...
        ...
        multiDexEnabled true
        ...
        ...
    }

nel file AndroidManifest.xml invece è necessario fare in modo che la nostra applicazione sia una MultiDexApplication, semplicemente modificando in questa maniera il nodo application:
```
<application
    android:name="android.support.multidex.MultiDexApplication">
    ...
    ...
</application>
```

Fatto ciò, si potrà attivare un nuovo build del progetto e questa volta – forti del frazionamento dei metodi in più file DEX – non verranno più segnalati errori e potremo provare la nostra app.

Nei limiti del possibile, sarebbe comunque preferibile cercare di evitare l’errore, ad esempio, limitando le dipendenze inserite nel progetto. Proprio la semplicità con cui Gradle ci mette a disposizione nuove funzionalità, induce spesso ad usare librerie di cui potremmo fare a meno magari scrivendo un po più di codice noi stessi: non sempre per sfruttarne una o due funzionalità vale la pena integrare una libreria intera, magari molto estesa. Pensando ad esempio ai Google Play Services sappiamo che la loro libreria client che integriamo nelle app per dialogare con i servizi Google è molto estesa ed offre funzionalità per l’intero universo di Mountain View. Si potrebbe limitare il loro “peso” nel progetto richiedendo solo le API di cui abbiamo bisogno e ciò è possibile dalla versione 6.5.

Quindi, invece di includere l’intera libreria dei Google Play Services:

dependencies {
        compile 'com.google.android.gms:play-services:9.4.0'
    }

potremmo introdurre – poniamo il caso – solo le API relative alle Google Maps:

dependencies{
com.google.android.gms:play-services-maps:9.4.0
}

includendo così un numero minore di metodi. L’intera lista delle API richiamabili è disponibile alla pagina ufficiale che illustra le modalità di installazione della libreria.

Conclusioni

Quindi la morale della storia è: se incorriamo nel superamento del limite dei 64K metodi, niente panico, la soluzione esiste, ciò non toglie che è bene configurare un progetto in maniera che non si richiedano dipendenze di cui potremmo fare a meno. Il valore di un’app si misura in tanti modi: apprezzando efficienza e funzionalità incluse – certo – ma anche gustando un prodotto ottimizzato e dalle dimensioni ridotte quanto possibile.

E voi che ne pensate? Vi è mai capito di incorrere in un messaggio di errore simile a quelli di cui abbiamo parlato ? Commentate e raccontateci le vostre esperienze!