Kuidas oma Android-projektide koostamiskiirust parandada

Hiljuti võtsin ette Kure'is asuva Androidi koodibaasi AndroidX-i üleviimise. Tundus, et see on ideaalne võimalus proovida projekti ehituskiirusi parandada.

Gradle on alati olnud aeglane ja ressursimahukas, kuid ma olin üsna üllatunud, kuidas väiksemad muudatused projekti koostekonfiguratsioonis võiksid ehitamise kiirust oluliselt parandada.

Selleks, et saaksin pilgu heita ajast, mille ma suutsin meie puhastest ehitistest välja heita, on siin järk-järgult enne ja pärast koostatud skaneeringu mõõdik.

5,5 minutilt 17 sekundile alla minna ?? See on prohmakad.

Lihtne on ületada optimeerimised, mida saate teha, et oma ehitamise aega veelgi vähendada. Kuid kavatsen sihilikult keskenduda väiksematele valututele meetmetele, mille võtsin selle mõõdiku lähedale jõudmiseks, et hoida postituse algaja sõbralik.

Aga esmalt!

Enne optimeerimisega alustamist on oluline võrrelda meie projekti, et näha, kui kaua selle ehitamine praegu aega võtab. Gradle'il on mugav skannimisvalik, mida saate kasutada oma ülesande jõudluse analüüsimiseks. Käivitage Android Studio terminal ja käivitage järgmine käsk:

./gradlew assembleDebug --scan

Kui järk on edukalt lõpule viidud, palub see teil ehituskontrolli tulemuste üleslaadimiseks nõustuda teenusetingimustega. Jätkamiseks sisestage jah . Kui see on avaldamise lõpetanud, saate terminalis lingi, et kontrollida oma järk-järgulist skannimist. Avage link.

Saidil on üsna palju võimalusi, kuid lühiduse huvides vaatame ainult kõige olulisemat.

KokkuvõteVaade näitab kokkuvõtet käivitatud ülesannetest ja nende täitmise ajast. Kuid see, mis meid siin huvitab, on jaotis Performance . See annab teile kogu ehitamise aja üksikasjalikuma jaotuse, nagu allpool näidatud.

Toimivuse jaotises on vahekaart Seaded ja soovitused, mis annab teile soovitusi selle kohta, kuidas saaksite oma kiirust parandada. Kontrollime seda.

Selles jaotises leiame mõned lihtsad parandused meie ehitamiskiiruse kohta. Lähme edasi ja rakendame neid ettepanekuid oma projektis.

1. samm: värskendage oma tööriistu

Androidi meeskond täiustab ja arendab pidevalt Androidi ehitussüsteemi. Nii saate enamasti tööriistade uusima versiooni kasutamisel olulisi täiustusi.

Selle refaktori ajal oli meie projekt Android Studio jaoks pistikprogrammi Gradle versioonil 3.2.1 (mis on paar versiooni vanem kui viimane väljaanne).

Gradle'i pistikprogrammi uusima versiooni saamiseks külastage seda linki .

Selle postituse kirjutamise ajal on uusim versioon tõenäoliselt versioon 3.4.0.

Kuid see on varjatud, mida peame hiljem meeles pidama:

Kui kasutate Gradle 5.0 ja eespool peame selgelt suurendada kuhja maht tagada meie build kiirus ei halveneks. Selle juurde naaseme vaid minutiga.

Avage faili build.gradle tipptasemel fail, mille leiate oma projekti juurest ja lisage sõltuvuste jaotisse järgmine rida :

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

Samuti peate värskendama levitamise URL-i gradle'i ümbrise omaduste failis, mis asub aadressil gradle / wrapper / gradle-wrapper.properties. Värskendage URL järgmisele.

(See link on saadaval pistikprogrammi Android Gradle vabastamise lehel.)

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

Kui kasutate oma projektis Kotlini, tekib viga, kui teie Kotlin Gradle'i pistikprogrammi versioon on väiksem kui 1.3.0 . Sel juhul kasutage IDL-i viipa, et värskendada oma Kotlin Gradle'i pistikprogrammi uusimale versioonile (mis selle postituse kirjutamise ajal juhtub olema versioon 1.3.31 ).

Hästi, käivitame ehituse terminalist uuesti, et näha, kas oleme mingeid parandusi saavutanud.

2. samm: värskendage oma konfiguratsioone

Nii et saime ehitada umbes 2,5 minutit ehituse ajast, kuid see pole ikkagi piisavalt hea. Terminali ehituskogude uurimisel sattusin ühele reale, mis meid huvitas:

Järk-järguline kompileerimine takistab põhimõtteliselt kogu lähtefailide komplekti raiskamatut koostamist ja kompileerib selle asemel ainult muudetud failid. Palke vaadates on selge, et me ei kasuta seda funktsiooni ära. See soovitab meil kasutada android.enableSeparateAnnotationProcessing = true, kuid kuna me kasutame oma projektides Kotlini, ei tohiks me igal juhul kasutada konfiguratsiooni 'annotationProcessor' .

Õnneks lisas Kotlini versioon 1.3.30 toetuse annotatsioonide järkjärguliseks töötlemiseks.

Nii et lähme

  1. Muutke annotationProcessori konfiguratsiooniks kapt
  2. Luba lisanduvate annotatsioon töötlemise eksperimentaalse lipu

Avage oma moodulitaseme build.gradle fail ja lisage järgmine rida faili ülaossa:

apply plugin: 'kotlin-kapt'

Järgmisena muutke sõltuvuste jaotises kõiki annotationProcessori konfiguratsioone, et kasutada kapt. Siin on näide:

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

Nüüd avage oma failis gradle.properties asuv fail ja lisage järgmine rida:

kapt.incremental.apt=true

Käivitame ehituse uuesti. ??????

Hästi, tundub, et me jõuame sinna.

Samm # 3: Gradle Properties

Oleme nüüd viimases etapis. Kas mäletate gotchat, millega Gradle'i pistikprogrammi versiooni värskendades kohtasime? Selgub, et Gradle'i uuemad versioonid vähendavad kuhja suurust 512 MB-ni. Selle eesmärk on tagada, et madalama otsa masinad ei lämbuks. Olen 16-mängulise masinaga, nii et saan lubada Gradle'i deemonile umbes 2–3 kontserdi andmist, kuid teie läbisõit võib erineda.

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

See ei tähenda kaugeltki kõiki nende projekti ehitamise kiiruse optimeerimise võimalusi. Selles postituses pole veel palju asju, millest ma ei rääkinud, näiteks minSdk 21 kasutamine MultiDexi kasutamisel, teie teekide dexxing, PNG krimpsutamise keelamine ja nii edasi - kui nimetada vaid mõnda.

Kuid enamik neist konfiguratsioonidest nõuab Androidi ehitussüsteemi sügavamat mõistmist ja suurte mitmemooduliliste projektidega töötamise kogemust (just seal on eelised kõige ilmsemad) . Eespool nimetatud samme on hõlbus lisada projekti isegi nooremate arendajate poolt ja neil on märkimisväärne tasuvus. Loodan, et see aitab teil ehitamise kiirust vähendada!

Hästi järgmise korrani, rahu! ✌?