Boehrsi.de - Blog

Es ist Sonntag und ich überlege ob ich zocke oder programmiere, doch bevor ich mich dieser extrem schweren Frage stelle noch eine kleine News für zwischendurch. Dieses Mal geht es um Android Libraries und die Anzahl an Methoden die sie mitbringen. Jeder Android Entwickler kennt vermutlich das 64K DEX Limit und wird hier und dort schon einmal nervige Erfahrungen mit Multi-DEX gemacht haben. Auch wenn dies ein geringeres Problem in neueren Android Versionen darstellt, ist es trotzdem störend. Denn sobald man Multi-DEX nutzt kann das bauen länger dauern, hier und dort können kryptische Fehler entstehen und gerade bei ganz neuen Android Studio Features kann es Probleme geben. Deswegen habe ich gerade erst bei einem großen Projekt mit hängen und würgen diverse Methoden aus fremden Libraries entfernt, um unter das magische DEX Limit zu kommen. Dazu gibt es bald noch einen Beitrag. Doch die Ernüchterung kam bald, denn abgesehen davon das die Android Support Libraries extrem viele Methoden am Start haben, gab es bald eine neue Abhängigkeit und zwar die Google Services. Damit war dann jegliche Chance verloren unter das DEX Limit zu kommen. Denn mit 20K+ Methoden für diverse Android Support Komponenten und dann noch ca. 8K für eine Komponente der Google Services ist man schon so extrem weit oben was den Method-Count angeht. Ich verstehe wie komplex diese Dinge sind und was Google so nah am System wohl alles bauen und bedenken muss, doch ein wenig mehr Augenmerk auf diese Komponenten mit Bezug auf die Anzahl der Methoden wäre hin und wieder sehr angenehm. In diesem Kontext ist mir bewusst das die Android Support und Google Services Libraries in der letzten Zeit in kleinere Pakete zerteilt wurden, was ich extrem gut finde, doch irgendwie reicht dies leider noch nicht aus. Für mich heißt es nun back to Multi-DEX und mit den eventuellen Problemen auskommen. Wie ist es bei euch, kennt ihr das Problem und wie umgeht ihr es bei euch, sofern dies möglich ist?