Komplett guide til konfigurasjon av bygg i Android Studio

Alfaguide » Android » Komplett guide til konfigurasjon av bygg i Android Studio

Hvis du er i ferd med å bli interessert i mobilutvikling, har du sannsynligvis innsett at det å sette opp en build ikke bare handler om å trykke på kjør-knappen. Android-byggesystemet er motoren som tar all koden og ressursene dine og transformerer dem til en APK-fil eller en Android App Bundle (AAB), som er pakkene som til slutt når brukernes enheter.

For at alt dette skal gå knirkefritt, bruker Android Studio Gradle og den dedikerte pluginen , som lar oss tilpasse alt fra appens signatur til hvilke operativsystemversjoner vi støtter. Det er ikke lett i starten, men når du mestrer hvordan du organiserer varianter og avhengigheter, kan du gi ut gratisversjoner, betalte versjoner eller prøveversjoner uten å måtte duplisere prosjektet ditt.

Hjertet i bygget: Gradle og filene

For å administrere byggeprosessen må vi samhandle med flere tekstfiler som bruker språk som Kotlin DSL eller Groovy. Først har vi Gradle Wrapper (gradlew) , som er fantastisk fordi den sikrer at hele teamet bruker samme versjon av Gradle, og forhindrer det typiske "det fungerer på min maskin"-scenarioet.

I roten av prosjektet finner vi settings.gradle.kts -filen , der vi forteller Gradle hvilke moduler som er en del av appen og konfigurerer repositoriene. Så har vi den øverste build.gradle-filen , som definerer plugin-versjonene som skal deles mellom alle modulene. Men den virkelige perlen er den modulnivåbaserte build.gradle-filen , der vi konfigurerer de appspesifikke detaljene, for eksempel SDK og avhengigheter.

Mestre Android SDK

Det er viktig å konfigurere SDK-en for å forhindre at appen din krasjer på eldre enheter eller blir foreldet. compileSdk definerer hvilke Android API-er som er tilgjengelige mens du skriver kode. Ideelt sett bør du alltid bruke den nyeste versjonen for å dra nytte av de nyeste funksjonene. På den annen side er minSdk den røde linjen: alle enheter med en versjon lavere enn dette vil ikke kunne installere applikasjonen.

Vi kan ikke glemme targetSdk , som i bunn og grunn forteller operativsystemet at vi allerede har testet appen på den spesifikke versjonen. Hvis enheten har en nyere versjon av Android enn målversjonen vår, vil systemet aktivere en kompatibilitetsmodus for å forhindre at appen oppfører seg uregelmessig.

Produktvarianter og byggetyper

Det er her ting blir interessante. Byggetyper De tjener til å skille mellom utviklingsstadier. Som standard har vi debugsom tillater feilsøking og bruker en generisk nøkkel, og release, som er den optimaliserte, obfuskerte og signerte versjonen for publikum.

Hvis du vil lansere en «Lite»-versjon og en «Pro»-versjon, må du bruke ProduktsmakerDisse tillater gjenbruk av vanlig kode, men endre ressurser eller funksjonalitet avhengig av versjon. Når vi kombinerer en byggetype med en produktvariant, får vi en kompileringsvariant (for eksempel demoDebugFor å håndtere dette bruker vi dimensjoner av variantersom lar deg gruppere forskjellige smaker fra appen og blande dem.

ID- og navneområdehåndtering

El applikasjons-ID Dette er appens ID på Google Play. Hvis du endrer den etter publisering, vil butikken tro at det er en helt ny app. Det er mulig å bruke applicationIdSuffix slik at feilsøkingsversjonen har en annen ID og kan installeres begge versjoner på samme mobiltelefon uten å kollidere.

Navnerommet definerer derimot pakken der R- og BuildConfig-klassene genereres. Selv om det anbefales at navnerommet og applicationId er det samme for å unngå komplikasjoner, er det mulig å skille dem hvis du trenger å omorganisere kildekoden uten å endre appens identitet i butikken.

Signatur- og sikkerhetskonfigurasjon

En utgivelsesapp kan ikke distribueres hvis den ikke er signert. Til dette trenger vi et nøkkellager og en privat nøkkel. Det er avgjørende å ikke skrive passordene direkte inn i Gradle-filen. Den beste fremgangsmåten er å laste dem inn fra miljøvariabler eller en lokal egenskapsfil som ikke lastes opp til versjonskontroll.

IDE-ytelsesoptimalisering

Android Studio kan være en RAM-sluker. For å forhindre dette kan du redigere studio.vmoptions -filen og øke den maksimale heap-størrelsen (Xmx). Hvis datamaskinen din kjører på få ressurser, er det best å aktivere strømsparingsmodus , deaktivere unødvendige lint-kontroller og, fremfor alt, feilsøke på en fysisk enhet i stedet for å bruke emulatoren.

På Windows kan antivirusprogramvare forsinke byggeprosessen ved å skanne alle filer Gradle oppretter. Løsningen er å ekskludere Gradle-mapper , Android SDK og prosjekter fra sanntidsskanning for å få en betydelig hastighetsøkning.

Bruk av BuildConfig og native biblioteker

Klasse Byggekonfigurasjon Det er et viktig verktøy som Gradle genererer automatisk. Det gir oss beskjed om vi er i modus DEBUG o RELEASE gjennom kode, som er ideelt for skjul logger i produksjon eller endre server-URL-en mellom utviklingsmiljøet og live-miljøet.

For de som trenger rå kraft, tillater Android Studio integrering C++ ved bruk av CMake eller ndk-buildVi kan koble eksterne prosjekter og kontrollere hva. ABI-er (binære grensesnitt)Vi ønsker å pakke ved hjelp av abiFiltersforhindre at den endelige filen blir for stor ved å inkludere arkitekturer vi ikke trenger.

Organisering av kildesett

Gradle organiserer koden i sett med opprinnelserKatalogen src/main/ Den inneholder det som deles av alle, men vi kan opprette mapper som src/debug/ o src/full/ å sette inn kode som bare finnes i den versjonen. Det finnes én prioritetshierarkiFilene i byggevarianten prioriteres over de av byggetypen, og disse prioriteres over de av produktvarianten og hovedkoden.

Gjennom hele dette økosystemet av konfigurasjonsfiler, minnehåndtering og versjonsdeling er det mulig å transformere et enkelt prosjekt til en profesjonell infrastruktur som kan skaleres og tilpasses enhver Android-enhet, noe som sikrer at pakkeprosessen er effektiv og distribusjonen i butikken er sikker.