Naarmate onze apps meer functies krijgen en complexer worden, neemt de uiteindelijke bestandsgrootte vaak aanzienlijk toe. Dit is een serieus probleem, want als een app te groot is, denken veel gebruikers wel twee keer na voordat ze op de installatieknop klikken of, erger nog, stoppen ze halverwege met downloaden. Bovendien neemt een grote app meer opslagruimte op de telefoon in beslag en kan dit uiteindelijk de reactiesnelheid van het systeem beïnvloeden.
Om te voorkomen dat je project uitgroeit tot een digitale kolos, zijn er verschillende strategieën, van het opschonen van code tot het optimaliseren van afbeeldingen. In dit artikel gaan we dieper in op hoe je tools zoals R8 en ProGuard kunt gebruiken , en hoe App Bundles je kunnen helpen om je app zo licht en snel mogelijk te maken, zodat deze zelfs op minder krachtige apparaten probleemloos draait.
Inzicht in wat er echt toe doet in je app.
Voordat we beginnen, moeten we weten waar het grootste deel van de data zich bevindt. De omvang van een applicatie is doorgaans verdeeld in vier hoofdblokken. Ten eerste is er de Java- of Kotlin-bytecode en de bijbehorende bibliotheken, die meestal 30% tot 40% van de data uitmaken. Vervolgens zijn er resources zoals layouts en animaties , met een vergelijkbare omvang. We hebben ook de native bibliotheken (C/C++) die gecompileerd zijn voor verschillende architecturen (15-25%), en tot slot de assets of onbewerkte bestanden (5-15%).
Om giswerk te voorkomen, is het het beste om de APK Analyzer van Android Studio te gebruiken (via Build > Analyze APK). Met deze tool kun je precies zien hoeveel DEX-klassen, de resource-map en native libraries in beslag nemen. Zo kun je de huidige versie vergelijken met eerdere versies om te achterhalen welke wijzigingen de toename in bestandsgrootte hebben veroorzaakt. Om dit onderwerp beter te begrijpen, is het handig om de bestandsstructuur in Android en de manier waarop bestanden zijn georganiseerd te kennen.
Code opschonen: De overstap van ProGuard naar R8
Codereductie is ongetwijfeld de meest effectieve manier om bytes te besparen. Hier komen ProGuard en zijn moderne opvolger, R8, om de hoek kijken. ProGuard was jarenlang de standaard en zorgde voor het verwijderen van ongebruikte klassen, velden en methoden , het optimaliseren van bytecode en het verbergen van namen om ze korter (en moeilijker leesbaar voor hackers) te maken.
Tegenwoordig is R8 de standaardcompiler en doet alles wat ProGuard deed, maar dan veel beter en sneller. R8 implementeert een agressievere vorm van tree shaking , voegt klassen met vergelijkbare functies samen en optimaliseert enumeraties door ze naar gehele getallen te converteren. Bovendien maakt het desugaring mogelijk, waardoor moderne Java 8-functies in oudere Android-versies gebruikt kunnen worden.
Technische configuratie in build.gradle
Om deze optimalisaties in de releaseversie te activeren, moet u het buildbestand configureren door de volgende instelling te gebruiken: minifyEnabled als waar en het koppelen van de regelbestanden. Het is essentieel om te gebruiken proguard-android-optimize.txt om optimaal te profiteren van de optimalisaties. Een voorbeeld van een basisconfiguratie zou er als volgt uitzien: applicatieklassen onderhouden of die welke zijn aangeduid met @Keep om te voorkomen dat R8 ze per ongeluk verwijdert.
Regelbeheer voor externe bibliotheken
Soms is R8 te efficiënt en verwijdert het code die via reflectie wordt gebruikt, wat fouten veroorzaakt zoals: ClassNotFoundExceptionDaarom zijn boekhandels zoals Retrofit, OkHttp of Gson vereisen specifieke regels.Bijvoorbeeld, bij Gson is het essentieel om de veldnamen in de datamodellen te behouden, zodat de JSON-deserialisatie niet mislukt. Als je na de obfuscatie fouten tegenkomt, moet je het bestand controleren. mapping.txt Het is je beste bondgenoot bij het vertalen van stacktraces en het achterhalen waar de fout is opgetreden.
Intelligente optimalisatie van resources
Vaak wordt de meeste ruimte verspild aan resources. Een eenvoudige maar krachtige techniek is het activeren van resources. krimpbronnen in het build.gradle-bestand. Dit verwijdert bestanden waarnaar in de code niet wordt verwezen, hoewel het belangrijk is om te weten dat als je een resource dynamisch aanroept met behulp van getIdentifierJe moet dit in een bestand declareren. keep.xml zodat het niet verdwijnt.
Afbeeldingen en grafische elementen: minder is meer.
Het PNG-formaat is verantwoordelijk voor veel onnodige megabytes. De huidige aanbeveling is om alles naar het WebP-formaat te migreren , dat een veel betere compressie biedt met behoud van kwaliteit. Je kunt deze conversie rechtstreeks in Android Studio uitvoeren door met de rechtermuisknop op de afbeelding te klikken. Voor pictogrammen en eenvoudige vormen zijn Vector Drawables ideaal ; één XML-bestand vervangt vijf versies met verschillende dichtheden, wat het onderhoud vereenvoudigt en de bestandsgrootte verkleint.
Het aantal talen en de bevolkingsdichtheid terugdringen
Veel externe bibliotheken worden geleverd met vertalingen in 50 talen die uw app waarschijnlijk niet ondersteunt. Om dit op te lossen, kunt u de eigenschap gebruiken. resConfigs in defaultConfigwaarbij alleen de talen worden gespecificeerd die u daadwerkelijk gebruikt (bijvoorbeeld, "es", "en"Op dezelfde manier kunt u de meegeleverde schermdichtheden beperken als u weet dat uw doelgroep moderne apparaten gebruikt, door resources te verwijderen. ldpi of mdpi die niemand meer gebruikt.
Geavanceerde distributiestrategieën
Als je de APK-grootte definitief wilt verkleinen, moet je stoppen met het gebruik van universele APK's en overschakelen naar Android App Bundles (.aab) . In plaats van één gigantisch bestand met alles wat mogelijk is te versturen, genereert Google Play een geoptimaliseerde APK voor elk apparaat. Op deze manier downloadt een gebruiker met een ARM64-telefoon en een xxhdpi-scherm alleen wat zijn hardware nodig heeft , waardoor de downloadgrootte tot wel 40% kleiner wordt.
Dynamische functiemodules en Instant Apps
Niet alle code hoeft vanaf het begin beschikbaar te zijn. Met dynamische functiemodules kunt u onderdelen van de app (zoals een geavanceerde foto-editor of offline-modus) scheiden, zodat deze pas worden gedownload wanneer de gebruiker die functie gebruikt. Instant Apps daarentegen laten gebruikers uw app uitproberen zonder deze te installeren, door een extreem lichte basismodule te laden via een URL of de Google Play-knop.
Controle van afhankelijkheden en definitieve details
Soms ligt het probleem niet bij je code, maar bij wat je van buitenaf importeert. Bibliotheken zoals Guava of Jackson kunnen erg groot zijn; overweeg ze te vervangen door lichtere alternatieven zoals kotlinx.serialization of Gson . Het is ook raadzaam om downloadbare lettertypen van Google Fonts te gebruiken in plaats van grote TTF-bestanden in je assets op te nemen. Dit kan je enkele megabytes besparen als je meerdere varianten van een lettertype gebruikt.
Om de optimalisatiecyclus te voltooien, is het belangrijk te onthouden dat Android Go een groeiende markt is. Als je wilt dat je app goed presteert op apparaten met minder dan 1 GB RAM, probeer de grootte dan onder de 40 MB te houden. Door Android Lint te gebruiken om ongebruikte resources op te sporen en een consistente opschoonroutine te hanteren, zorg je ervoor dat je app efficiënt is, snel installeert en een soepele gebruikerservaring biedt, ongeacht de rekenkracht van het apparaat.
