Hogyan lehet javítani az Android projektek összeállítási sebességét

A közelmúltban vállaltam a Kure Android kódbázisának áttelepítését az AndroidX-re. Tökéletes lehetőségnek tűnt kipróbálni a projekt felépítési sebességét.

Gradle-nek mindig rossz volt a reprezentációja, mivel lassú és erőforrásigényes volt, de nagyon meglepődtem azon, hogy a projekt build-konfigurációjának kisebb változtatásai miként javíthatják jelentősen az összeállítási sebességet.

Hogy bepillanthassak abba az időbe, amelyet a tiszta építményeinkből ki tudtam szabadítani, íme egy az előtte és utána mutató a build összeolvasásából.

5,5 percről 17 másodpercre lefelé haladni ?? Azok hülyék.

Könnyen túlléphet az optimalizálásokkal, amelyek elvégzésével még tovább csökkentheti az építési időt. De szándékosan azokra a kisebb, fájdalommentes intézkedésekre fogok összpontosítani, amelyeket azért tettem, hogy közelebb kerüljek ehhez a mutatóhoz annak érdekében, hogy a kezdők számára barátságos legyen.

De először!

Mielőtt elkezdené az optimalizálást, fontos összehasonlítani a projektünket, hogy lássa, mennyi időbe telik az elkészítése. A Gradle rendelkezik egy praktikus beolvasási lehetőséggel, amely segítségével elemezheti a feladat teljesítményét. Indítsa el az Android Studio terminálját, és hajtsa végre a következő parancsot:

./gradlew assembleDebug --scan

Miután az összeállítás sikeresen befejeződött, a rendszer felkéri Önt, hogy fogadja el az általános szerződési feltételeket, hogy feltöltse a build vizsgálat eredményeit. Írja be az igent a folytatáshoz. Miután befejezte a közzétételt, kap egy linket a terminálon, hogy ellenőrizze a build vizsgálatát. Nyissa meg a linket.

Elég sok lehetőség van az oldalon, de a rövidség kedvéért csak a legfontosabbakat vesszük szemügyre.

Az összegzésnézetben összefoglalja a futtatott feladatokat, és azt, hogy mennyi időbe telt a végrehajtásuk. De ami itt érdekel, az a Performance szakasz. Részletesebb bontást nyújt a teljes építési időről az alábbiak szerint.

A teljesítmény szakasz alatt található a Beállítások és javaslatok fül, amely javaslatokat ad arra vonatkozóan, hogyan javíthatja az összeállítási sebességet. Nézzük meg.

Ebben a szakaszban megtalálhatunk néhány egyszerű javítást az építési sebességünkhöz. Tehát folytassuk és alkalmazzuk ezeket a javaslatokat projektünkben.

1. lépés: Frissítse szerszámát

Az Android csapat folyamatosan fejleszti és fejleszti az Android build rendszert. Így legtöbbször jelentős javulás érhető el, ha csak az eszköz legújabb verzióját alkalmazza.

A refaktor idején projektünk a Gradle plugin for Android Studio 3.2.1 -es verzióján volt (amely néhány verzióval régebbi, mint a legújabb kiadás).

Erre a linkre látogatva megkapja a Gradle plugin legújabb kiadásának verzióját.

A bejegyzés megírásakor a legújabb verzió véletlenül a 3.4.0.

De jön egy góc, amelyet későbbre kell szem előtt tartanunk:

A Gradle 5.0 és újabb verzióinak használatakor kifejezetten meg kell növelnünk a kupac méretét, hogy az építési sebességünk ne romoljon. Erre csak egy perc múlva térünk vissza.

Nyissa meg a legfelső szintű build.gradle fájlt, amelyet a projekt gyökérkönyvtárában talál, és adja hozzá a következő sort a függőségek szakaszhoz:

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

Frissítenie kell a terjesztés URL-jét a gradle wrapper tulajdonságfájlban is, amely a gradle / wrapper / gradle-wrapper.properties címen található. Frissítse az URL-t a következőre.

(Ez a link az Android Gradle plugin kiadási oldalán lesz elérhető.)

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

Ha a Kotlin programot használja, akkor hibába ütközik, ha a Kotlin Gradle plugin verziója 1.3.0- nél kisebb . Ebben az esetben használja az IDE parancssorát a Kotlin Gradle plugin frissítésére a legújabb verzióra (ami a bejegyzés írásakor véletlenül 1.3.31-es verzió ).

Rendben, futtassuk újra a buildet a terminálról, hogy lássuk, sikerült-e valamilyen fejlesztés.

2. lépés: Frissítse a konfigurációkat

Tehát körülbelül 2,5 percet tudtunk leadni a gyártási időtől, de ez még mindig nem elég jó. Miután megvizsgáltam a terminál építési naplóit, egy sorra bukkantam, ami számunkra érdekes:

Az inkrementális fordítás alapvetően megakadályozza a teljes forrásfájlkészlet pazarló összeállítását, ehelyett csak a megváltozott fájlokat állítja össze. A naplókat nézve egyértelmű, hogy nem használjuk ki ezt a funkciót. Azt javasolja, hogy használjuk az android.enableSeparateAnnotationProcessing = true parancsot, de mivel projektjeinkben a Kotlint használjuk, semmiképpen sem szabad használni az 'annotationProcessor' konfigurációt.

Szerencsére a Kotlin 1.3.30-as verziója hozzáadta az inkrementális kommentár-feldolgozás támogatását.

Tehát

  1. Módosítsa az annotationProcessor konfigurációját kapt-ra
  2. Engedélyezze a járulékos kommentár feldolgozó kísérleti jelölés

Nyissa meg a modul szintű build.gradle fájlt, és adja hozzá a következő sort a fájl tetejéhez:

apply plugin: 'kotlin-kapt'

Ezután módosítsa az összes annotationProcessor konfigurációt a függőségek szakaszban a kapt használatához. Íme egy példa:

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

Most nyissa meg a projekt gyökerében található gradle.properties fájlt, és adja hozzá a következő sort:

kapt.incremental.apt=true

Futtassuk újra az építést. ??????

Rendben, úgy néz ki, hogy odaérünk.

3. lépés: Gradle Properties

Most vagyunk az utolsó szakaszban. Emlékszel a Gchchára, akivel a Gradle plugin verziójának frissítése közben találkoztunk? Kiderült, hogy a Gradle újabb verziói 512 MB-ra csökkentik a kupac méretét. Ennek célja, hogy az alsó végű gépek ne fojtsanak el. 16 gigás gépen vagyok, így megengedhetem magamnak, hogy körülbelül 2–3 koncertet adjak a Gradle démonnak, de a futásteljesítmény változhat.

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

This is by no means an extensive coverage of all the ways one can optimize the build speed of their project. There are tons of other things which I did not go over in this post like using minSdk 21 when using MultiDex, pre-dexing your libraries, disabling PNG crunching, and so on — to name a few.

But most of these configurations require a deeper understanding of Android’s build system and experience working on large multi-module projects (which is where the benefits are most apparent). The steps I mentioned above are easy to incorporate in a project even by junior devs and have considerable payoffs. I hope this helps you trim down your build speeds!

Alright until next time, peace! ✌?