Komplet guide til konfiguration af builds i Android Studio

Alfa-guide » Android » Komplet guide til konfiguration af builds i Android Studio

Hvis du er begyndt at arbejde med mobiludvikling, har du sikkert indset, at det at sætte et build op ikke bare handler om at trykke på en kør-knap. Android-buildsystemet er den motor, der tager al din kode og dine ressourcer og omdanner dem til en APK-fil eller en Android App Bundle (AAB), som er de pakker, der i sidste ende når brugernes enheder.

For at alt dette skal køre problemfrit, bruger Android Studio Gradle og dets dedikerede plugin , der giver os mulighed for at tilpasse alt fra appens signatur til hvilke operativsystemversioner vi understøtter. Det er ikke nemt i starten, men når du mestrer, hvordan du organiserer dine varianter og afhængigheder, kan du udgive gratis, betalte eller prøveversioner uden at skulle duplikere dit projekt.

Hjertet i byggeprocessen: Gradle og dens filer

For at styre byggeprocessen skal vi interagere med adskillige tekstfiler, der bruger sprog som Kotlin DSL eller Groovy. For det første har vi Gradle Wrapper (gradlew) , som er fantastisk, fordi den sikrer, at hele teamet bruger den samme version af Gradle, hvilket forhindrer det typiske "det virker på min maskine"-scenarie.

I roden af ​​projektet finder vi filen settings.gradle.kts , hvor vi fortæller Gradle, hvilke moduler der er en del af appen, og konfigurerer repositorierne. Derefter er der filen build.gradle på topniveau , som definerer de plugin-versioner, der skal deles mellem alle moduler. Men den virkelige perle er build.gradle-filen på modulniveau , hvor vi konfigurerer de app-specifikke detaljer, såsom SDK og afhængigheder.

At mestre Android SDK'et

Det er vigtigt at konfigurere SDK'et for at forhindre, at din app går ned på ældre enheder eller bliver forældet. compileSdk definerer , hvilke Android API'er der er tilgængelige, mens du skriver kode. Ideelt set bør du altid bruge den nyeste version for at drage fordel af de nyeste funktioner. På den anden side er minSdk den røde linje: Enhver enhed med en lavere version end denne vil ikke kunne installere applikationen.

Vi må ikke glemme targetSdk , som grundlæggende fortæller operativsystemet, at vi allerede har testet appen på den specifikke version. Hvis enheden har en nyere version af Android end vores target, aktiverer systemet en kompatibilitetstilstand for at forhindre appen i at opføre sig uregelmæssigt.

Produktvarianter og byggetyper

Det er her, tingene bliver interessante. Byggetyper De tjener til at skelne mellem udviklingsstadier. Som standard har vi debugsom tillader fejlfinding og bruger en generisk nøgle, og release, som er den optimerede, tilslørede og signerede version til offentligheden.

Hvis du vil lancere en "Lite"-version og en "Pro"-version, skal du bruge ProduktsmagDisse tillader genbrug af almindelig kode, men ændring af ressourcer eller funktionaliteter afhængigt af versionen. Når vi kombinerer en buildtype med en produktvariant, får vi en kompileringsvariant (f.eks. demoDebugFor at håndtere dette bruger vi dimensioner af variantersom giver dig mulighed for at gruppere forskellige smagsvarianter fra appen og blande dem.

ID- og navneområdestyring

El applikations-ID Dette er din apps ID i Google Play. Hvis du ændrer det efter udgivelsen, vil butikken tro, at det er en helt ny app. Det er muligt at bruge applicationIdSuffix så fejlfindingsversionen har et andet ID og kan installeres begge versioner på den samme mobiltelefon uden at støde sammen.

Navnerummet definerer derimod den pakke, hvor R- og BuildConfig-klasserne genereres. Selvom det anbefales, at navnerummet og applicationId er de samme for at undgå komplikationer, er det muligt at adskille dem, hvis du har brug for at omorganisere kildekoden uden at ændre appens identitet i butikken.

Signatur- og sikkerhedskonfiguration

En udgivelsesapp kan ikke distribueres, hvis den ikke er signeret. Til dette har vi brug for et nøglelager og en privat nøgle. Det er afgørende ikke at skrive adgangskoderne direkte ind i Gradle-filen; den bedste praksis er at indlæse dem fra miljøvariabler eller en lokal egenskabsfil, der ikke uploades til versionskontrol.

IDE-ydeevneoptimering

Android Studio kan være en RAM-sluger. For at forhindre dette kan du redigere filen studio.vmoptions og øge den maksimale heap-størrelse (Xmx). Hvis din computer kører på få ressourcer, er det bedst at aktivere strømbesparende tilstand , deaktivere unødvendige lint-kontroller og frem for alt foretage fejlfinding på en fysisk enhed i stedet for at bruge emulatoren.

På Windows kan antivirussoftware forsinke byggeprocessen ved at scanne alle filer, som Gradle opretter. Løsningen er at udelukke Gradle-mapper , Android SDK'et og projekter fra scanning i realtid for at opnå en betydelig hastighedsforøgelse.

Brug af BuildConfig og native biblioteker

klasse Byggekonfiguration Det er et vigtigt værktøj, som Gradle genererer automatisk. Det fortæller os, om vi er i tilstanden DEBUG o RELEASE gennem kode, hvilket er ideelt til skjul logfiler i produktion eller ændre server-URL'en mellem udviklingsmiljøet og live-miljøet.

For dem, der har brug for rå kraft, tillader Android Studio integration C++ ved hjælp af CMake eller ndk-buildVi kan forbinde eksterne projekter og kontrollere hvad. ABI'er (binære grænseflader)Vi ønsker at pakke ved hjælp af abiFiltersforhindrer, at den endelige fil bliver for stor, ved at inkludere arkitekturer, som vi ikke har brug for.

Organisering af kildesæt

Gradle organiserer koden i sæt af oprindelserKataloget src/main/ Den indeholder det, der deles af alle, men vi kan oprette mapper som f.eks. src/debug/ o src/full/ at indsætte kode, der kun findes i den version. Der er én prioritetshierarkiFilerne i buildvarianten har forrang frem for dem af buildtypen, og disse har forrang frem for dem af produktvarianten og hovedkoden.

Gennem hele dette økosystem af konfigurationsfiler, hukommelsesstyring og versionsdeling er det muligt at omdanne et simpelt projekt til en professionel infrastruktur, der er i stand til at skalere og tilpasse sig enhver Android-enhed, hvilket sikrer, at pakningsprocessen er effektiv, og distributionen i butikken er sikker.