Sådan forbedres opbygningshastigheden på dine Android-projekter

For nylig påtog jeg mig opgaven med at migrere Android-codebasen på Kure til AndroidX. Det virkede som den perfekte mulighed for at prøve at rette projektets byggehastigheder.

Gradle har altid haft en dårlig rep for at være langsom og ressourceintensiv, men jeg var ganske overrasket over, hvordan mindre ændringer i projektets opbygningskonfiguration massivt kunne forbedre byggehastighederne.

For at give dig et smugkig på den tid, jeg var i stand til at kaste fra vores rene builds, er her en før og efter metric fra build scanningen.

Går ned fra 5,5 minutter til 17 sekunder ?? Det er bonkers.

Det er let at gå overbord med optimeringer, som du kan udføre for at reducere din byggetid endnu længere. Men jeg vil bevidst fokusere på de mindre, smertefri foranstaltninger, jeg har truffet for at komme tæt på denne måling for at holde dette indlæg nybegyndervenligt.

Men først!

Før du starter med optimeringen, er det vigtigt at benchmarke vores projekt for at se, hvor lang tid det i øjeblikket tager at bygge. Gradle har en praktisk scanningsindstilling, som du kan bruge til at analysere udførelsen af ​​din opgave. Skyd terminalen på Android Studio, og udfør følgende kommando:

./gradlew assembleDebug --scan

Når build er afsluttet med succes, vil det bede dig om at acceptere servicevilkårene for at uploade dine build-scanningsresultater. Skriv ja for at fortsætte. Når det er udgivet, får du et link på terminalen for at kontrollere din build-scanning. Åbn linket.

Der er en hel del muligheder på webstedet, men for kortfattethed skal vi kun se på, hvad der er vigtigst.

Resumeetvisning viser dig et resumé af de opgaver, der blev kørt, og hvor lang tid det tog for dem at udføre. Men det, vi er interesseret i her, er Performance- sektionen. Det giver dig en mere detaljeret oversigt over den samlede byggetid som vist nedenfor.

Under præstationsafsnittet er der en fane Indstillinger og forslag , der giver dig forslag til, hvordan du kan forbedre dine byggehastigheder. Lad os tjekke det ud.

Vi kan finde nogle nemme rettelser til vores byggehastighed i dette afsnit. Så lad os gå videre og anvende disse forslag i vores projekt.

Trin # 1: Opdater dit værktøj

Android-teamet forbedrer og udvikler konstant Android build-systemet. Så det meste af tiden kan du modtage betydelige forbedringer bare ved at vedtage den nyeste version af værktøjet.

På tidspunktet for denne refaktor var vores projekt på version 3.2.1 af Gradle-pluginet til Android Studio (som er et par versioner ældre end den seneste udgivelse).

Du kan besøge dette link for at hente versionen til den seneste udgivelse af Gradle Plugin.

På tidspunktet for skrivningen af ​​dette indlæg er den seneste version tilfældigvis version 3.4.0.

Men det kommer med en gotcha, som vi skal huske på senere:

Når du bruger Gradle 5.0 og derover, skal vi eksplicit øge dyngestørrelsen for at sikre, at vores byggehastighed ikke forværres. Vi kommer tilbage til dette om bare et minut.

Åbn den øverste niveau build.gradle- fil, som du finder i roden af ​​dit projekt, og tilføj følgende linje i afsnittet afhængigheder:

classpath 'com.android.tools.build:gradle:3.4.0'

Du bliver også nødt til at opdatere distributions-URL'en i egenskaben-filen for gradleindpakning, der findes på gradle / wrapper / gradle-wrapper.properties. Opdater URL-adressen til følgende.

(Dette link vil være tilgængeligt på Android Gradle-udgivelsessiden.)

distributionUrl=https\://services.gradle.org/distributions/gradle-5.1.1-all.zip

