Komplett guide till att konfigurera byggen i Android Studio

Alfaguide » Android » Komplett guide till att konfigurera byggen i Android Studio

Om du ger dig in i mobilutveckling har du förmodligen insett att det inte bara handlar om att trycka på körknappen för att skapa en build . Android-byggsystemet är motorn som tar all din kod och alla dina resurser och omvandlar dem till en APK-fil eller ett Android App Bundle (AAB), vilket är de paket som slutligen når användarnas enheter.

För att allt detta ska fungera smidigt förlitar sig Android Studio på Gradle och dess dedikerade plugin , vilket gör att vi kan anpassa allt från appens signatur till vilka operativsystemversioner vi stöder. Det är inte lätt till en början, men när du väl behärskar hur du organiserar dina varianter och beroenden kan du släppa gratis-, betal- eller testversioner utan att behöva duplicera ditt projekt.

Hjärtat i bygget: Gradle och dess filer

För att hantera byggprocessen behöver vi interagera med flera textfiler som använder språk som Kotlin DSL eller Groovy. Först har vi Gradle Wrapper (gradlew) , vilket är fantastiskt eftersom det säkerställer att hela teamet använder samma version av Gradle, vilket förhindrar det typiska "det fungerar på min maskin"-scenariot.

I projektets rot hittar vi filen settings.gradle.kts , där vi anger för Gradle vilka moduler som är en del av appen och konfigurerar repositorierna. Sedan finns det den översta build.gradle-filen , som definierar de plugin-versioner som ska delas mellan alla moduler. Men den verkliga pärlan är modulnivå-filen build.gradle , där vi konfigurerar de appspecifika detaljerna, såsom SDK och beroenden.

Bemästra Android SDK

Att konfigurera SDK:t är avgörande för att förhindra att din app kraschar på äldre enheter eller blir föråldrad. compileSdk definierar vilka Android API:er som är tillgängliga medan du skriver kod; helst bör du alltid använda den senaste versionen för att dra nytta av de nyaste funktionerna. Å andra sidan är minSdk den röda linjen: alla enheter med en lägre version än denna kommer inte att kunna installera applikationen.

Vi får inte glömma targetSdk , som i princip talar om för operativsystemet att vi redan har testat appen på just den versionen. Om enheten har en nyare version av Android än vår målversion aktiverar systemet ett kompatibilitetsläge för att förhindra att appen beter sig oregelbundet.

Produktvarianter och byggtyper

Det är här det blir intressant. Byggtyper De tjänar till att differentiera utvecklingsstadier. Som standard har vi debugvilket tillåter felsökning och använder en generisk nyckel, och release, vilket är den optimerade, obfuskerade och signerade versionen för allmänheten.

Om du vill lansera en "Lite"-version och en "Pro"-version måste du använda Produktens smakerDessa tillåter återanvändning av vanlig kod men att ändra resurser eller funktioner beroende på version. När vi kombinerar en byggtyp med en produktvariant får vi en kompileringsvariant (till exempel, demoDebugFör att hantera detta använder vi dimensioner av variantervilket gör att du kan gruppera olika smaker från appen och blanda dem.

ID- och namnrymdshantering

El ansöknings-ID Detta är din apps ID på Google Play. Om du ändrar det efter publicering kommer butiken att tro att det är en helt ny app. Det är möjligt att använda applicationIdSuffix så att felsökningsversionen har ett annat ID och kan installeras båda versionerna på samma mobiltelefon utan att kollidera.

Namnrymden , å andra sidan, definierar paketet där klasserna R och BuildConfig genereras. Även om det rekommenderas att namnrymden och applicationId är desamma för att undvika komplikationer, är det möjligt att separera dem om du behöver omorganisera källkoden utan att ändra appens identitet i butiken.

Signatur- och säkerhetskonfiguration

En versionsapp kan inte distribueras om den inte är signerad. För detta behöver vi en nyckelbutik och en privat nyckel. Det är avgörande att inte skriva lösenorden direkt i Gradle-filen; det bästa är att läsa in dem från miljövariabler eller en lokal egenskapsfil som inte laddas upp till versionshantering.

IDE-prestandaoptimering

Android Studio kan vara ett RAM-slukare. För att förhindra detta kan du redigera filen studio.vmoptions och öka den maximala heap-storleken (Xmx). Om din dator körs på få resurser är det bäst att aktivera energisparläge , inaktivera onödiga lintkontroller och framför allt felsöka på en fysisk enhet istället för att använda emulatorn.

På Windows kan antivirusprogram sakta ner byggprocessen genom att skanna varje fil som Gradle skapar. Lösningen är att exkludera Gradle-mappar , Android SDK och projekt från realtidsskanning för att få en betydande hastighetsökning.

Använda BuildConfig och native bibliotek

Klass Byggkonfiguration Det är ett viktigt verktyg som Gradle genererar automatiskt. Det låter oss veta om vi är i läge DEBUG o RELEASE genom kod, vilket är idealiskt för dölj loggar i produktion eller ändra serverns URL mellan utvecklingsmiljön och live-miljön.

För de som behöver rå kraft, tillåter Android Studio integration C++ med CMake eller ndk-buildVi kan länka externa projekt och kontrollera vad. ABI:er (binära gränssnitt)Vi vill paketera med hjälp av abiFiltersförhindra att den slutliga filen blir för stor genom att inkludera arkitekturer som vi inte behöver.

Organisera källuppsättningar

Gradle organiserar koden i uppsättningar av ursprungKatalogen src/main/ Den innehåller det som delas av alla, men vi kan skapa mappar som src/debug/ o src/full/ att infoga kod som bara finns i den versionen. Det finns en prioritetshierarkiFilerna i byggvarianten har företräde framför de av byggtypen, och dessa har företräde framför de av produktvarianten och huvudkoden.

Genom hela detta ekosystem av konfigurationsfiler, minneshantering och versionsdelning är det möjligt att omvandla ett enkelt projekt till en professionell infrastruktur som kan skalas och anpassas till vilken Android-enhet som helst, vilket säkerställer att paketeringsprocessen är effektiv och distributionen i butiken är säker.