Hvis du bruger Kotlin i dit projekt, vil du støde på en fejl, hvis dit Kotlin Gradle-plugins version er mindre end 1.3.0 . Hvis det er tilfældet, skal du bruge IDE's prompt til at opdatere dit Kotlin Gradle-plugin til den nyeste version (som på tidspunktet for skrivning af dette indlæg tilfældigvis er version 1.3.31 ).

Okay, lad os køre bygningen igen fra terminalen for at se, om vi har opnået nogen forbedringer.

Trin # 2: Opdater dine konfigurationer

Så vi var i stand til at kaste omkring 2,5 minutter fra byggetiden, men det er stadig ikke godt nok. Efter at have undersøgt build-logfiler i terminalen stødte jeg på en linje, der er interessant for os:

Inkrementel kompilering forhindrer grundlæggende spild af kompilering af hele kildefiletsættet og kompilerer i stedet kun de filer, der er ændret. Når man ser på logfilerne, er det klart, at vi ikke udnytter denne funktion. Det foreslår os at bruge android.enableSeparateAnnotationProcessing = true, men da vi bruger Kotlin i vores projekter, bør vi ikke bruge konfigurationen 'annotationProcessor' alligevel.

Heldigvis tilføjede Kotlin version 1.3.30 understøttelsen til trinvis annoteringsbehandling.

Så lad os

  1. Skift annotationProcessorkonfigurationen til kapt
  2. Aktivér det eksperimentelle flag for trinvis annotering

Åbn din modul niveau build.gradle fil og tilføj følgende linje øverst i filen:

apply plugin: 'kotlin-kapt'

Dernæst skal du ændre alle annotationProcessor-konfigurationer i afsnittet afhængigheder for at bruge kapt. Her er et eksempel:

//Before annotationProcessor 'com.google.dagger:dagger-compiler:2.9' //After kapt 'com.google.dagger:dagger-compiler:2.9'

Åbn nu din gradle.properties- fil placeret ved roden af ​​dit projekt, og tilføj følgende linje:

kapt.incremental.apt=true

Lad os køre bygningen igen. ??????

Okay, det ser ud til, at vi kommer derhen.

Trin # 3: Gradle egenskaber

Vi er i sidste fase nu. Husk den gotcha, vi stødte på, mens vi opdaterede vores Gradle-plugin-version? Det viser sig, at de nyere versioner af Gradle reducerer dyngestørrelsen til 512 MB. Dette er for at sikre, at maskiner i den nedre ende ikke kvæles. Jeg er på en maskine med 16 gig, så jeg har råd til at give omkring 2-3 gig til Gradle-dæmonen, men din kilometertal kan variere.

Open the gradle.properties file located at the root of your project and add the following line. Remember to select the size according to your requirements and machine specification.

org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

While we’re at it, let’s also enable parallel builds and configure on demand in the properties.

Here’s what my final gradle.properties file looks like:

org.gradle.jvmargs=-Xmx3072m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 org.gradle.parallel=true org.gradle.configureondemand=true kapt.incremental.apt=true
  • org.gradle.parallel - This flag allows Gradle to build modules within a project in parallel instead of sequentially. This is only beneficial in a multi-module project.
  • org.gradle.configureondemand - This flag configures only the modules needed by the project, instead of building all of them.

With these, let’s see where we are on our build speed metric:

And there we go. ???

Closing remarks

Dette er på ingen måde en omfattende dækning af alle de måder, man kan optimere byggehastigheden på deres projekt. Der er masser af andre ting, som jeg ikke gik igennem i dette indlæg som at bruge minSdk 21, når jeg bruger MultiDex, pre-dexing af dine biblioteker, deaktivering af PNG-knasning og så videre - for at nævne nogle få.

Men de fleste af disse konfigurationer kræver en dybere forståelse af Android's build-system og erfaring med at arbejde med store multimodulprojekter (det er her fordelene er tydeligste) . De trin, jeg har nævnt ovenfor, er nemme at integrere i et projekt selv af juniorudviklere og har betydelige udbetalinger. Jeg håber, dette hjælper dig med at trimme dine byggehastigheder!

Okay indtil næste gang, fred! ✌?